I have been using lots of various APIs in my frontend lately and they all have to be properly configured with CORS and the browser always do extra OPTIONS request that only make debugging harder.

I was wondering if there could be a way of disabling cookies for these requests for an application, would that work as a secure alternative to CORS?

E.g. something like that in the index.html file:


Then all requests to 3d party apis would be made without any cookie which would prevent all the issues that CORS is trying to solve.

Can this be an alternative to CORS, or would that not be "secure enough" and CORS prevents some other attacks/problems?

P.S. This is more of a theoretical question on whether a proposed solution (if implemented by browsers) would make any sense.

  • The browser is trying to protect your users from attacks. You don't need to configure CORS headers if all requests are same-site/domain. The browser will then keep your users safe. There is already a setting for cookies which prevents sending them from a 3rd party context. (same-site attribute... strict or lax would prevent them from being sent via request from a different domain. Default is "lax" for most browsers so your users are already protected unless you explicitly set that to "none".) Commented Dec 13, 2023 at 23:40
  • "they all have to be properly configured with CORS" You may be very mistaken here. This may be true while debugging locally and running frontend/backend on different localhost ports (which is treated as separate domains), but the published version front-end and back-end can certainly all be hosted at the same domain... and really should be. You CAN turn off the protection in the browser. Flag is something like --disable-web-security for Chrome. Commented Dec 13, 2023 at 23:51

1 Answer 1


I think you have fundamentally misunderstood CORS. The short answer to your question is "NO", because that question doesn't even make sense; there exist alternatives to CORS (see the bottom of this answer) but they have nothing to do with whether cookies are used or not.

CORS is just a way to poke holes in the Same-Origin Policy (SOP) that normally prevents origin X from accessing content on origin Y. In particular, CORS is a way to make the same kind of requests you can do same-origin - with custom headers and so on, plus the ability to read the responses - for cross-origin requests. Pre-flights are needed for any cross-origin request that you couldn't make with a normal HTML <form> element.

Cookies have nothing at all to do with whether CORS preflights (the OPTIONS requests) are required or not. You can send non-CORS requests cross-origin (and they can even have cookies!) but you can't read the responses to those requests (this is basically what CSRF is, though in this case you wouldn't be "forging" the requests), but I'm guessing you need those responses. You can also turn off cookies in CORS requests but this does not change whether or not a pre-flight is required.

If you want to avoid CORS pre-flights, either don't use CORS (in which case you can't read the response), or use "simple" CORS requests (no custom headers, no ability to read response headers, limited content types, GET/POST/HEAD methods only). Either one will work fine. Cookies are irrelevant, unless the target site permits CORS from your site but doesn't specify Access-Control-Allow-Credentials: true, in which case you need to turn off sending cookies (which is easy, just set "credentials" to false when making the request) or else you won't be able to view the response.

There are other options for cross-origin messaging, but they all have major downsides.

  • JSONP is an old technique for cross-origin requests that is now discouraged; few sites offer it any more, in part it's much less secure than CORS for both the server and the client.
  • Server-side requests work fine but add latency and server load (for you), and require relaying information (such as credentials) off your server; also, some third-party servers might get suspicious about your server hammering them with requests on behalf of all your users; it's an atypical access pattern.
  • Iframes or popups plus window messaging offer a way to load a third-party origin (if it permits this) in its own "sub-window" that can then - with approval of both sites - send and/or receive messages with your own origin, but it requires coordination between the origins on the message format and also some browsers are really restrictive when it comes to stored data of any kind in sub-windows.
  • Thanks for your comprehensive answer! I see that I failed to formulate the question properly. What I really meant to say is that I want an alternative to using CORS as a means of relaxing same origin policy. And then my theoretical proposed solution is to tell the browser that I want to allow making any ajax requests at will and the browser does not need to include cookies in these requests (which can be abused). Alternatively just allow the fetch requests to any domain altogether So with that in mind I was wondering if such a theoretical option in browser can work as an alternative to CORS Commented Dec 15, 2023 at 8:57
  • Simply making CORS-like requests (including ability to see the responses) without cookies is not necessarily safe, and this is why browsers don't allow it. The JS sandbox in browsers is very strict about what you're allowed to do, and one of those things is "no making requests that a HTML form couldn't make, or seeing the responses to any cross-origin request at all, without the consent of the third-party site". After all, JS is untrustworthy code from somebody else, running on your computer. It shouldn't have very much network access; the fact it has as much as it does is historical artifact!
    – CBHacking
    Commented Dec 15, 2023 at 11:25
  • I see, do you have some examples that explain how a cross site request without cookies with a possibility to read a response will not be safe? I.e. how this possibility can be abused? Commented Dec 16, 2023 at 12:09
  • 1
    Lots of ways to authenticate or at least authorize a client without cookies. This is a full question in its own right, but some quick answers: TLS client certificates, IP address (possibly combined with IPSec), access to a specific network interface (e.g. LAN or even loopback, with the latter being very common), port knocking, and of course HTTP Basic or Digest auth. Note that these don't involve sending user-specified credentials with requests, like Bearer tokens or secrets in URLs or so on. In addition to exposing secrets, seeing responses means state-changing CSRF can't be prevented.
    – CBHacking
    Commented Dec 18, 2023 at 3:33
  • 1
    @jub0bs Interesting. HEAD is allowed for simple CORS requests (and, apparently, for non-CORS cross-origin requests) but you're right, it's not actually allowed for HTML forms. HEAD is supposed to be processed exactly as if it were a GET request (just not returning the body), but of course "supposed to be" is often violated, and there's nothing forcing the server to follow the spec.
    – CBHacking
    Commented Dec 20, 2023 at 22:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .