Do You Really Know CORS? • Hacker News Board

Re: Do You Really Know CORS?

#11

Post by officialchicken » Wed, Oct 03, 2018, 10:00 PM UTC

Klathmon wrote: post #4

officialchicken wrote: post #2

I know it well enough that changing to a custom mime-type like "text/x-myapp-foo" is a solution that gets around CORS and pre-flight as well in the latest version of Chrome.

Are you sure? That's a pretty insane security issue if it's true! Content-Type should only be allowed to be `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain` to be allowed without preflight. Edit: I can't reproduce this on Chrome 69.0.3497.100 (Official Build) (64-bit). Setting the Content-Type to anything other than the above with a POST request will cause an OPTIONS preflight, even when us…

I'm using 69.0.3497.81. Make sure your server accepts the header... after changing I stopped seeing OPTIONS requests in my server logs, not that it measurably improved the speed of the SPA. It was several months ago I made the change and FF behavior is definitely different (more relaxed?) than Chrome when it comes to CORS.

Re: Do You Really Know CORS?

#12

Post by icebraining » Wed, Oct 03, 2018, 10:03 PM UTC

ravenstine wrote: post #10

paulddraper wrote: post #8

Earlier quoted context omitted.

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.

> rather than just enforcing access itself. Could you elaborate on that? I can't picture the alternative you're suggesting.

Same here... from what I can tell, only the browser has reliable information about what's happening. How could the server know code from another domain is making the requests? And if anything, the web is more secure - desktop native applications can usually access each other's data and do malicious requests to remote servers using stolen credentials just fine.

Re: Do You Really Know CORS?

#13

Post by stesch » Wed, Oct 03, 2018, 10:07 PM UTC

Had to deal with a firewall that filtered all unknown/"new" HTTP headers. This included CORS.

A PITA to find the reason why Firefox wouldn't use the Google fonts.

Re: Do You Really Know CORS?

#14

Post by nothrabannosir » Wed, Oct 03, 2018, 10:08 PM UTC

ravenstine wrote: post #10

paulddraper wrote: post #8

Earlier quoted context omitted.

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.

> rather than just enforcing access itself. Could you elaborate on that? I can't picture the alternative you're suggesting.

Using HMAC or API keys.

Re: Do You Really Know CORS?

#15

Post by paulddraper » Wed, Oct 03, 2018, 10:09 PM UTC

ravenstine wrote: post #10

paulddraper wrote: post #8

Earlier quoted context omitted.

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.

> rather than just enforcing access itself. Could you elaborate on that? I can't picture the alternative you're suggesting.

The alternative is for the idea agent to send the Origin header on all requests.

Then the server responds with 200 or 403.

Re: Do You Really Know CORS?

#16

Post by TeMPOraL » Wed, Oct 03, 2018, 10:13 PM UTC

officialchicken wrote: post #11

Klathmon wrote: post #4

Earlier quoted context omitted.

Are you sure? That's a pretty insane security issue if it's true! Content-Type should only be allowed to be `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain` to be allowed without preflight. Edit: I can't reproduce this on Chrome 69.0.3497.100 (Official Build) (64-bit). Setting the Content-Type to anything other than the above with a POST request will cause an OPTIONS preflight, even when us…

I'm using 69.0.3497.81. Make sure your server accepts the header... after changing I stopped seeing OPTIONS requests in my server logs, not that it measurably improved the speed of the SPA. It was several months ago I made the change and FF behavior is definitely different (more relaxed?) than Chrome when it comes to CORS.

There's caching for successful preflights; maybe it's involved here?

Re: Do You Really Know CORS?

#17

Post by breatheoften » Wed, Oct 03, 2018, 10:15 PM UTC

officialchicken wrote: post #11

Klathmon wrote: post #4

Earlier quoted context omitted.

Are you sure? That's a pretty insane security issue if it's true! Content-Type should only be allowed to be `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain` to be allowed without preflight. Edit: I can't reproduce this on Chrome 69.0.3497.100 (Official Build) (64-bit). Setting the Content-Type to anything other than the above with a POST request will cause an OPTIONS preflight, even when us…

I'm using 69.0.3497.81. Make sure your server accepts the header... after changing I stopped seeing OPTIONS requests in my server logs, not that it measurably improved the speed of the SPA. It was several months ago I made the change and FF behavior is definitely different (more relaxed?) than Chrome when it comes to CORS.

I know that chrome limits the amount of time that the CORS preflight validation response result can be cached (to a maximum of 5 minutes — and if the server sets expiration header to a longer time - chrome still only caches up to 5 minutes). Does Firefox perhaps not limit this? It could be that you are seeing a difference in behavior due to the max time that each browser is willing to cache the CORS preflight check ...?

Re: Do You Really Know CORS?

#18

Post by inopinatus » Wed, Oct 03, 2018, 10:25 PM UTC

paulddraper wrote: post #8

3pt14159 wrote: post #6

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.

CORS protects users, not services, so it's entirely reasonable that the evaluation of policy occurs in the user agent.

Re: Do You Really Know CORS?

#19

Post by rnotaro » Wed, Oct 03, 2018, 10:29 PM UTC

paulddraper wrote: post #15

ravenstine wrote: post #10

Earlier quoted context omitted.

> rather than just enforcing access itself. Could you elaborate on that? I can't picture the alternative you're suggesting.

The alternative is for the idea agent to send the Origin header on all requests. Then the server responds with 200 or 403.

The origin could still be falsified client-side.

Re: Do You Really Know CORS?

#20

Post by aikah » Wed, Oct 03, 2018, 10:46 PM UTC

paulddraper wrote: post #8

3pt14159 wrote: post #6

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.

> 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 only concerns of CORS is with Javascript running in the browser. CORS is not about server-side security but what Javascript can or cannot access. It is there to protect the browser's user and make script execution more secure.