Since application is not responding with allow credentials header, an attacker can't craft cross domain request with cookies, but I was wondering if allow origin * alone (Without credentials being true) can be exploited?

I know allow origin can't be * if allow credentials header is true, what am asking is that is this alone a flaw, is this exploitable in any way?

  • This fully depends on your unknown application. Can anything be done there without cookies? Mar 10 at 18:28
  • No, without cookie there's no way to identify a user. Does this mean ACAO header being * is useless in this case?
    – Jack
    Mar 11 at 6:21
  • Does everything in your application even require a user? Again, this question cannot be answered with the current amount of information. Mar 11 at 7:28
  • Yes, most part of the application is only available to authenticated users which requires cookies.
    – Jack
    Mar 11 at 7:55
  • 1

No, if the server's API follows REST principles (which it should).

If in a fetch with GET you set credentials: "include" then the request will be performed and credentials will be included. But:

  1. response's content won't be made available to the browser when either Access-Control-Allow-Origin: * or Access-Control-Allow-Credentials: false (or if either of them is missing). So the client won't be able to read the response even if the server responded with something user-specific.
  2. since this is a GET request then the server shouldn't do anything state-changing (this is the "follow REST" part)

Using POST, PUT or DELETE in a cross-origin fetch with credentials: "include" will require a preflight request beforehand -- to ask the server if these methods are allowed to be performed with credentials. So if the server does allow credentialed state-changing requests then it must reply to the preflight with headers Access-Control-Allow-Origin: https://the-clients-origin.com and Access-Control-Allow-Credentials: true.

(There is a slight exception to the previous for POST requests with content-types either application/x-www-form-urlencoded, multipart/form-data or text/plain. These are there for cross-origin form-submit handlers (someone correct me on this).)

Read more on MDN: CORS: Simple requests or Fetch specification.

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.