0

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?

6
  • This fully depends on your unknown application. Can anything be done there without cookies? Mar 10, 2021 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, 2021 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, 2021 at 7:28
  • Yes, most part of the application is only available to authenticated users which requires cookies.
    – Jack
    Mar 11, 2021 at 7:55
  • 3
    Does this answer your question? Concrete example of how can Access-Control-Allow-Origin:* cause security risks?
    – jub0bs
    Sep 9, 2021 at 15:38

2 Answers 2

1

Is there an issue if application responds with access control allow origin * but there is no allow credentials header?

This question is literally exactly the same as:

Is there an issue if application responds with access control allow origin *?

And that question is already answered at Concrete example of how can Access-Control-Allow-Origin:* cause security risks?

Beyond that, CORS does not inherently prevent CSRF attacks; you still need a way to block those. That's true even if you don't return any ACAO: header at all, though.

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

2
  • 1
    This is wrong in multiple ways! Perhaps most centrally, POST requests do NOT inherently require pre-flights! POST might require a preflight depending on conditions, but so can GET. The distinction is "simple" requests (those that could be made using an HTML form, which does allow POST) aren't preflighted; everything else is. CORS does not inherently prevent CSRF!
    – CBHacking
    Dec 6, 2021 at 22:58
  • @CBHacking The original question isn't about whether something requires a preflight or not and also not directly about CSRF, but about whether access-control-allow-origin: * can be exploited. So for GET and HEAD regardless of if there is a preflight or not they shouldn't be exploitable as per REST they shouldn't cause a state change on the server, neither won't they show the response if credentials were included. The exception content types where a POST request doesn't require a preflight are mentioned at the end in parenthesis. Surely the answer could be improved, but how? Dec 7, 2021 at 13:47

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.