I found a website which is vulnerable to cors.(https://portswigger.net/web-security/cors)

GET /api/requestApiKey HTTP/1.1.
Host: vulnerable-website.com.
Origin: https://evil.com.
AUTHENTICATION: eyssdsdsdsasa.....

And the server responds with:

HTTP/1.1 200 OK.
Access-Control-Allow-Origin: https://evil.com.
Access-Control-Allow-Credentials: true.

I can see that the website is vulnerable to cors, but I am unable to access website data as it uses an authentication header rather than cookies.

How can I still do the attack. What impact can i show as of now? .


1 Answer 1


By "vulnerable to cors" I assume you mean "has a vulnerable CORS misconfiguration", since CORS is not an attack and is not inherently a weakness (it's a way to relax the sometimes over-zealous "same-origin policy" of browsers).

There are only two ways that CORS can be dangerous:

  • If you're authenticating the client / authorizing requests using cookies or other auth that is sent automatically (HTTP Basic, HTTP Digest, Kerberos, or TLS client certificates), CORS misconfiguration can lead to everything from CSRF to complete compromise of account data and permissions.
  • If you're authorizing requests based on where the request is coming from (e.g. a service that is only accessible from loopback addresses but has no other access controls can be said to authorize requests only if they come from the local machine), then CORS can be used for "confused deputy" attacks, where a malicious outsider can tell a trusted device to make requests which are in turn trusted based on their location.

Most likely, neither of these apply here. They seem to be using a custom header for authentication (normally I'd expect a Bearer token, but it doesn't matter; the point is it won't get sent automatically and the attacker won't know it), which at least implies that they aren't relying on the request originating from a trusted device. Access-Control-Allow-Credentials means nothing here, since the server isn't expecting any credentials that it applies to (the ones that the browser can automatically include, like cookies or HTTP Basic auth).

How can I still do that attack.

You can't. The site is not vulnerable to the attack you seem to think it's vulnerable to.

What impact can i show as of now?

They probably don't need to support CORS, much less with arbitrary origins and ACAC: true; you could tell them they should switch to Access-Control-Allow-Origin: * if they really need to allow all sites, or limit the ACAO responses to specific trusted sites, or drop CORS support altogether. However, this is purely defense-in-depth stuff; I wouldn't call the severity even "Low" but rather "Informational".

  • Thanks a lot, I understand it now, do you know if I can use javascript to send that header value ? Commented Apr 23, 2022 at 20:19
  • Not sure which header value you mean. Client-side JS (in the browser) can send the authentication header if the caller knows it, although if the request is cross-origin then this will trigger a "CORS preflight" request first to see if the server wants to allow the other origin to send such headers. Access-Control-Allow-... headers are response headers (sent from the server to the client) and can be sent from any web application/service server using whatever programming language the server uses (which, if it's Node.JS, is Javascript).
    – CBHacking
    Commented Apr 24, 2022 at 6:18

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