How is this different from the origin header? Does the origin header not tell the webbserver if the requested originated from the same website? Is the origin header flawed in some way?
This spec seems really powerful, provided all browser support it :)
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fe...
Internet Explorer is dead (ok, is a Zombie. But was supper-seeded by Edge for most users).
Safari is sadly not yet supported.
The nice thing is that you can employ security enhancements based on this technique even if it's not supported by all your clients.
I.e. you can automatically reject requests if the headers are given and have a bad value, which would add additional protection against certain attacks for all users except the ones stuck on IE or Safari.
Because I use Safari specifically for privacy reasons and it also used to never trigger my fans to full speed just to play videos, like Chrome. I also have read that while Safari does tend to take longer, their implementations tend to be more polished. But this was more like a tweet so take that anecdata with a grain of salt.
Also more user-friendly way to install desktop shortcut would help tremendously to make web apps more popular. Of course Apple is not interested with that, but it's still sad.
Today I spent hours debugging why pages with a particular iframe embed would log you out of the parent site on Safari / iOS. Possibly because the same first-party resource was requested from both outside and inside the frame? Not sure yet.
If you attempt to use localStorage from a private tab on safari, it reports that it's present and working, but raises an exception on any access (every other platform either does not expose localStorage in private tabs, or clears it after).
1. it was largely dominant, so people thought they could develop just taking that browser in consideration
2. for the previous point, MS started to develop proprietary features (like ActiveX)
3. at a certain point its development was stopped for a long time
Safari certainly cannot match the first two reasons. But it cannot match the third either, because the development of standard web features is going on at good pace (see <https://webkit.org/status/>).
1. It doesn't support many of the latest web standards
2. A large enough percentage of users use it that it can't be simply ignored
Both of those points apply to modern Safari. Less so to IE these days as #2 becomes less and less applicable; hence "Safari is the new IE".
> Safari certainly cannot match the first two reasons.
1. Most users view websites on their phones. Safari is the only browser on iPhone (there are other browser skins, but they're all forced to run on top of Safari). The market share of iOS devices is usually about at least 50% in developed nations.
2. iOS has proprietary features, it is known as the App Store. If you want to develop certain things, you must use the app store, the browser is locked out of those features (even if all other browser vendors have them).
> But it cannot match the third either, because the development of standard web features is going on at good pace (see <https://webkit.org/status/>).
3. I probably don't need to go into this point since it's common knowledge that Safari has always been the least compliant browser in terms of web standards. Their history of holding back features or implementing features with critical flaws that make them useless has been a recurring trend for the last decade. Just because they have checked a box on a table, doesn't mean the feature is anything close to useable.
I think you meant superseded (pronounced super-seeded).
It's defense in depth :D
“ There are some exceptions to the above rules; for example if a cross-origin GET or HEAD request is made in no-cors mode the Origin header will not be added.”
It seems though that a browser would not allow 'non-simple' headers in no-cors mode[0].
Authorization headers for example would not be allowed (if i'm reading correctly). So any API using that header would not be affected by this issue right?
[0] https://developer.mozilla.org/en-US/docs/Web/API/Request/mod...
The user action part is very nice if it can't be overwritten with just javascript. The other parts I'm not sure what the browser is helping with, that can't just be done with standard headers.
tl;dr yes. It's not always sent.
According to [0] we can force CORS behaviour be using a non-simple request in our webapp. By setting the mime type to JSON for example.