Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Killing CORS Preflight Requests on a React SPA

m.alphasights.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Killing CORS Preflight Requests on a React SPA

#21

Post by terinjokes »

Manishearth wrote: post #14
jdmichal wrote: post #12

I personally always thought that the CORS domain checking was needlessly and overly restrictive. I can understand entirely different top-level domains; definitely 100% necessary. You start to lose me at different sub-domains for the same top-level domain. Do we really need to check api.example.com from app.example.com ? Chances are good that they're both controlled by the same entity, so what's the problem? I'm out t…

> Do we really need to check api.example.com from app.example.com? Sure. What about hosted subdomains where people can create their own sites, with JS, on different subdomains? CORS can't work without applying the most restrictive policy by default -- if you do care about these things being able to access each other, send Access-Control headers.

Then request to add yourself to the public suffixes list.

Re: Killing CORS Preflight Requests on a React SPA

#22

Post by cmrx64 »

lmm wrote: post #17
Xorlev wrote: post #8

> In terms of security, all API calls should be using https and there is little difference in putting the token in headers or as part of the query string. Mostly true. But as a heads up, you might want to shy away from this as plenty of browser extensions are actually spyware and report full URLs back to the mothership. We ran into this recently where calls to our service including API keys in the query parameters en…

I wish browser vendors would put work into making the browser-managed client certificate UX much nicer. That would make it possible to offer a real step change in security.

This is about authenticating consumers of an API, not end users. So while your wish is nice, it's a non sequitur here.

Re: Killing CORS Preflight Requests on a React SPA

#23

Post by lmm »

cmrx64 wrote: post #22
lmm wrote: post #17

Earlier quoted context omitted.

I wish browser vendors would put work into making the browser-managed client certificate UX much nicer. That would make it possible to offer a real step change in security.

This is about authenticating consumers of an API, not end users. So while your wish is nice, it's a non sequitur here.

If we're talking about browser extensions (as the comment I replied to was) then we're talking about calls being made from the browser.

Re: Killing CORS Preflight Requests on a React SPA

#26

Post by Manishearth »

terinjokes wrote: post #21
Manishearth wrote: post #14

Earlier quoted context omitted.

> Do we really need to check api.example.com from app.example.com? Sure. What about hosted subdomains where people can create their own sites, with JS, on different subdomains? CORS can't work without applying the most restrictive policy by default -- if you do care about these things being able to access each other, send Access-Control headers.

Then request to add yourself to the public suffixes list.

That's not yet used by all browsers. And it's a bit more restrictive than necessary, since the base domain is supposed to not be a website at all (and loses the ability to do some things with cookies iirc). That's not always the case. co.uk doesn't need to set cookies, but blogspot.com does (and is a website), so .blogspot.com can't be an eTLD.

Re: Killing CORS Preflight Requests on a React SPA

#27

Post by jessaustin »

terinjokes wrote: post #21
Manishearth wrote: post #14

Earlier quoted context omitted.

> Do we really need to check api.example.com from app.example.com? Sure. What about hosted subdomains where people can create their own sites, with JS, on different subdomains? CORS can't work without applying the most restrictive policy by default -- if you do care about these things being able to access each other, send Access-Control headers.

Then request to add yourself to the public suffixes list.

So rely on proactive work by various SaaS vendors/other domain owners to preserve security for some of their clients, rather than relying on well-defined action from the owners of a particular service to ensure that said service works at all? Seems like we're "failing open" with the policy you suggest?

Re: Killing CORS Preflight Requests on a React SPA

#28

Post by bostonvaulter2 »

33degrees wrote: post #10
jc4p wrote: post #2

super minor but unless I'm mistaken SPA stands for "Single Page Application", so the first sentence in the post is a bit jarring: > AlphaSights’ recruitment platform evolved from a Rails application into a _classic SPA app_. Update 20s later: is "Wepack" in the diagram supposed to be "Webpack"? Update 60s later: Can you explain _what_ you're actually using that runs into CORS issues? Are browsers talking to the api.*…

The diagram is bad, the browser is running code loaded on app.* and making requests to api.*; I've used similar setups and have run into the same issues the author is describing.

How did you end up dealing with them?

Re: Killing CORS Preflight Requests on a React SPA

#29

Post by HorizonXP »

tlrobinson wrote: post #9

Maybe this is obvious, but why not just configure a reverse proxy to point different paths to different backends? I always assumed CORS was more for connecting directly to 3rd party APIs.

That's how I do it. Not sure what the benefit of having your API on a separate sub-domain is.

Re: Killing CORS Preflight Requests on a React SPA

#30

Post by 3pt14159 »

When I started going down the whole CORS rabbit hole a very simple solution came to me almost immediately via googling. Xdomain. It is simple, it doesn't do preflight checks, it's secure. The only silly edgecases are where other people have already worked around CORS awfulness for their client libraries (MixPanel, FB SDK, Intercom).
Post reply on HN