71–80 of 127 posts
Why not just include the Origin on all cross-origin requests? Then the server could deny/allow it without the need for preflight.
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 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…
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".
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…
Ya I generally think CORS is a waste of time. It would have been better to provide a hash of the file we're linking to and trust that rather than where it came from. Which is precisely what Subresource Integrity (SRI) does: https://en.wikipedia.org/wiki/Subresource_Integrity Sadly even though this is an obvious concept and trivial to implement, it took them over 20 years since the web came out to get it in most brows…
Google Analytics or recaptcha for example aren't versioned. Deploying SRI is just going to break your site when they update the script.
It acts as a `fetch` implementation that allows you to declare cross-origin policies in advance, then channel the requests through an iframe which enforces those policies.
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…
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 deploying documents and applications over the internet because this HTML (and all its supporting technologies) is an experiment that has gone bad. Id preferably want something that doesn't allow each browser to interpret the specifications differently and absolutely something that isn't controlled by Google (they would obviously need input but the last thing we need is another AMP).
Of course it will never happen, but one can dream / rant nonetheless.
Earlier quoted context omitted.
How would http be any harder for middleware than app-layer? If both linked to libhttp.c, couldn't they each get the full parsing/reading/writing - wether proxy or server?
Being able to parse HTTP doesn't get anywhere when you can't actually get at the contents because they're encrypted (as with all major HTTP2 implementations).
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…
It's amazing if you look at it from that point. You can't have security by default because the old standard is insecure by default (by todays means) and that's what legacy applications depend on, yet there has been a lot of progress that you can opt into.
My favorite example are cookies. While everything else is origin based, those are still based on a model that is very close to dns (everything psl+1 is the same thing). This opens you up to a large number of attacks, especially in a man in the middle situation (even with https). You can secure your own application by using secure cookie prefixes, but everything else is doomed.