CORS wildcard subdomain support for high-risk endpoints

Introduction

Starting with Safewhere Identify version 5.18, we've enhanced the security and flexibility of CORS settings by introducing support for subdomain wildcard matching in the Access-Control-Allow-Origin header for CORS (Cross-Origin Resource Sharing). This new feature allows trusted subdomains to access endpoints securely, minimizing potential security risks.

Challenges in previous versions

In earlier versions, Safewhere Identify supported either a wildcard origin (*) or exact origin matches, but it did not support subdomain wildcards (e.g., https://*.safewhere.com). This limitation complicated access for applications that needed to reach Identify endpoints from various subdomains.

For some specific OAuth endpoints, the Access-Control-Allow-Origin header was set in the web.config, allowing unrestricted cross-origin access with a wildcard (*). While this configuration is a common way to enable CORS for public APIs, it posed security risks, as unrestricted access is often not recommended for sensitive endpoints. To mitigate risks like cross-site scripting (XSS) attacks, trusted origins should be specified explicitly.

New feature: Subdomain wildcard support

This update enables Safewhere Identify to support subdomain wildcards in the Access-Control-Allow-Origin header, allowing administrators to grant access to any subdomain under a specific domain securely.

For example, setting the Allowed Domains in CORS Origins Header setting to https://*.safewhere.com now allows any subdomain - such as https://api.safewhere.com, https://admin.safewhere.com, or https://portal.safewhere.com - to securely access endpoints.

Key changes

Support for flexible CORS configuration

The Allowed Domains in CORS Origins Header setting in the Settings now supports wildcard subdomains.

Additionally, a new Allowed Domains in CORS Origins Header setting is available under the Security tab for OAuth/OIDC applications. This setting applies only to applications using these connections.

However, the most important change, which is also a breaking one, is the removal of the wildcard (*) rule for the Access-Control-Allow-Origin header in the web.config for OAuth 2.0/OIDC endpoints such as openidconnect/userinfo.idp and oauth2/token.idp. By removing the wildcard, only trusted origins explicitly specified in the two aforementioned settings can access these endpoints, reducing the likelihood of XSS and other vulnerabilities.

A potential backward compatibility issue is that applications using OAuth/OIDC connections upgraded from a previous Identify version may lose access to openidconnect/userinfo.idp and oauth2/token.idp if their origin is not configured in the Allowed Domains in CORS Origins Header. To prevent access issues, the system will automatically permit CORS for domains listed in the Allowed Callback URIs for OAuth/OIDC connections.

Handling preflight requests (HTTP OPTIONS)

Preflight requests lack sufficient information to determine if they match any origin configured in the Allowed Domains in CORS Origins Header and Allowed Callback URI settings.

To address this, we implemented a workaround which adds the requesting origin to the Access-Control-Allow-Origin header in the response.

CORS handling process

When a request is made to Safewhere Identify, it performs a series of CORS-related validations in the following order:

1. If the endpoint is configured in the web.config: The response'sAccess-Control-Allow-Origin header is set according to the web.config.

Previously, setting a wildcard (*) value for the Allowed Domains in CORS Origins Header setting in the Settings page could cause errors for some endpoints because they already had Access-Control-Allow-Origin configured in web.config. Now, Identify checks if Access-Control-Allow-Origin is already configured for an endpoint in web.config. If it is, the endpoint will set Access-Control-Allow-Origin in the Runtime web.config without creating duplicates.

2. If the endpoint is not configured in the web.config: The system compares the request's "Origin" header with the following configurations:

• Allowed domains in Allowed domains in CORS origins header in the Setting page
• Allowed domains in Allowed domains in CORS origins header in OAuth/OIDC connections
• Allowed domains in Allowed Callback URIs in OAuth/OIDC connections

Based on this comparison, the system applies the appropriate Access-Control-Allow-Origin header:

• If a configuration contains a wildcard (*), the header is set to *.
• If a configuration exactly matches the "Origin" header of the request, the header is set to that origin.
• If a wildcard subdomain in the configuration matches the "Origin" header of the request, the header is set to that origin.

If none of the above conditions are met, the system will respond with HTTP 403 Forbidden, denying access.