When loggin in to a website, A Bearer token is generated and echoed back from the server in a JSON reponse. After this, each request sends the generated token in the Authorization: BEarer header.

However, there is a API endpoint which reflects the request Origin header value in Access-Control-Allow-Origin and carries out Access-Control-Allow-Credentials: true to.

I minimize the request to the minimum info needed to make the request successfully and the session is held in the Authorization: Bearer . So, then, I tried to test it for CORS issues to get sensitive info.

But the Cross-domain is not attaching the Authorization header.

I'm using the console in Developer Tools from example.com open.

Using this code:

var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.open('get','url', true); 
req.withCredentials = true; req.send(null); 
function reqListener() { 

But still gets HTTP 401 Unauthorized due to the ausence of Authorization header.

Any comments?

1 Answer 1


Bearer tokens are not sent automatically. They must be manually added by the client on every request.

As such, any site that uses bearer tokens as its only form of session authentication is automatically secure against CSRF and CORS misconfiguration, as the attacker will never know the value to send in the Authorization header (or, if the attacker does know, then they can just send the request without needing a browser at all, using curl or similar, in which case browser-specific features like CORS are irrelevant).

CSRF and CORS abuse is based on cookies (or, if you're old-school, HTTP Basic and Digest Authorization values) being sent automatically. If the site doesn't use any of those - and no, Bearer doesn't count, even though it uses the same header as Basic and Digest - then you'll have to look for vulns that can be exploited by the attacker directly communicating with the server (e.g. stored XSS, SQLi, XML custom entities, IDOR, authz or authn bypasses, command injection, file path traversal, etc.)

Some sites use Bearer tokens but also set (and trust) cookies for authz/session management. Those sites are at risk of CSRF and CORS abuse, as it is the use of cookies that make a site at risk, not the absence of Bearer tokens.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.