Cache your CORS

Unfortunately this caching is still per-path. For example:<p><pre><code> GET &#x2F;v1&#x2F;document&#x2F;{document-id}&#x2F;comments&#x2F;{comment-id} </code></pre> For every new document-id or comment-id, there will be a new pre-flight request.<p>Alternative hacks: Offer a variant of your API format that either<p>1. Moves the resource path to the request body (or to a header that is included in &quot;Vary&quot;). Though the rest of your stack (load balancing, observability, redaction) might not be ok with this, e.g. do your WAF rules support matching on the request body? You also will no longer get automatic path-based caching for GET requests.<p>2. Conforms to the rules of a CORS &quot;simple&quot; request [1], which won&#x27;t trigger a pre-flight request. This is what we did on the Dropbox API [2]. You&#x27;ll need to move the auth information from the Authorization header to a query parameter or the body, which can be dangerous wrt redaction, e.g. many tools automatically redact the Authorization header but not query parameters.<p>[1] <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>[2] <a href="https:&#x2F;&#x2F;www.dropbox.com&#x2F;developers&#x2F;documentation&#x2F;http&#x2F;documentation" rel="nofollow">https:&#x2F;&#x2F;www.dropbox.com&#x2F;developers&#x2F;documentation&#x2F;http&#x2F;docume...</a> (see &quot;Browser-based JavaScript and CORS pre-flight requests&quot;)

I built fetch-robot (<a href="https:&#x2F;&#x2F;github.com&#x2F;krakenjs&#x2F;fetch-robot" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;krakenjs&#x2F;fetch-robot</a>) to avoid dealing with CORS preflight requests. And the associated maze of request and response headers you need to use to negotiate in the preflight.

Hey, I&#x27;m the author of this post, thanks for sharing it @aloukissas!<p>I&#x27;ve also built a tiny &quot;just tell me what to do&quot; SPA for debugging your CORS configurations that everybody reading this might find useful too: <a href="https:&#x2F;&#x2F;httptoolkit.tech&#x2F;will-it-cors&#x2F;" rel="nofollow">https:&#x2F;&#x2F;httptoolkit.tech&#x2F;will-it-cors&#x2F;</a>

Sorry I am not an expert, but just wanted to raise that I recall that in our firm we had to disable CORS caching a while back, as this was non compliant with some security standards. I think it had to do with this: <a href="https:&#x2F;&#x2F;vulncat.fortify.com&#x2F;en&#x2F;detail?id=desc.dynamic.html.html5_cors_prolonged_caching_of_preflight_response" rel="nofollow">https:&#x2F;&#x2F;vulncat.fortify.com&#x2F;en&#x2F;detail?id=desc.dynamic.html.h...</a>

&gt; In practice, almost all cross-origin API requests will require these preflight requests, notably including<p>At Clerk, we took the opposite approach, and restructured our API so it fits within the narrow window that does not require a preflight<p>I wrote a little about it here: <a href="https:&#x2F;&#x2F;clerk.dev&#x2F;blog&#x2F;skip-cors-options-preflight" rel="nofollow">https:&#x2F;&#x2F;clerk.dev&#x2F;blog&#x2F;skip-cors-options-preflight</a>

Very good and important advice, would advise caution when implementing this though - consider a shorter period when you make changes to CORS headers so that if you make a mistake you don&#x27;t accidentally cut off your frontend for 24 hrs. I guess you could hack your way around it in an emergency but it&#x27;d still be painful.

Excellent suggestion.<p>These days chrome hides the preflight requests by default and you miss to notice the latency added for each of those CORS calls.<p>Also we don&#x27;t deal with CORS unless it&#x27;s an external plugin that we include in our site. Earlier we had subdomains like api.<i>.com, static.</i>.com to parallelize network requests which required CORS to be setup. With H2 we got rid of all of them and load everything from a single domain. This reduced the CORS surface area.

Access-Control-Max-Age has, unfortunately a big security caveat which is that it is cached on a per-endpoint basis. Because Access-Control-Allow-Origin only allows one origin specification, if you previously used the Origin header to determine who could access the API, your next API requestor will effectively get your last response.<p>For example, to allow abc.com AND bcd.com, you could check Origin and if correct return Access-Control-Allow-Origin: *. In this case, setting Access-Control-Max-Age will mean this applies to <i>any site* after a single successful request. If you return the site&#x27;s name, this will </i>break CORS* for that amount of time if an attacker makes a single request to it.

I&#x27;m a big fan of &quot;BFF&quot; (Backend For Frontend), which among other benefits, sidesteps CORS altogether. See eg <a href="https:&#x2F;&#x2F;remix.run&#x2F;docs&#x2F;en&#x2F;v1&#x2F;guides&#x2F;bff" rel="nofollow">https:&#x2F;&#x2F;remix.run&#x2F;docs&#x2F;en&#x2F;v1&#x2F;guides&#x2F;bff</a>

Damn, I am kinda surprised we don&#x27;t have this enabled on our site. Thanks for dropping this tonight.

We just use a path prefix and a reverse proxy to save the pre-flight request altogether.

This is a good practical article. One minor clarification:<p>&gt; cross-origin API requests will require these preflight requests, notably including: … Any request including credentials<p>No, setting XMLHttpRequest’s withCredentials:true and fetch’s credentials:&quot;include&quot; to send the user’s Cookie with the request does <i>not</i> imply that a preflight request must be made, since &lt;script&gt; and &lt;form&gt; sent the Cookie with cross-site requests (back in the CSRF days when the default Cookie SameSite flag was effectively SameSite=None). Maybe he was referring to a custom header such as Authorization, which does trigger prefetch.

I hate cors, the biggest pain in the ass I have to constantly deal with.

Doesn&#x27;t moving the API from the subdomain to the &#x2F;api path on the same subdomain as the website solve the problem?

A quick hack is to cache OPTIONS in Varnish.

Wow, thank you, never heard about this before. I really hope this is not entirely correct but I will check our sites for sure. If options requests often bypass the edge servers some of the services we use are way better than expected.

CORS = Cross-Origin Resource Sharing.<p>There, that wasn&#x27;t so hard, was it? I assume this is written for web developers who find this the most familiar acronym in the world, but ... still, it would not kill anybody to include the definition of the acronym, perhaps even with a friendly link [1] to make it Even More Accessible.<p>I&#x27;ll be off looking at the lawn mowing robot, now.<p>[1]: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;CORS" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;CORS</a>