What's the point of Access-Control-Allow-Credentials?

Viewed 446

The default value for sending cookies is SameSite=Lax, which means cookies are sent for GET requests, but blocked for POST.

With a cross origin GET request, the response is blocked anwyay due to the Same-Origin-Policy, unless the response contains Access-Control-Allow-Origin.

Why isn't Access-Control-Allow-Origin enough?

Why would you ever want to return Access-Control-Allow-Origin: someDomain.com without also returning Access-Control-Allow-Credentials?

Why allow a cross origin GET request from a trusted domain, but block the response only if the cookie was sent?

1 Answers

Allowing cross-origin sharing is much riskier in the presence of cookies, since that's what can reveal a user's private information to a malicious script. Without cookies, the script can only access public information—the same information that could be accessed by just navigating to the URL from any computer.

So the existence of the Access-Control-Allow-Credentials marks an important security inflection point, and usefully distinguishes between sharing public and private information.

For example, let's say you have an API that's distributing stock ticker data and you want to allow scripts from other sites to access this API. CORS is necessary since the Same Origin Policy will otherwise prevent those scripts from seeing the data. There's no need for cookies, though. So the site can simply use * for Access-Control-Allow-Origin and be done. There's no risk of sharing any private data.

By contrast, a site that wants to enable the sharing of user-specific data will have to opt-in by setting Access-Control-Allow-Credentials to true. Moreover, the site is forced to specify the specific sites allowed, since * is not valid for Access-Control-Allow-Origin in this case.

Related