2

I'm testing an API, which allows an arbitrary origin on POST/GET requests, by responding with the CORS header Access-Control-Allow-Origin: *.

However, with OPTIONS requests and an arbitrary origin, the web service does not respond with Access-Control-Allow-Origin: *, it does not use the response header at all.

This means that any CORS preflight requests with an arbitrary Origin, would fail.

I don't see the point in having the CORS response header for GET/POST requests, but not the OPTIONS request. However, I also can't provide an example for a vulnerability or how this may be exploited.

Q: Is it safe to say that does not pose a vulnerability, but is just bad practice?

Improve this question
5
  • is that your api or another application ?
    – pfaclix
    Commented Dec 3, 2018 at 12:53
  • No, I've been tasked to perform a penetration test. It's an API used by mobile applications and directly by developers in the backend.
    – Dolores The Third
    Commented Dec 3, 2018 at 12:56
  • 1
    This is a vulnerability because you can avoid preflighting. There's some info here
    – paj28
    Commented Dec 3, 2018 at 13:32
  • 1
    I don't see how I can avoid preflight requests here. Could you elaborate?
    – Dolores The Third
    Commented Dec 3, 2018 at 13:48
  • I've noticed that Cloudflare for Teams exhibits the behaviour described by the OP.
    – jub0bs
    Commented Sep 9, 2021 at 13:39

2 Answers 2

Reset to default
1

Q: Is it safe to say that does not pose a vulnerability, but is just bad practice?

Since it's an API and assuming it requires Authorization header for all requests, it's safe to say that it doesn't pose a vulnerability. The behavior, however, limits communication to same-domain.

It's worth noting that not all requests are preflighted. Please refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests for more details.

An API expects, if properly configured, a proper Content-type header and an authorization header which in most cases is Authorization. If a request sets a "forbidden header name" or an unsafe Content-type, it's always preflighted. And as such, no other domain would be able to send an authenticated request at all.

Improve this answer
1

This is simply a way to allow browsers to make unauthenticated requests against the site, but not authenticated ones. Access-Control-Allow-Origin: * doesn't support authenticated CORS requests anyhow - it's a violation of the spec to specify that and also specify Access-Control-Allow-Credentials: true and conforming browsers would ignore that - but simple (GET/POST/HEAD, no custom headers, only content types supported by HTML forms) requests made without credentials will work fine and the requesting site will be able to see the response.

There's no security impact of configuring CORS this way EDIT: provided that the server doesn't have any non-credentials-based authorization (that is, it doesn't trust any clients based purely on things like being on the same LAN or loopback server, or the request coming from a specific IP); the server for the other origin (or any host controlled by a hypothetical attacker) could just send its own request to the target site, retrieve the resource that is available unauthenticated, and send it to the browser. The advantage to setting this header is that the server can say "hey, go ask some other site for this info yourself" and the client-side code will be allowed to do that (this reduces other-origin server activity and network load, and exposes where the requests are ultimately coming from to the target site).

Some web scanners still report Access-Control-Allow-Origin: * as inherently vulnerable; this is wrong and their developers should feel bad.

Improve this answer
8
  • a way to allow browsers to make unauthenticated requests against the site, but not authenticated ones. The OP writes that the preflight response doesn't contain any Access-Control-Allow-Origin. In that case, if the resource is accessed via a CORS request, there's no way its preflight check would succeed.
    – jub0bs
    Commented Sep 9, 2021 at 13:43
  • True, but irrelevant to security (unless the API server is not publicly accessible). The point I was making about ACAO: * is that it's not security-relevant (and gave the reason why it exists at all). The fact that it won't work for non-simple CORS requests is still not going to impact security at all (though it might be inconvenient for third parties that want to use the API for something).
    – CBHacking
    Commented Sep 9, 2021 at 21:48
  • A ACAO: * CORS policy is relevant to security in some contexts; see, for example, security.stackexchange.com/questions/227779/…
    – jub0bs
    Commented Sep 10, 2021 at 5:52
  • 1
    I specified the context, @jub0bs. "(unless the API server is not publicly accessible)". I suppose "publicly accessible" is too specific - the actual case is "unless the API server is reachable from the victim's browser but not from any host the attacker controls" - but it rounds off pretty well to "not publicly accessible". I'll edit it into the answer though.
    – CBHacking
    Commented Sep 10, 2021 at 7:40
  • 1
    Huh! Header names are often case-insensitive, I guess it's not a shock for values to be case-sensitive, but I wouldn't have predicted it. Fixed, and thanks for the tip!
    – CBHacking
    Commented Mar 11, 2023 at 12:13

You must log in to answer this question.

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