1

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?

  • is that your api or another application ? – pfaclix Dec 3 '18 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 Dec 3 '18 at 12:56
  • 1
    This is a vulnerability because you can avoid preflighting. There's some info here – paj28 Dec 3 '18 at 13:32
  • 1
    I don't see how I can avoid preflight requests here. Could you elaborate? – Dolores The Third Dec 3 '18 at 13:48
0

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 | |
0

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; the server for the other origin could just send its own request to the target site, retrieve the resource that is available unauthenticated, and send it with the response. 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 a vulnerability; this is wrong and their developers should feel bad.

| improve this answer | |

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.