What do Tenant Level security_headers actually impact?

Get Help
,
1

I noticed that that Management API now supports sending a security_headers field on the Update Tenant Settings API, which apparently allows for the configuration of Content-Security-Policy and other security related items.

What I have not been able to find out, is what does this actually control? I tried applying a policy to my tenant and reviewed the headers returned by the Universal Login and Password Reset pages. Unfortunately I can’t seem to get it to produce any changes. I also cannot find any documentation on the topic other than API documentation linked above.

Are these features not fully rolled out yet? What do/will they actually control? Will it extend to the Universal Login page? We’ve had an open action item on our end to apply a stricter CSP to satisfy some pen-test requirements and we were pleased to see the new settings in hopes that it would extend to those pages.

2

Hi @mhull

Thank you for reaching out to us!

You are correct, the security_headers property introduced in the Update tenant settings endpoint (PATCH /api/v2/tenants/settings ) is a feature designed to configure Content-Security-Policy (CSP) and other security directives directly at the tenant level.

It is designed to define custom Content-Security-Policy policies (both in enforcing and

"security_headers": {
  "content_security_policy": {
    "enabled": true,
    "policies": [
      {
        "mode": "enforcing",
        "directives": {},
        "flags": [
          "upgrade-insecure-requests"
        ]
      }
    ]
  }
}

If you applied a policy and saw no changes in the headers returned by the Universal Login or Password Reset pages, this is by design:

  • Strict Default Controls: For the New Universal Login Experience , Auth0 actively enforces and manages its own robust, default security headers (including Content-Security-Policy: frame-ancestors 'none' , X-Frame-Options: deny , and strict transport controls) to protect against Clickjacking, XSS, and session interception .
  • Prevention of Breakage: Customized CSP directives can easily break core Auth0 runtime scripts, SDK interactions, and Attack Protection features (like CAPTCHA and Bot Detection) . Consequently, the default New Universal Login pages do not dynamically inherit the tenant-level security_headers values.

Depending on your architectural approach, you have options to set CSP customization, allow me to share some additional useful documentations:

Hope this helped, please reach out to us for any other issues or requests and we will gladly look into it!

Best regards,
Gerald

3

So you didn’t answer the full question. If it doesn’t impact the two pages I mentioned, what does it actually impact? Where would I actually see a change if I were to apply a policy on my tenant?

Unfortunately those links don’t help at all. The CSP on the universal login page is too weak and results in findings every time we have a PenTest of our application. While I can appreciate that you don’t want to risk users breaking the experience, this feels like an advanced feature to “use at your own risk”. I feel like you should reconsider allowing it to impact universal login, perhaps with an explicit opt-in. Either that, or please work with the community to devise a stricter CSP policy for the universal login.

This topic has come up before from other people, both in the context of PenTest findings and general best practices. I am on mobile at the moment so it’s difficult to search for those right now… However they were all unresolved and/or pointed to the same unactionable links.