1

This question already has an answer here:

I'm looking at the following setup. A web application uses a REST API to communicate with the server. All API responses include Origin: *. For authorization Authorization: Bearer <token> is used. Access-Control-Allow-Headers: Authorization is also included for appropriate preflight requests.

As Origin: * is configured, modern browsers will not send authorization data, such as the bearer token.

This makes it impossible to use API requests across domains, which require authorization.

I'm struggling to justify, why this should be considered a vulnerability. It is bad practice to allow any origin. It could lead to data leakage, but not in this scenario.

Could this be exploited in another way, I'm not seeing right now, or is this in fact just bad practice and does not pose an actual threat?

EDIT: The CORS response headers are (Origin: * is a request header):

Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Authorization

marked as duplicate by tim, Xander, Steffen Ullrich, MechMK1, Benoit Esnard Jun 19 at 14:09

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • What confuses me about your question is that Origin: is a request header. So it doesn't in any way alter the security-settings of the browser for that particular host. What are the actual CORS settings of the server? The actual response header which defines whether or not the Authorization header will be sent along with requests is "Access-Control-Allow-Credentials: ". But when Access-Control-Allow-Credentials is set to true, Access-Control-Allow-Origin cannot contain *, allowing any hosts making requests with credentials attached. – Martin Fürholz Jun 14 at 14:04
  • Also, are you worried about the security of the server, or of the web application? – Martin Fürholz Jun 14 at 14:07
  • @MartinFürholz, you're absolutely right. I've adjusted the post. – GarlicCheese Jun 17 at 7:19
2

ACAO: * will prevent the browser from automatically sending any form of credentials, but that's only relevant for the kinds that the browser can actually send automatically (cookies and HTTP BASIC, DIGEST, and NTLM auth). HTTP auth does use the Authorization header, but not with a Bearer token. Because ACAH: Authorization is specified for both the pre-flight and the actual request, the caller is completely free to explicitly attach an Authorization header (with any value at all, including a Bearer token). The difference is that the caller needs to actually know the value to put in that header; it won't be automatically added by the browser.

Given that the attacker would already need to know the bearer token and that the browser isn't automatically including any secrets with the request, there is no security vulnerability here at all. Allowing the browser to make such authorized requests from arbitrary origins is fine; it's exactly equivalent to the browser making a same-origin callback to its own server, and having the server send the request (which would ignore CORS because most HTTP client libraries don't even have a concept of the same-origin policy) and relay the response back to the browser. In other words, this is no greater security risk than any other web service protected with a Bearer token.

Of course, this is all assuming that the web service is supposed to be reachable from arbitrary addresses. If it's not - if for example it's only supposed to be reachable by one company - then it would make a little sense to restrict the allowed origins more tightly. Only a little, though, because anybody with an HTTP client library (and the bearer token, without which the attacker cannot do anything if the auth is otherwise solid) can make requests all day, unless there's also something like an IP whitelist.

The primary and critical part of the security of the service, as you've described it, is the bearer token. To a first approximation, nothing else matters.


With that said, there are of course many other potential vulnerabilities to check for. Obviously, you should verify that the Bearer tokens are at least as secret as the information they authorize access to; it's no good to require authorization to access a web service and then push the required authorization data to a Git repo, for example. Similarly, make sure the valid Bearer tokens cannot be guessed, brute-forced, or found via timing attack. There are lots of ways to screw up auth, and even more to screw up web services in general (is it available over HTTP, or via weak HTTPS cipher suites? Does it have deserialization or XML DTD vulns? Standard web security stuff).

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