I have a follow-up question to this older question: How to exploit a misconfigured CORS policy when a per user authorization token is required?

According to Mozilla's documentation, the Access-Control-Allow-Credentials should be able to transport tokens such as Authorization headers because "Credentials are cookies, authorization headers or TLS client certificates."

However, when I attempt the following exploit, I can't seem to get any browsers to forward the token.

I'm attempting to perform the following cross domain request from https://my.domain/:

var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.withCredentials = "true"; 

function reqListener() 

The request is preflighted (OPTIONS method) and the API responds with:

HTTP/1.1 200 OK
Access-Control-Expose-Headers: APIm-Debug-Trans-Id, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-Global-Transaction-ID
Access-Control-Allow-Headers: authorization,cache-control,content-type,pragma
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://my.domain/

So far so good. Now the browser immediately follows up with a GET request but for this request to succeed I need it to include the header:

Authorization: bearer [redacted]

But the client's browser apparently can't access this token (?) even though I am authenticated to the API. Is there any way to grab this token from somewhere? I can't seem to find it in the browser's local storage and it's not a cookie value either.

  • There was some bad formatting on the third/fourth line where you actually are setting the authorization header to an empty string.
    – Alex
    Commented Jul 30, 2019 at 15:56

1 Answer 1


However, when I attempt the following exploit, I can't seem to get any browsers to forward the token.

Given that nothing in your code actually sets the Authorization header it looks like that you are assuming that the header gets automatically set by the browser based on cached credentials, i.e. similar to cookies.

But, such caching is only done for authentication credentials entered by the user in case of basic or digest authentication. If some script in the site instead explicitly sets the Authorization header for a specific XHR no caching of the credentials will be done and therefore also no automatic setting of the Authorization header from cached credentials.

  • I see. That makes sense. Thank you so much for clarifying Steffen!
    – Lykias
    Commented Aug 9, 2018 at 17:57
  • Does it imply that if 'Authorization: Bearer xxx' is set by the server for a response, the browser will set this header automatically for all other requests a script would make from the browser (for the same domain)?
    – Dmitry
    Commented Jun 23, 2020 at 20:51
  • @Dmitry: No, the browser will not automatically send an Authorization header from the response back to the server. Commented Jun 23, 2020 at 21:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .