81–90 of 127 posts
CORS is a technical subsidy granted to (sloppy) users of cookie authentication. I’ve never worked on a project where it was anything other than an annoying hoop to jump through.
You could just as easily frame CORS as "antibiotics for the people who dared to leave their house".
(There's also a no-true-scotsman fallacy going on in your argument)
Why not just include the Origin on all cross-origin requests? Then the server could deny/allow it without the need for preflight.
I would be concerned about the privacy implication of it. Imagine if the browser sent the origin to widely used CDNs, or to Google Fonts, and that people didn't actually block Google domains on their browsers. Also, this would not be secure by default, because you would have to change the default behavior of the server to block cross origin requests.
I'm ideologically against third party on the web because it is a privacy nightmare. But I'm in the system that I'm in, and I don't take on fights that aren't possible to win, so barring my becoming a billionaire I've kinda just accepted that third party is here for at least a little while and I'm not going to refuse to use ads and analytics. Except on my personal website, that gets to stay cool. That said, CORS is th…
Our microservices stack is pretty dependent upon clients making cross-origin requests. I don't necessarily consider these "3rd party".
That means extra delay, extra db connections and calls, etc.
How do you deal with them?
This is an awesome overview! But don't take it as all encompassing, it doesn't go into some of the more esoteric edge cases with CORS, like: * either an unreleased safari version, or the most recent version will send preflight requests even if the request meets the spec (like if the Accept-Language is set to something they don't like). * If you use the ReadableStream API with fetch in the browser, a preflight will be…
The entire webstack is such a broken mess of inconsistencies and thousands of hidden traps that can render the entire thing insecure. People moan about C yet I find the web stack greatly more painful to write because you didn't even have control over the compiler following standards strictly (where stuff has even been standardised). I really do wish we worked together to create a new standard for building and deployi…
Maybe it isn't great in all the ways, but at least it's something that works and is flexible enough for all sort of things.
I'm ideologically against third party on the web because it is a privacy nightmare. But I'm in the system that I'm in, and I don't take on fights that aren't possible to win, so barring my becoming a billionaire I've kinda just accepted that third party is here for at least a little while and I'm not going to refuse to use ads and analytics. Except on my personal website, that gets to stay cool. That said, CORS is th…
CORS is not necessarily about third parties. It's common to have app.example.org point to a CDN and api.example.org point to an API. And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The reason it's implemented this way is because of the organic evolution of web security.
That's not true. You can set CORS: * and validate all requests in your server. The extra rules are for vast majority of servers that never inspect Origin headers.
I never really understood why we have CORS. I mean, the problem with CSRF is that some random page can trick your browser into adding its authentication token to a request which does not originate from the authenticated page. So why the do we need the server to tell the browser that it should not send requests from other origins? In my opinion, it would have been much better to improve the browsers to not include coo…
CORS is really for the opposite problem. Browsers do block requests from other origins by default (mostly). CORS is used to let the server decide which origins are allowed to request data and how it can be requested. If the client was allowed to decide via javascript, then attacker.com could make a request via javascript to facebook.com telling the browser to send cookies and return the user's data. This is actually…
If the browsers separated the session by origin (as blauditore wrote), the whole problem space would look very different.
Especially, setting the "Access-Control-Allow-Credentials" header to true means that a client which sent a request with a cookie is allowed to read the result, but whether the request is sent with a cookie or not, and will be treated as such by the server, is entirely up to the client.
So although malicious.com cannot read the details of bank.com using AJAX, it can definitely send a POST request to trigger the transfer from the user's account to a malicious account using the user's cookie (blindly so).
This is the reason proper CSRF protection must be implemented by the server, independently of whether CORS is enabled or not.
This is something I could never get my head around with CORS - what's the point of whitelisting origins if getting around the whitelist is nothing more than an inconvenience?
Earlier quoted context omitted.
The entire webstack is such a broken mess of inconsistencies and thousands of hidden traps that can render the entire thing insecure. People moan about C yet I find the web stack greatly more painful to write because you didn't even have control over the compiler following standards strictly (where stuff has even been standardised). I really do wish we worked together to create a new standard for building and deployi…
I don't think there's the ultimate solution to anything. On a high-level anything seems like it can be done easily, but the issue always lies in the details. Maybe it isn't great in all the ways, but at least it's something that works and is flexible enough for all sort of things.
I will grant you that things have gotten better in recent years and I do agree that there isn't such thing as a perfect solution, but given we're in an era where desktop software is being fazed out in favour of web applications (and even some desktop software is now being written using web technologies - such as Electron) it really feels like we're going wholesale into using a stack of technologies that could be significantly improved if we redesigned it from the ground up taking into account:
* what we have learned form the last ~25 years of the web,
* the change in how the internet (in a broader sense) is consumed over the last 10 years
* all the lessons we've learned from the decades of desktop software development.
Plus removing all the legacy cruft which your sibling commenter highlighted has to be seen as a bonus too.
I'm not suggesting we get rid of HTML entirely, but maybe have a new programming language for the modern web - like how we have different programming languages for other areas of computing for when we have different problems we are trying to solve. eg Bash, Perl, Go and C can all be used to write CLI tools but you'd use them to target different problems.
I guess to an extent developers are trying to do this already with some of the massive tooling you get that compiles down to CSS, Javascript and so forth. Plus the experiments we see in web assembly are another example of developers trying to break free from the constraints of scripting stuff inside a document. But I'd rather see a secondary development platform that is native to the web and is more application aware and security conscious than our current situation of having to run vast and complex frameworks that still, ultimately, compile down to the same inconsistent and insecure platform that we're currently stuck with.
But as I said, this is just soapbox ranting. I couldn't see it changing without one of the powerhouses developing it largely in isolation and then we run the risk of walled gardens which - in my opinion at least - is worse than the current status quo.
This is an awesome overview! But don't take it as all encompassing, it doesn't go into some of the more esoteric edge cases with CORS, like: * either an unreleased safari version, or the most recent version will send preflight requests even if the request meets the spec (like if the Accept-Language is set to something they don't like). * If you use the ReadableStream API with fetch in the browser, a preflight will be…
The entire webstack is such a broken mess of inconsistencies and thousands of hidden traps that can render the entire thing insecure. People moan about C yet I find the web stack greatly more painful to write because you didn't even have control over the compiler following standards strictly (where stuff has even been standardised). I really do wish we worked together to create a new standard for building and deployi…