CORS Is Stupid

Lots of stuff about this article is strange:<p>* The author first describes a mildly convoluted cookie-stripping middleware under &quot;Actually Solving The Problem&quot; and includes the much simpler `SameSite=Lax` cookie under &quot;Defense in Depth&quot; later on.<p>* The author neglects to mention that `SameSite=Lax` is the default on all major browsers (still good to set it, though), which basically blows up the premise of the article, that all your cookies are one cross-origin form away from being mis-used<p>* The author recommends _loosening_ the default CORS protections, which I guess makes sense if you think &quot;CORS Is Stupid&quot;, but definitely makes your server less secure for basically no reason.<p>The best way to deal with the Cross-Origin Resource Sharing restrictions is to simply set up your site so that it doesn&#x27;t need to make cross-origin requests: serve your site from the same domain that it makes requests to, and make sure you set your cookies with `SameSite=Lax`, `Secure`, and `HttpOnly`. I outline this approach in more detail here: <a href="https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;web-security-basics-with-htmx&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;web-security-basics-with-htmx&#x2F;</a><p>Also, while I still think that existing browser controls basically solve this problem, it&#x27;s true that POST forms have some sneaky vulnerabilities due to backwards compatibility concerns. One way to help fix that is by introducing PUT, PATCH, and DELETE to HTML forms—methods which don&#x27;t have the same CORS exceptions: <a href="https:&#x2F;&#x2F;alexanderpetros.com&#x2F;triptych&#x2F;form-http-methods" rel="nofollow">https:&#x2F;&#x2F;alexanderpetros.com&#x2F;triptych&#x2F;form-http-methods</a>

My biggest gripe with CORS is how the destination site needs to opt into it for requests of every kind. For instance, by default a cross-origin XMLHttpRequest or fetch() request <i>will not include cookies</i>, and if you ask it to include cookies, then the destination must include an Access-Control-Allow-Credentials header if you want the browser to allow it.<p>So that&#x27;s all well and good, except for the part where even requests <i>without cookies</i> still need an explicit Access-Control-Allow-Origin in the response. As far as I am aware, the only attack vector this protects against is when the destination decides to release sensitive information solely based on the IP address of the source, and not based on its cookies or any other information not already accessible to JS. (Obviously, the biggest instance of this is in the case of local network addresses, but there are efforts to further restrict cross-origin requests to such addresses, using a separate header, Access-Control-Allow-Private-Network [0].)<p>I find this a shame, since it means that it&#x27;s impossible to download most public data in a web app without proxying it through your own server, just because of this one edge case.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;WICG&#x2F;private-network-access">https:&#x2F;&#x2F;github.com&#x2F;WICG&#x2F;private-network-access</a>

This post doesn’t mention the other reasons the same origin policy was necessary: intranets.<p>If your company hosts content on <a href="https:&#x2F;&#x2F;company-news.corp.internal&#x2F;" rel="nofollow">https:&#x2F;&#x2F;company-news.corp.internal&#x2F;</a> it’s very important that some random malicious site on the internet can’t use fetch() or XMLHttpRequest to read that page and exfiltrate that information, just from one of your employees being tricked into visiting that site.<p>So it’s about more than just cookies.

Ideally TFA would have also explained why some requests do go through without a preflight. What&#x27;s called a &#x27;simple&#x27; request is the explanation behind TFA&#x27;s whole premise.<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;CORS#simple_requests" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;CORS#simpl...</a><p>These days, pretty much everything requires a non-simple request in order to invoke an action, regardless of whether the client can read the result.<p>Agree&#x27;d in spirit though that CORS is annoying to use, and it&#x27;s always worth consulting the manual.

I didn&#x27;t get this article. This first part explains common CSRF vulnerabilities, and then even explains the SameSite attribute, but it neglected to point out that SameSite=Lax is now the default on browsers, and has been for some time, specifically to mitigate the problems outlined in this article and to get rid of the need for CSRF tokens.

One of my favorite explanations of CORS is this one, which includes an interactive playground: <a href="https:&#x2F;&#x2F;jakearchibald.com&#x2F;2021&#x2F;cors&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jakearchibald.com&#x2F;2021&#x2F;cors&#x2F;</a>

&gt; It provides both opt-out protections as an attempt to mitigate XSS attacks<p>nitpick, I guess, but CORS is about CSRF (Cross Site Request Forgery) and not XSS (Cross Site Scripting). If you have an XSS bug, CORS can&#x27;t save you since they can make requests <i>from your origin</i>.

I was expecting a rant, but, wow, it was far better than that. This is a well founded criticism.<p>CORS is an afterthought that never carefully integrated into the ecosystem, which resulted in bad DX. It’s so blunt that applying CORS always feels like a hack.

I run into CORS issues often when fetching RSS feeds from browser Javascript [0], where the RSS provider has failed to currently set the Access-Control-Allow-Origin header<p>[0] <a href="https:&#x2F;&#x2F;porjo.github.io&#x2F;freshtube&#x2F;" rel="nofollow">https:&#x2F;&#x2F;porjo.github.io&#x2F;freshtube&#x2F;</a>

Do people use XSRF-tokens nowadays? That used to be the standard approach to this, before all browser CORS protection came to be. The server gives the client a token on the top level page, that must be included in any subsequent POST requests, while also requiring the cookies. Seems like a safer approach, unless you fully trust all browsers to get CORS correct.<p>It&#x27;s similar to the Authorization header technique, except you would normally submit it as a parameter in the POST request instead of headers. Explicit credentials are good but has some drawbacks, by being in the headers, you must submit it using fetch(), making it difficult to use in forms or &lt;a&gt;-tags, there the implicit credentials work smoother.

I know that CORS is stupid.<p>It took a CORS expert from W3C to answer this convoluted CORS question.<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;62289103&#x2F;same-origin-request-causes-access-control-allow-origin-doesn-t-match-error-th" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;62289103&#x2F;same-origin-req...</a>

It’s great when people learn things and write about it, that behavior enbiggens us all. But “X is stupid” screeds shows a lack of appreciation for historical context and why things are the way they are. No one had a grand design for the web and it is for better or worse a series of compromises.

You really should be using Content-Security-Policy to block untrusted scripts. And anything you do not host yourself should be untrusted, no matter how much your marketing department whines they want to include Google Tag Manager.

Every time I need to fiddle with CORS is CSP, I have to read the MDN pages for them, could never get them to stick intuitively. This is a nice article but more info on CORS would be nice.

Anytime who complains about CORS has my instant upvote, haha!<p>Seriously though, I think, like this guy suggests, if you avoid cookies on your site or use same site, your fine and cors is mostly a waste.

CORS is clunky. This article is not very good and I would not recommend just blindly following the advice given.

100% agree. CORS is very clunky

Wait what<p>The main premise of this post is false.<p>The mentioned request can’t succeed without first completing a preflight check.