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?

Jack
  • 1

2 Answers2

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.

CBHacking
  • 48,401
  • 3
  • 90
  • 130
-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.

Cigarette Smoking Man
  • 101
  • 4
  • 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 06 '21 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?

     – Cigarette Smoking Man Dec 07 '21 at 13:47