Check security headers
Ce contenu n'est pas encore disponible dans votre langue.
Inspect the policy the browser receives when a proxy or identity-provider redirect fails.
Prerequisites
Section titled “Prerequisites”- Access to browser developer tools, application configuration and proxy configuration.
- A working public HTTPS URL and, for SSO, the provider’s discovery metadata.
1. Inspect the public response
Section titled “1. Inspect the public response”Load the affected page and inspect its response headers in the browser’s Network panel. Check both the main page and any failing /auth request: the authentication application has its own middleware settings.
Compare the browser’s console error with the effective Content-Security-Policy. Check whether both the proxy and application emit a policy. Multiple policies can constrain a request together; adding a permissive header at the proxy does not necessarily relax the application policy.
Identify which application answered before changing a switch:
| Response surface | Configuration to inspect |
|---|---|
| Core web HTML | CSP_ENABLED controls the nonce-based CSP. This middleware does not add that policy to API responses. |
/auth in full mode |
site.middleware.profiles.authenticated_web controls a separate protection stack. Its components default on in development, test and production. |
| Shared protections | site.middleware.* and their MIDDLEWARE_* variables configure the shared stack, not the additional /auth profile. |
For example, MIDDLEWARE_HTTP_ORIGIN=false does not disable the auth profile’s Origin check; its separate variable is MIDDLEWARE_AUTH_HTTP_ORIGIN. Likewise, CSP_ENABLED=false does not disable the auth profile’s CSP; that component uses MIDDLEWARE_AUTH_CONTENT_SECURITY_POLICY. Keep these protections enabled while diagnosing the request. A successful homepage load does not test the /auth stack.
2. Check the identity-provider origin
Section titled “2. Check the identity-provider origin”The application derives platform provider origins for CSP and adds custom-domain SSO origins per request. Normally you do not need a manual allowlist.
An OIDC issuer can publish an authorization endpoint on another origin. If the browser reports that origin is blocked by form-action, verify it against the provider’s discovery metadata, then add only the required origin:
SSO_FORM_ACTION_ORIGINS=https://login.example.comThe value is a space-separated list of origins, without URL paths. It is an override for missing or incomplete derivation, not a replacement for provider configuration.
Sovereign Microsoft Entra deployments use generic OIDC with the sovereign issuer; that issuer’s origin is derived automatically. Do not add a broad Microsoft allowlist by default.
3. Correct the responsible layer
Section titled “3. Correct the responsible layer”Update the relevant proxy or application setting and restart the affected services. Keep CSP and CSRF protections enabled. The environment reference documents the separate CSP_ENABLED and authentication-middleware switches.
Verify it worked
Section titled “Verify it worked”Repeat the previously failing action through the public hostname. Confirm the console no longer reports the blocked origin and the SSO callback returns to an authenticated session. Inspect response headers again to ensure the intended policy remains active.