Security Headers
Configure browser security headers for hosted Login and Profile pages from the Admin Console. The available headers control framing, MIME type detection, referrer data, and the resource origins that pages can load.
Open security headers
Open the Security Headers page from Tenant Settings to configure the headers for your tenant.
- Log in to the LoginRadius Admin Console.
- Navigate to Tenant Settings.
- Select Security Headers.
- Configure the required header options.
- Click Save.
The Security Headers page is available for supported LoginRadius tenants.
Available Headers
Each header is independent and can be enabled or configured on its own.
| Header | Type | Purpose |
|---|---|---|
| X-Frame-Options | Boolean | Prevents the page from being rendered inside a frame or iframe on another site, mitigating clickjacking. |
| X-Content-Type-Options | Boolean | Stops the browser from MIME-sniffing a response into a content type other than the one declared, closing off a content-sniffing based injection vector. |
| Referrer-Policy | String, one of a fixed set of values | Controls how much of the page's URL is sent as the Referer header when the browser makes a request to a different origin. |
| Content-Security-Policy | String, policy directives | Restricts which origins the page may load scripts, styles, images, fonts, and other resources from. |
X-Frame-Options
When enabled, LoginRadius returns X-Frame-Options: deny on the hosted page response, unless the request's Referer matches a domain already registered on that app, either as its Custom Domain or in its Callback URL list. For every other origin, the value is always deny.
Note: This exception is per app, not per tenant. If your integration needs to embed the hosted Login or Profile page inside an iframe on your own domain, register that domain as the app's Custom Domain, or add it to the app's Callback URL list, instead of disabling this header entirely. Any domain that isn't registered this way stays blocked from framing the page.
X-Content-Type-Options
When enabled, LoginRadius returns X-Content-Type-Options: nosniff on the hosted page response. This tells the browser to trust the declared Content-Type rather than inferring one from the response body, which prevents a response from being executed as script or HTML if it wasn't served as one.
Referrer-Policy
The Referrer-Policy value you configure is applied to the hosted Login and Profile pages, including when shown mid-flow for OAuth 2.0, OIDC, JWT, or SAML. SAML also carries the header on its outbound response, while OAuth 2.0, OIDC, and JWT don't since their final token or code response returns before the hosted page is rendered. If it isn't configured, LoginRadius doesn't send the header, and the browser falls back to its own default policy.
| Value | What's sent to a different origin |
|---|---|
| no-referrer | Nothing. |
| no-referrer-when-downgrade | Full URL, unless the request downgrades from HTTPS to HTTP. |
| origin | Scheme, host, and port only. |
| origin-when-cross-origin | Full URL for same-origin requests, origin only for cross-origin requests. |
| same-origin | Full URL for same-origin requests, nothing for cross-origin requests. |
| strict-origin | Origin only, omitted entirely on a downgrade. |
| strict-origin-when-cross-origin | Full URL for same-origin requests, origin only for cross-origin requests, omitted on a downgrade. |
| unsafe-url | Full URL, always. |
Login and Profile page URLs can carry sensitive query parameters, such as a redirect_uri, an OAuth state, or an email address. A loose policy such as unsafe-url hands that full URL to every third-party origin the page talks to, including CDNs, fonts, and analytics scripts. Use strict-origin-when-cross-origin or stricter unless you have a specific reason not to.
Content-Security-Policy
Content-Security-Policy is a directive-based allow-list for the resources a page can load. A directive such as script-src 'self' cdn.example.com permits scripts from the page's own origin and from cdn.example.com, and blocks everything else. LoginRadius passes the configured value through to the response header without validating individual directives, so any directive or source expression the browser supports is available to you.
Enforcing mode and Report-Only mode
A configured policy can be applied in one of two modes, controlled by a single toggle:
- Enforcing (default): LoginRadius returns the policy as Content-Security-Policy. The browser blocks any resource that violates the policy.
- Report-Only: LoginRadius returns the same policy as Content-Security-Policy-Report-Only instead. The browser evaluates the policy and logs violations, but doesn't block anything. Use this to validate a policy against real traffic before enforcing it.
Only one of the two headers is ever returned for a given configuration. Enabling Report-Only doesn't add a second header alongside the enforcing one, it replaces it.
Reporting-Endpoints
Reporting-Endpoints registers a named HTTPS URL the browser sends violation reports to, as JSON. It works together with a report-to directive inside your Content-Security-Policy value, which the Admin Console can add for you.
Reporting-Endpoints: csp-endpoint="https://your-collector.example.com/reports"
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://cdn.example.com; report-to csp-endpoint
The name in Reporting-Endpoints and the name after report-to must match exactly. If they don't match, or Reporting-Endpoints isn't configured at all, violations aren't delivered anywhere, and no error is surfaced anywhere in the response.
LoginRadius doesn't validate the URL you configure, but use an HTTPS URL. The browser blocks a report sent from an HTTPS page to an HTTP endpoint as mixed content, so reports to a non-HTTPS URL are silently dropped. Reports can also contain sensitive data, such as blocked resource URLs, which is a second reason to keep the endpoint on HTTPS.
Dependency on Content-Security-Policy
Report-Only mode and Reporting-Endpoints only take effect when a Content-Security-Policy value is configured. If it's empty, neither header is returned, regardless of how Report-Only or Reporting-Endpoints are configured.
| Content-Security-Policy configured | Report-Only enabled | Reporting-Endpoints configured | Headers returned |
|---|---|---|---|
| No | - | - | None |
| Yes | No | No | Content-Security-Policy |
| Yes | No | Yes | Content-Security-Policy, Reporting-Endpoints |
| Yes | Yes | No | Content-Security-Policy-Report-Only |
| Yes | Yes | Yes | Content-Security-Policy-Report-Only, Reporting-Endpoints |
Configure in the Admin Console
Manage these headers from Tenant Settings → Security Headers:
- Each of the four sections, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Content-Security-Policy, saves independently. Saving one doesn't resend or overwrite the others.
- The Content-Security-Policy section shows a warning if the configured Reporting-Endpoints name is missing from the policy's report-to directive, with a button that adds it for you.
- Viewing this page requires security policy read access. Saving changes requires security policy edit or admin access.
Example
The following Content-Security-Policy configuration, entered in the Admin Console with Report-Only enabled and a Reporting-Endpoints value set, configures violation reporting without blocking anything.
Policy value:
default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data:; font-src 'self' https://fonts.gstatic.com; report-to csp-endpoint
Reporting endpoints:
csp-endpoint="https://your-collector.example.com/reports"
This results in the following headers on the hosted Login and Profile pages:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data:; font-src 'self' https://fonts.gstatic.com; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://your-collector.example.com/reports"
Security Recommendations
These recommendations apply on top of the header behavior described above.
- Start a new Content-Security-Policy in Report-Only mode and let real traffic run before enforcing it. Nobody writes a complete policy from memory. Violation reports tell you what's actually missing.
- Prefer strict-origin-when-cross-origin or stricter for Referrer-Policy, since Login and Profile URLs can carry sensitive query parameters.
- Avoid 'unsafe-inline' and 'unsafe-eval' in script-src where possible. Use nonces or hashes to allow specific inline scripts instead of allowing all of them.
- Enable X-Content-Type-Options and X-Frame-Options as a baseline. Neither has a functional cost to a legitimate user.
- Review Content-Security-Policy whenever you add a new third-party script, font, or embedded widget to the Login or Profile page, since an unlisted origin is silently blocked in enforcing mode.