New answers tagged

1

Burp is Very Concerned about CORS for some reason. Non-credentialed CORS requests can be a vulnerability, but only if the server (or endpoint) authorization is based on something other than credentials/authentication, and specifically is based on request source. For everything else, it's a non-issue; any attacker could just directly make the request ...


2

Your browser will not show the ACAO policy for the currently displayed page, because ACAO policies are request-specific rather than being tied to the current document. You can see the HTTP response headers sent by the server using developer tools, and the console should log any errors related to ACAO when you attempt to access a cross-origin resource. ...


0

The browser's handling of a CORS response is readily visible both via javascript (is the response body readable? are any other fields, such as headers that were supposedly exposed, visible?) and in the developer tools (insufficient CORS permissions, or other CORS violations, will cause errors in the console). I could not find any requirement in the ACAO spec ...


0

If you're wondering whether the behaviour you described can be abused, I can think of at least one exploit (described by James Kettle, from PortSwigger) that can lead to the equivalent of stored XSS, but only under certain conditions: The value of the Origin request header gets reflected verbatim in the Access-Control-Allow-Origin response header can have ...


1

Things have changed since this question was asked and answered. Support for Access-Control-Allow-Headers: * in responses to non-credentialed requests was added to the Fetch standard in 2017. The feature was implemented in major browsers shortly after that. See the relevant section of the MDN page about that response header: The value "*" only ...


0

I am also confused about this, my understanding is like this. For an origin in the Access-Control-Allow-Origin, it can read sensitive information from the server on behalf of authorized users. But for others, the browser will block them. And more than that. When the browser sends cookies and the server returns sensitive information related to the user based ...


0

No need to test your CORS policy to tell you that it's misconfigured, in this case: *.domain.com is simply not a valid value for Access-Control-Allow-Origin. No conformant browser will allow any CORS request (from any origin) through, because the preflight request will just fail. The values that the Access-Control-Allow-Origin can take are limited to null, ...


3

[S]uppose website B set the header Access-Control-Allow-Credentials to false, and Access-Control-Allow-Origin: *, can this cause any concrete security risk to the user who is browsing website A (suppose website A is malicious)? Access-Control-Allow-Origin: * can be too permissive In particular, consider a situation in which site B is accessible by an ...


Top 50 recent answers are included