Cors...

In reality it's more like

request ---> browser ---> server

CORS error <-x- browser <--- server

CORS is managed by the browser and serverside opt-out because it's designed to protect servers that are older than CSRF.

That's also why it's such a pain in the ass to configure. If it was the server's job to read the Origin header and decide whether to accept or not, the protocol would be a single status code. Because the server has to explain to the browser under what circumstances cross-origin requests should be allowed, it has to be a large set of headers with complicated values and possibly the most complex protocol published by the IETF that takes HTTP as the underlying abstraction, second only to WebDAV.

Actually, I wonder why CORS doesn't come with an

Access-Control: Disable

header to indicate that the server is aware of CSRF and equipped to handle it, along with a 4xx status code for "Access control overreach / Agent not permitted". This status code isn't handled by the browser, it's forwarded directly to the origin because the server allows some cross-origin requests and the response may contain useful information about the error at the server's discretion.

I mean we have ACAO: *, but we don't have an ACAHeaders: * and there are a horde of other edge cases to make access control a pain in the ass. Whether a 5xx response should be forwarded from a server that also disabled access control is an interesting question.

@bubblegumPOP How has this got anything to do with JS? This feels a lot like blaming JS for standard floating points.

@bubblegumPOP You load a local file using fs.readFileSync or require if you're in node, or the import function if you're in deno.

If you're talking about a browser, you're probably approaching your problem incorrectly because web content is only supposed to interact with local data using uploads, downloads and the filesystem API. This is deliberate.