4 ms·

Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours inc

by atonse 8y ago

Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours included)

askmike 8y ago
Wondering about the same thing.
tinco 8y ago
Some people have performance concerns with CORS is the main reason I believe. The overhead is an extra round trip.
- atonse 8y ago
  I thought the concern was security. Anyway HTTP2 would hopefully address that (through header compression), and things like zero-RTT TLS and keep-alive further minimize the overhead of an additional request. Plus doesn't CORS only make preflight requests periodically, not for every request?
  - luhn 8y ago
    Preflights are cached, but because CORS is per-URL caching can be of limited value. If your API uses `/info` and `/edit`, a preflight request has to be made for both (assuming a preflight is necessary). If your application has dynamic URLs (e.g. `/widget/1`, `/widget/2`, etc.) the problem is exacerbated even further.
  - Ayesh 8y ago
    I wrote/research a lot about http/2, and even has a small tool for it (https://http2.pro https://http2.pro). Among many things you get from http/2, it cannot eliminate round trip time. Sure, you can keep a connection alive but that's possible with http 1.1 too. Header compression is HPACK. If the header changes even the slightest bit, it's not cached. Dynamic URLs and headers can easily bust HPACK compression.
throwawaymath 8y ago
The author hasn’t clarified yet, but I suspect what they’re referring to is the fact that CORS does not support granular access control. If you make something public under CORS, any client can retrieve the resource if no other authorization or authentication check is in place. It’s not a system of authentication, it’s a system of authorization - specifically, for authorizing hosts to request resources which normally wouldn’t be authorized to do so under same origin policy. As a concrete example: people occasionally misuse the Origin header, thinking that they can use it as a form of client authentication. The idea is that any client request from a non-whitelisted origin will fail. But any user can spoof their own Origin header, and the Origin header is primarily intended to protect users from making CORS requests they didn’t intend (because in most cases an attacker cannot coerce a browser to forge a header).
- felipelemos 8y ago
  CORS is not a tool to turn resources private, but to protect the browser (not the server's content) from cross domain requests.
  - scottydelta 8y ago
    Exactly, the attacker can always not use the browser and emulate a browser request if motivated enough.
  - throwawaymath 8y ago
    Yes, that's precisely why CORS is a poor fit for authentication :)
    - askmike 8y ago
      Sure, but I don't see why the tip in OP is "don't use CORS". To me that implies there is actually something insecure about using it.
      - throwawaymath 8y ago

by atonse 8y ago

Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours included)

askmike 8y ago

Wondering about the same thing.

tinco 8y ago

Some people have performance concerns with CORS is the main reason I believe. The overhead is an extra round trip.

atonse 8y ago
I thought the concern was security. Anyway HTTP2 would hopefully address that (through header compression), and things like zero-RTT TLS and keep-alive further minimize the overhead of an additional request. Plus doesn't CORS only make preflight requests periodically, not for every request?
- luhn 8y ago
  Preflights are cached, but because CORS is per-URL caching can be of limited value. If your API uses `/info` and `/edit`, a preflight request has to be made for both (assuming a preflight is necessary). If your application has dynamic URLs (e.g. `/widget/1`, `/widget/2`, etc.) the problem is exacerbated even further.
- Ayesh 8y ago
  I wrote/research a lot about http/2, and even has a small tool for it (https://http2.pro https://http2.pro). Among many things you get from http/2, it cannot eliminate round trip time. Sure, you can keep a connection alive but that's possible with http 1.1 too. Header compression is HPACK. If the header changes even the slightest bit, it's not cached. Dynamic URLs and headers can easily bust HPACK compression.

throwawaymath 8y ago

The author hasn’t clarified yet, but I suspect what they’re referring to is the fact that CORS does not support granular access control. If you make something public under CORS, any client can retrieve the resource if no other authorization or authentication check is in place. It’s not a system of authentication, it’s a system of authorization - specifically, for authorizing hosts to request resources which normally wouldn’t be authorized to do so under same origin policy. As a concrete example: people occasionally misuse the Origin header, thinking that they can use it as a form of client authentication. The idea is that any client request from a non-whitelisted origin will fail. But any user can spoof their own Origin header, and the Origin header is primarily intended to protect users from making CORS requests they didn’t intend (because in most cases an attacker cannot coerce a browser to forge a header).

felipelemos 8y ago
CORS is not a tool to turn resources private, but to protect the browser (not the server's content) from cross domain requests.
- scottydelta 8y ago
  Exactly, the attacker can always not use the browser and emulate a browser request if motivated enough.
- throwawaymath 8y ago
  Yes, that's precisely why CORS is a poor fit for authentication :)
  - askmike 8y ago
    Sure, but I don't see why the tip in OP is "don't use CORS". To me that implies there is actually something insecure about using it.
    - throwawaymath 8y ago