Set up CORS for Ory Network

Cross-Origin Resource Sharing (CORS) is a mechanism to allow cross-origin requests. CORS is a relaxation of the same-origin policy implemented in modern browsers. It allows a server to explicitly allow some cross-origin requests while rejecting others. It's important that you add CORS origins to your Ory Project to ensure Single Page Applications (SPAs) support. Ory Network allows up to 50 origins. If you plan on using server-side rendering or native applications, you can disable CORS. You can read more about CORS at MDN.

note

Ory Network doesn't allow setting the CORS origins to be *, null or localhost/127.0.0.1. You can, however, use a wildcard subdomain such as https://*.foobar.ory. To be on the safe side, Ory recommends setting the CORS origins to be an exact match instead of a wildcard subdomain. For local development with localhost/127.0.0.1 use Ory Tunnel.

Supported Endpoints

All public endpoints apply the global CORS settings. For OAuth2, also per-client CORS settings are supported if CORS is enabled globally. This means that you can set different CORS settings for different OAuth2 clients. You can find the CORS settings in the OAuth2 client settings.

Enable CORS

CORS can be enabled using the Ory CLI:

ory patch project <your-project-id> \
  --replace '/cors_public/enabled=true' \
  --replace '/cors_public/origins=["https://*.foobar.ory"]'

You can find more information about the ory patch command in the Ory CLI documentation.

Restricted origins

Some pages load scripts that you don't control, such as ads. If such a page needs to know whether the user is signed in, add its origin to the allowed CORS origins, then mark it as a restricted origin. Requests from a restricted origin can only call these endpoints:

• GET /sessions/whoami to check the session.
• GET /self-service/fed-cm/parameters and POST /self-service/fed-cm/token to sign in with FedCM.
• GET /self-service/logout/browser and GET /self-service/logout to sign out.

All other public endpoints respond with 403 Forbidden. Responses never contain identity data. A session contains only its ID and whether it's active:

{
  "id": "65dea6f4-5d15-4e61-9eb7-f30190c0b2e2",
  "active": true
}

The FedCM token response contains the same reduced session and no identity. A whoami request with tokenize_as fails with 400 Bad Request. Cookies, redirects, and continue_with items don't change.

Requests from other origins and requests without an Origin header, such as calls from your server, still receive full responses. To read identity data, call GET /sessions/whoami from your server and forward the user's cookie.

Use the Ory CLI to allow the origin and mark it as restricted:

ory patch project <your-project-id> \
  --add '/cors_public/origins/-="https://www.example.com"' \
  --replace '/services/identity/config/security/restricted_origins=["https://www.example.com"]'

• Each restricted origin is an exact origin, such as https://www.example.com, without wildcards or paths. It can be covered by a wildcard allowed origin, such as https://*.example.com.
• The restrictions apply whether or not the origin is an allowed origin, and also while CORS is disabled. Without the allowed origin, the browser can't read any response.
• On a custom domain, add the origin to the custom domain's CORS origins instead.
• If session caching is enabled, whoami responses cached before you restrict an origin can be served until they expire.

CORS on custom domains

You can configure custom domains to use specific CORS settings. Head over to the Custom Domains documentation for all information.