Problem statement
This article addresses the following question:
- Why does the /.well-known/jwks.json endpoint not include some Security response headers such as X-XSS-Protection, Content Security Policy, and X-Frame-Option? Is it a security concern?
Steps to reproduce
Navigate to the tenant’s /.well-known/jwks.json, inspect the http response, and notice the missing Security Headers.
Cause
Okta’s Engineering team confirms that this is expected and does not represent any security concern, given that the /.well-known/jwks.json resource serves public information (the public keys to validate a signature issued by the Auth0 tenant).
Solution
Since this is public (and making requests has no side effects), there is no genuine concern about cross-site requests.
In general, a cross-site scripting attack will look to inject a malicious script to run on the given page that is loaded. An XSS attack of any sort cannot adjust/change the existing page, so as it relates to the /.well-known/jwks.json page, even if somehow there was an ability to do an XSS attack, one wouldn’t be able to change the contents of that page, and therefore there wouldn’t be an adverse effect for the apps that consume that page to do validation.
A page better suited for XSS might be, for example, our login pages/flows where a script could be introduced to, for example, log which keystrokes are made. These flows do include the necessary headers (X-Frame-Options, X-Xss-Protection, X-Content-Type-Options, Content-Type, Strict-Transport-Security, Referrer-Policy, etc). To complete an XSS, there are a lot of factors necessary, and going back to the /.well-known/jwks.json page, it is a very “static” page, so even the ability to find and exploit on that page is very, very unlikely.