8 ms·

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 he

by wronex 5y ago

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?

taf2 5y ago
It seems silly to me too but re reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Or... “ 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.”
- elken 5y ago
  That's an interesting find thanks. I was not aware of no-cors mode. 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/mode#value https://developer.mozilla.org/en-US/docs/Web/API/Request/mod...
alexghr 5y ago
Reading the documentation on MDN[1] it looks like it sends more data than just the Origin of the request. Metadata headers include if the user initiated the request (e.g. navigation or click events?) and how the data is meant to be used (e.g. as audio data for <audio> or a top-level document). This spec seems really powerful, provided all browser support it :) [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fetch_metadata_request_headers https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fe...
- dathinab 5y ago
  Firefox, Chrome, Edge and Opera support it (including mobile). 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.
  - drchickensalad 5y ago
    Safari truly is IE in 2021
    - deleted 5y ago
      [deleted]
    - Dah00n 5y ago
      I have done web-development both in the bad IE days but also recently and IMO it wasn't as bad to develop for IE as it is for Safari today. Safari is broken in strange and random ways and missing odd features and is a moving target (and seem to break more with time). Developing for IE was extremely well documented (especially in later versions) and avoiding pitfalls was very easy, even for people new to creating webpages using a few Google searches. Not so for Safari - unless you cut it completely off from all modern advances on the web. It just felt worse back then because IE was much more widespread.
      - vanviegen 5y ago
        Were you actually doing any serious web development in the mid 2000s? Because I have a feeling you wouldn't be saying this if you were.. :-)
        Dah00n 5y ago
        I can see that came out wrong. I'll try to rephrase...
    - sgift 5y ago
      And even for the same reason: If the browser was too good "no one" (very loosely defined here) would need to buy Apps anymore. :(
    - atonse 5y ago
      I don’t quite understand this argument. Can you give me a couple examples of Safari holding back major parts of web design? Or is it more obscure stuff like some webGL engine? 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.
paulddraper 5y ago
> Is the origin header flawed in some way? tl;dr yes. It's not always sent.
- deleted 5y ago
  [deleted]
- wronex 5y ago
  This is true. Could we not disregard requests without an origin header? 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. 0: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
dec0dedab0de 5y ago
If all the parts of the site are at the same place, then checking an origin header would probably do the same thing. This seems to be adding semantics for when the frontend is requesting data from a different backend, as well as for specific types of content, and if it was based on a user action. 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.

by wronex 5y ago

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?

taf2 5y ago

It seems silly to me too but re reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Or... “ 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.”

elken 5y ago
That's an interesting find thanks. I was not aware of no-cors mode. 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/mode#value https://developer.mozilla.org/en-US/docs/Web/API/Request/mod...

alexghr 5y ago

Reading the documentation on MDN[1] it looks like it sends more data than just the Origin of the request. Metadata headers include if the user initiated the request (e.g. navigation or click events?) and how the data is meant to be used (e.g. as audio data for <audio> or a top-level document). This spec seems really powerful, provided all browser support it :) [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fetch_metadata_request_headers https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fe...

dathinab 5y ago
Firefox, Chrome, Edge and Opera support it (including mobile). 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.
- drchickensalad 5y ago
  Safari truly is IE in 2021
  - deleted 5y ago
    [deleted]
  - Dah00n 5y ago
    I have done web-development both in the bad IE days but also recently and IMO it wasn't as bad to develop for IE as it is for Safari today. Safari is broken in strange and random ways and missing odd features and is a moving target (and seem to break more with time). Developing for IE was extremely well documented (especially in later versions) and avoiding pitfalls was very easy, even for people new to creating webpages using a few Google searches. Not so for Safari - unless you cut it completely off from all modern advances on the web. It just felt worse back then because IE was much more widespread.
    - vanviegen 5y ago
      Were you actually doing any serious web development in the mid 2000s? Because I have a feeling you wouldn't be saying this if you were.. :-)
      - Dah00n 5y ago
        I can see that came out wrong. I'll try to rephrase...
  - sgift 5y ago
    And even for the same reason: If the browser was too good "no one" (very loosely defined here) would need to buy Apps anymore. :(
  - atonse 5y ago
    I don’t quite understand this argument. Can you give me a couple examples of Safari holding back major parts of web design? Or is it more obscure stuff like some webGL engine? 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.

paulddraper 5y ago

> Is the origin header flawed in some way? tl;dr yes. It's not always sent.

deleted 5y ago
[deleted]
wronex 5y ago
This is true. Could we not disregard requests without an origin header? 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. 0: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

dec0dedab0de 5y ago

If all the parts of the site are at the same place, then checking an origin header would probably do the same thing. This seems to be adding semantics for when the frontend is requesting data from a different backend, as well as for specific types of content, and if it was based on a user action. 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.