You don't need that CORS request

You don't even need an SPA. Having the backend + frontend share the same state makes development so much faster and easier it's shockingly refreshing. When building a SaaS project last year I decided to just ditch React/Angular/Vue and did everything server-side like it was 2005. I was extremely pleased at the result -- everything feels snappy, secure, and native for the browser. I was shocked at how much time and headache I saved: not having to design/deploy an API and all the trimmings (ACLs, CORS, JWTs etc.), not having to spend X hours a day wrestling with Webpack/hot reloading/npm/tree-shaking/state management, having direct access to backend secrets/state/APIs and just spitting out HTML, it's just so....lovely. It simplifies performance tuning as well, the only thing I need to optimize is the server, which is easy to do because I have 100% control and visibility, compared to debugging/optimizing JavaScript for a million different clients.

CORS is such an ugly web standard. It&#x27;s not only a pain in you butt, but it also makes your requests slow through these extra pre-flight round-trips.<p>I have hope that we can remove it, though, in new versions of HTTP.<p>CORS only exists because XMLHTTPRequest broke the assumptions of web 1.0 servers. Suddenly any web browser loading any page anywhere could make a request to your server without the user&#x27;s explicit permission, and a ton of web servers had already been built and were running under the assumption that users would only hit their endpoints by explicitly typing in a URL or clicking on a link.<p>But each time we design a new version of HTTP, we get an opportunity to remove CORS restrictions for it, because there aren&#x27;t any servers running the new version yet.<p>And with Braid (<a href="https:&#x2F;&#x2F;braid.org" rel="nofollow">https:&#x2F;&#x2F;braid.org</a>), we&#x27;re making changes that are big enough that I think it really warrants taking a fresh look at all of this stuff. So I have hope that we can eliminate CORS and all this ugliness.

The irony in this is that with CloudFront at least, it can&#x27;t strip the &quot;&#x2F;api&quot; prefix before sending it to your backend, so you have to have your backend server understand &#x2F;api&#x2F;xyz rather than just &#x2F;xyz calls like when it was on a dedicated api subdomain.<p>But don&#x27;t worry! AWS thought of this! They invented Another Cloud Thing, namely Lambda@Edge, to solve this. Now you can run a JS function for every single request that hits your CloudFront Distribution so that you can run logic in there to strip the prefix before it gets passed to your origin. You read that right! Execute code every time a request hits your proxy! But wait, doesn&#x27;t executing code for every single request sound insane AND doesn&#x27;t it also add latency which this was trying to remove? Yes! Isn&#x27;t cloud just lovely?

Recently chrome required COOP and COEP for shared memory access, which essentially restricts any access to anything besides the same origin. This basically killed my project&#x2F;motivation of 2~ years.<p>Using Emscripten and threads, you require COOP &amp; COEP headers to be sent via the main document. This is not common practice for static html hosting sites, thus requiring that you have access to a config file or .htaccess, and requires ALL assets to be hosted exclusively on that same server.<p>Killing my project is a bit extreme, but killed my motivation.<p>It&#x27;s a web-based game with multiplayer that I was hoping people would modify and expand on, hosting themselves, uploading to places like Github.<p>I&#x27;ve recently started modifying Emscripten&#x27;s runtime library to try and treat each webworker as a separate instance that just communicates between each other. This has major overhead as each thread is a new memory instance. I&#x27;ve tried getting it to extract each function into it&#x27;s own module for a webworker to load but that&#x27;s a major task.<p>Web apps want to act as desktop applications but they&#x27;re so held back by security it&#x27;s nearly impossible. We don&#x27;t even have a proper local storage system.<p>To quote Dilbert, &quot;Security is more important than usability. In a perfect world, no one would be able to use anything.&quot;

What is the author trying to say, it is very hard to recognize the answer of the article.<p>Is it to point requests to sub path of the main domain to reduce OPTIONS requests? eg: api.example.com ---&gt; example.com&#x2F;api<p>In that case why not use proper &quot;Access-Control-Max-Age&quot; headers?<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;Headers&#x2F;Access-Control-Max-Age" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;Headers&#x2F;Ac...</a>

I&#x27;ve struggled with this exact problem. A client developed a SPA and an API to go with it. Because &quot;reasons&quot; they wanted the API to live on api.customersite.com. Fair enough, that&#x27;s their problem. Except it&#x27;s not, because the developers have no idea how CORS work, only that it&#x27;s a thing. So their API can&#x27;t send CORS headers back, they never implemented that and apparently can&#x27;t figure out how to make it work.<p>Instead, we now have a reverse proxy (haproxy) that &quot;fixes&quot; the missing CORS headers, by intercepting the OPTIONS call and return a dummy response with the correct headers included. The developer basically understand NOTHING in regards to CORS, so whenever the silly SPA breaks, the logic is always the same: &quot;CORS is broken, fix it&quot;. At not point has it been an option to fix the API service to include the correct headers.<p>We could just have moved the API to &#x2F;api and saved days of debugging and writing work-arounds, but no, api.customersite.com looks more professional.

From my experience, when you want to have 12 factor apps and just build your Frontend&#x2F;backend once, and don’t want to leak absolute urls in the Frontend code, you are better of with relative URL’s anyways, i.e. &#x2F;api for your api, and let a reverse proxy do the proper mapping to your services.<p>Then of course you don’t need CORS

Before you start rearchitecting your app, be sure to check if the only reason you&#x27;re seeing preflights on GET is that someone added a dumb X-Requested-By header.<p>(You can even do POSTs without preflight if you use a whitelisted content-type.)

This will result in fewer requests, but the author didn&#x27;t provide any test results demonstrating that the server load was appreciably reduced. Since the preflight OPTIONS request will be cached, it will only occur for some fraction of the total volume of requests. Since those requests are also very low impact, I&#x27;m skeptical that this pattern will have a consequential impact for most APIs.

The author mentions Cloudflare as having the ability to rewrite requests from `api.website.com&#x2F;*` to `website.com&#x2F;api&#x2F;*`. Is that functionality available as a page rule or would we have to use workers and pay for every request rewritten?<p>I remember taking a look at this a while ago and only found ways to do this through workers, so was turned off by the potential cost scaling. Ended up just setting a high `Access-Control-Max-Age` and calling it a day. But maybe I&#x27;ve missed a more cost effective way to accomplish this?

Or you can have the browser cache the CORS header for up to 2 hours (cross-browser), for the same performance effect - but it will also work for third party website consumers of your API that you can&#x27;t just put on your domain.

Here is an extensive step-by-step tutorial which describes in detail how to create and deploy a React-based web app frontend using TypeScript and Redux Toolkit on top of a Node.js based AWS Lambda backend with a DynamoDB database, connect and integrate them through API Gateway and CloudFront, and explains how to codify and automate the required cloud infrastructure and deployment process using Terraform.<p>The resulting architecture does not require any CORS requests, too:<p><a href="https:&#x2F;&#x2F;manuel.kiessling.net&#x2F;2021&#x2F;05&#x2F;02&#x2F;tutorial-react-single-page-applications-spa-with-a-serverless-aws-api-gateway-and-lambda-and-dynamodb-backend-and-terraform-infrastructure-as-code&#x2F;" rel="nofollow">https:&#x2F;&#x2F;manuel.kiessling.net&#x2F;2021&#x2F;05&#x2F;02&#x2F;tutorial-react-singl...</a>

imho CORS is poorly designed mechanism, you should be able to flag api.domain.com as a safe place, making a single cors request at start of user interaction with your app. Also some sort of caching should be more than welcome.<p>On a side note at previous company I&#x27;ve worked at, speed was critical, so we were forced to do same tactic, use &#x2F;api instead of api.domain.com which resulted in huge improvements :)

My favorite way to avoid preflights is to have Next.js handle the reverse proxy. It fits my mental model better to have it code-side instead of putting Cloudflare&#x2F;Fastly in front.

Does this work if you want to allow an iframe to execute code in a parent browser window from a different domain? (Assuming you control both domains and can inject a different Sec-fetch-mode header into the parent page)?<p>Context here: I&#x27;m maintaining a PWA that has to run on local iphones&#x2F;android devices and maintain contact with a server on local networks in the 127.x block. But the point of download for the app itself is under an https domain on the open internet. It uses an iframe to check lots of local 127.x.x addresses until it finds one with a local server, and bootstraps itself to the code on the local server that way; unfortunately, it can&#x27;t run as a true PWA because the iframe at the center of it violates CORS (due to the ban on mixing clear and SSL requests in the more recent versions of Chrome and Safari). Would be nice if the local servers could simply serve up their content and control the window without a whole domain-specific postMessage protocol.

Is avoiding the OPTIONS request as simple as keeping a fetch to the same origin? I thought there were all kinds of rules for something to be considered a &quot;simple request&quot;, like it can&#x27;t be JSON, can&#x27;t be PUT or DELETE, etc. I haven&#x27;t looked much into this but does someone have a clear answer?

Hint for those who didn&#x27;t fall for cloud behemoths vendor lock. Deploying your app to plain VPS you still need a reverse proxy like nginx to handle raw requests and terminate TLS. So it is natural to let it do the routing part too.

Aren’t `OPTION` requests useful when you want to build an actual REST API and not what most devs call everything having an HTTP interface? The clients can use the requests to understand which actions they can apply to the resources.

I was interested to note that the Dropbox API offers a hack to avoid the extra CORS request - among other details, their server accepts this:<p>- Set the Content-Type to &quot;text&#x2F;plain; charset=dropbox-cors-hack&quot; instead of &quot;application&#x2F;json&quot; or &quot;application&#x2F;octet-stream&quot;. [0]<p>...which is allowed in a &quot;Simple&quot; request that doesn&#x27;t require a separate round trip for OPTIONS.<p>[0] - <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>

Is there any way to read the OPTIONS response from JavaScript?<p>I&#x27;m guessing not, but if there was, theoretically could you just include your API response in the CORS rejection response?

Please use Access-Control-Max-Age instead. CORS has some nice security properties.

I don’t understand what the article is actually recommending. To avoid CORS requests, I usually proxy www.foobar.app&#x2F;api to api.foobar.app, but it seems like the article is suggesting the opposite.

Looking at some of my HTTP requests, I noticed that<p>* `Sec-Fetch-Site: cross-site` can be `Sec-Fetch-Mode: no-cors`<p>* `Sec-Fetch-Site: same-origin` can be `Sec-Fetch-Mode: cors`<p>It looks like all four combinations of these two headers are possible.

This is quite timely, was getting frustrated with some CORS issues last night because I am using the domain &amp; api.domain schema. Will have to give this a try.

Try doing this with Heroku and you’ll decide that you want CORS after a few hours.

Going to implement this to improve Denigma.app load time!

Didn&#x27;t we do this back in the day for IE?

I&#x27;m not 100% on this, but doesn&#x27;t disabling CORS essentially re-introduce CSRF?

Or just declare JSON as text, simple cors supports authentication, no need to mess with routes.

&gt; You don’t need that CORS request<p>…if you’re using a proxy like Cloudflare.<p>The short version of this post is that if your api is hidden behind Cloudflare, you can have it proxy requests to you api that lives on a subdomain.