Home > database >  What are the security implications of setting Access-Control-Allow-Headers: *, if any?
What are the security implications of setting Access-Control-Allow-Headers: *, if any?

Time:09-24

For my web app, I sometimes get errors like Request header field Pragma is not allowed by Access-Control-Allow-Headers in preflight response, which I can solve by configuring Access-Control-Allow-Headers: * on the server side. Are there any security implications for this?

CodePudding user response:

To set it to a wildcard *, means to allow all headers apart from safelisted ones, and remove restrictions that keeps them safe.

These are the restrictions for the 4 safelisted headers to be considered safe:

  • For Accept-Language and Content-Language: can only have values consisting of 0-9, A-Z, a-z, space or *,-.;=.
  • For Accept and Content-Type: can't contain a CORS-unsafe request header byte: 0x00-0x1F (except for 0x09 (HT), which is allowed), "():<>?@[\]{}, and 0x7F (DEL).
  • For Content-Type: needs to have a MIME type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded, multipart/form-data, or text/plain.
  • For any header: the value’s length can't be greater than 128.

For simplicity's sake, I'll base my answer on these headers.

Depending on server implementation, simply removing these limitations can be very dangerous (to the user).
For example, this outdated wordpress plugin has a reflected XSS vulnerability where the value of Accept-Language was parsed and rendered on the page as-is, causing script execution on the user's browser should a malicious payload be included in the value.

With the wildcard header Access-Control-Allow-Headers: *, a third party site redirecting to your site could set the value of the header to Accept Language: <script src="https://example.com/malicious-script.js"></script>, given that the wildcard removes the restriction in Point 1 above.

The preflight response would then give the greenlight to this request, and the user will be redirected to your site, triggering an XSS on their browser, which impact can range from an annoying popup to losing control of their account through cookie hijacking.

Thus, I would strongly recommend against setting a wildcard unless it is for an API endpoint where nothing is being rendered on the page.

You can set Access-Control-Allow-Headers: Pragma as an alternative solution to your problem.


Note that the value * only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information), otherwise it will be read as a literal header. Documentation

  • Related