Cross-origin resource sharing relaxes a browser rule that exists for good reasons, and a careless policy hands your users’ data to any website they visit. The dangerous combination is reflecting whatever origin the request carries while also allowing credentials. OWASP documents the pattern because it appears constantly in applications that added an API for a front end and configured sharing by trial and error.
What the headers actually do
Access-Control-Allow-Origin names which site may read a response. Access-Control-Allow-Credentials decides whether the browser sends cookies with the cross-origin request and lets the calling page read the result. Browsers refuse to combine a wildcard origin with credentials, which is why developers implement dynamic reflection instead: read the Origin header, echo it back, and set credentials to true. That works for the front end and it also works for an attacker’s site, because their origin is reflected just as faithfully.
See also: The Economics of Technology Development
The variations testers check
Reflection is the obvious one and it is rarely alone. Null origin is accepted by some implementations and can be produced from a sandboxed iframe, which turns a supposedly restricted value into an easy bypass. Sloppy matching is the other common failure: a check for a domain appearing anywhere in the origin will accept a hostile domain that contains your name, and a check on the start of the string will accept a subdomain the attacker controls elsewhere. Testers work through these systematically because each takes seconds and any one of them is enough. Preflight handling deserves the same attention, since a permissive response there can allow methods and headers the main handler never anticipated.
“The proof of concept for this finding is what changes minds. We host a page, the client visits it while signed into their own application, and their account data appears on our page in front of them. Nothing is exploited on their server. The browser was simply told that our site was allowed to read the response.”
William Fieldhouse, Director, Aardwolf Security Ltd
Writing a policy that holds
Keep an explicit list of permitted origins and compare against it exactly, including the scheme and the port. Return the specific origin from your list rather than the one the request supplied, and set the Vary header on Origin so caches do not serve one site’s permitted response to another. Only enable credentials where the endpoint genuinely needs an authenticated session across origins, and consider whether a token in a header would remove the need entirely. Internal APIs should not be reachable cross-origin at all. Log rejected origins for a fortnight before enforcing a new policy, which shows you exactly which legitimate callers you were about to block.
Checking it in the right places
Test every endpoint rather than a sample, because policies are frequently applied by middleware on some routes and by hand on others. Include preflight responses, since a permissive answer to an OPTIONS request often reveals a policy the main handler does not share. Web application security testing services cover the browser-facing behaviour, and API endpoint testing catches the routes that only a mobile client or partner integration uses, which are the ones most likely to have a policy written in a hurry.
Frequently asked questions about CORS
These questions come up when a front end and an API are on different domains.
Does CORS protect the server?
No. It is a browser control governing which pages may read responses. Anything with a scripted client can call your endpoint regardless, so authentication and authorisation still do the real work.
Is same-site cookie configuration a substitute?
It helps considerably against cross-site request forgery and does not replace a correct sharing policy. Use both, because they address different halves of the problem.
