Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • - cors docs are written either from solution or implementation point of view, not the "why this exists, and how we successively deal with bad actors trying to game cors", cors RFC is terse

    - protocol itself is quite nuanced, like iirc requests with Authorization (or some other) headers don't obide by usual rules, and again for developer it's just an arbitrary convoluted set of rules, if they don't grasp the problematics

    - backend and frontend should work in unison to have correctly configured cors, but as we know, devs hate communicating with each other

    by kartoshechka
  • From my experience, the reason CORS is hard to understand is that it's somehow inverted from the default "shape" of security in web dev.

    We easily form the intuition of the client being a by-default untrusted entity, and checking whether it has the privilege of accessing this data, where the server is the arbiter of that access.

    CORS is so inherently different to that, and while the information is easily available, it requires a short but careful read to grok the idea -- which a dev tunnel-visioning towards getting their application code written may not wish to slow down for.

    by frogulis
  • I think that once you understand that CORS is about protecting the visitor not the server you're halfway there.

    Also, if you have everything set up properly, the fact that you're haveing any CORS issues at all means you're probably trying to do something stupid and you need to ask someone smarter how to solve your problem.

    by trick-or-treat
  • I understand how the Same Origin Policy protects browsers from executing malicious scripts. I also understand how the Access-Control-Allow-Origin header can be used by servers to declare additional origins as trustworthy, relaxing the SOP.

    What I still don't understand is what purpose the Access-Control-Allow-Headers header serves. It doesn't seem like it improves security for the browser (and definitely not for the server). Was it included "just for completeness" by the protocol designers? See also https://stackoverflow.com/questions/17992042

    by default-kramer
  • Sometimes I'm not even sure what I truly 'understand.' When even senior engineers working on products used by hundreds of millions of people, like Zoom, have had these kinds of issues, it makes me wonder. So I usually just write code the way it was left by my seniors, out of inertia. But I realize that the area I work in is actually incredibly abstracted.
    by jdw64
  • To understand CORS, you have to understand the Same Origin Policy.

    If you find CORS difficult to understand, particularly the question of "why do we need this?", I suggest starting here: https://developer.mozilla.org/en-US/docs/Web/Security/Defens...

    I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so you learn very little by bringing it up.

    by simonw
  • > I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so you learn very little by bringing it up.

    For hiring frontend developers, I've found it to be an excellent question, as surely if you've been developing web apps, you essentially must have come across it at some point. If you haven't, I'd be asking more questions about how typically you'd communicate with a backend and so on. Some people have hit the issues related to CORS, worked around it the quickest possible way then forgot all about it, rather than understanding what's going on, also a useful signal for some roles.

    Bit less good for backend roles, as not everyone has worked closely with a frontend team which tends to be the people hitting issues around CORS.

    by embedding-shape
  • This blog post is very misleading.

    > So what would a secure implementation of this feature look like? The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.

    First of all, its not CORS that protects. CORS is an anti-security feature. What does protect is the SOP (same origin policy). The SOP (or SOPs rather, it's not really one feature but more of a paradigm in the standards) blocks documents from one origin, from reading data that belongs to another origin. This is the reason why `let w = window.open("https://example.com"); console.dir(w.document.body);` will work when it is ran from example.com, but not wikipedia.org. Only when protocol, host and port match, can documents access each others data (there is an interesting differential with cookies here, their SOP only looks at protocol and host, not port).

    Importantly, the SOP only blocks reading data from other origins, not writing! So while example.com won't be able to read the response of a post request it sends to wikipedia.org, the request is sent and processed nontheless!

    CORS now is a feature that allows sites to loosen up the SOP. This allows documents to read cross origin data nontheless. Namely, HTTP responses. (Standards for reading other kinds of data cross origin exist, but are not related to CORS).

    by StrauXX
  • It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able to access that information and CORS allows you to weaken it.

    Example: SOP stops example.com from fetching the list of subscriptions on youtube.com. But CORS allows example.com to access youtube.com/public/*.

    This is also not the sole use-case, it also stops your backend api being up under a different frontend which would allow data theft since you could log into real services on google.com, but you're actually on g00gle.com enabling data exfiltration because now every request can be MitM'd.

    by himata4113
  • I love this, easy intuitive explanation
    by crackalamoo
  • To understand the threat model you need to understand historical decisions browsers made, such as when cookies are sent, and the distinction between actually sending the request versus allowing client-side JS to read back request content. The decisions are just really counterintuitive and often build on legacy precedent.

    I think the nature of threat model has also changed over time. Now that samesite cookies are the default, API requests made with the user's credentials shouldn't be an issue, but there is still value in preventing cross-origin reads to do things like preventing random webpages from scanning intranet (there are probably still timing side-channels though). I guess the limitation against non-simple post/get is also marginally beneficial for preventing ddos.

    by krackers
  • No, it's exactly the other way around. The SOP protects you from these security issues. CORS is a feature that can be used to loosen up the SOP, to allow more complex inter-application behaviour.
    by StrauXX
  • I'm one of them. CORS is THE topic that I have to get a refresher for periodically. It's like I forget about it, it never sticks. I'm a backend developer so I never encounter any cors issues. Maybe that's why? I seem to forget things that I don't use on a day to day basis, so.
    by mparnisari
  • I feel the same. Unfortunately, I've had to deal with CORS in a few situations where the request is "we need to get this thing from this server, but we can't change the servers CORS or CSP", which, in technical security speak is "we have this security system in place, we need to circumvent it".

    Ultimately, it almost always depends on the server only being accessed via an untampered browser request.

    The Zoom exploit was able to happen because CORS and CSP are so easy to get around on the client side, so Zoom did it. Sure, Zoom were bad/lazy/silly for doing it, but I feel we're bad as a community for still having this model.

    by 1dom
  • The biggest problem with CORS is precisely that most CORS errors show up as a frontend problem - specifically, a browser problem - but it needs to be fixed on the backend
    by yen223
  • The DX for CORS and CSP is horrible because none of the browsers point out where the problem is coming from. In a sane world they would all write "response header" or "meta tag" somewhere in the message but the Riddler, Jigsaw, the Cheshire Cat were each hired by the major browser vendors to write the error messages. Chrome is the closest with "requested resource" but that's still downright cryptic. But on the other hand I'm glad all three of them still agree on something.

    Edit: I realize that this is a fairly non-constructive comment, so to fix that, my suggested replacements are:

        Resource https://bank.com doesn't allow cross-origin requests due to lack of CORS headers. (Link to preflight request in Network tab) CORS protects against unaffiliated sites requesting data from your server. (Link to MDN)

    Resource https://bank.com doesn't allow cross-origin requests because this origin isn't in its CORS allowlist. (Link to preflight request in Network tab) ...

    Resource https://... can't be fetched due to CSP headers in this page. (Link to page request headers or meta tags in inspector) CSP prevents unauthorized scripts from executing on your page. (Link to MDN)
    by cyberrock
  • The only thing I remember about CORS is that it takes way longer than expected to debug, by design the error messages sent to the browser are intentionally gutted, and CORS error scenarios are hard to tell from other failure modes atfirst glance.
    by piyh
  • > by design the error messages sent to the browser are intentionally gutted

    A CORS error is not "an error message sent to the browser", it is an error generated by the browser, because the browser has decided it cannot permit the request. (Though certainly a server can not understand a CORS request as such, and returned a weird response, which would then end up getting translated to a CORS failure.)

    by deathanatos
  • It's not just CORS that's hard to understand. Many (most?) developers don't really understand the threat model. And even when it's explained it hard to see why it's a big deal. Part of this is that backend developers usually have to configure CORS and it's not an access privilege protection. From the point of view of the backend it doesn't seem to matter. Bad guys can't get it. From the point of view of the front-end it's often seen as a nuisance.

    The article does a nice job giving a concrete example.

    by encomiast
  • CORS is amazing for when you want to prevent people from (easily) stealing your bandwidth and hosting resources. Thieves have to stand up their own proxies, which makes them very easily blocked.
    by vachina
  • > Many (most?) developers don't really understand the threat model.

    It’s because CORS builds on a very odd base permission model. So if you use multipart form data, okay. But application JavaScript bad.

    by paulddraper
  • On top of that, it's a threat model that doesn't make really sense from an attacker vs defender perspective. Because it's optional, and all kinds of other libraries and tools can just blatantly ignore it anyways.

    CORS literally exists only against XSS and CSRF for actively logged in human users. Anything else in CORS is absolutely pointless because every other attack scenario uses scripts or programs that fake HTTP headers anyways. It's just as useless as the Sec-CH (client hint) headers because some Browser made by a company that starts with Micro and ends with Slop decided that the User Agent always needs to be Windows 10 for compatibility reasons.

    That is why you see everyone just enabling every CORS option anyways, even though that is literally the worst case that allows XSS and CSRF. And a lot of websites have user edited content at some place, at the very least in images that aren't filtered for embedded scripts (PNGs, anyone?).

    by cookiengineer
  • It’s not that hard to understand… in the cors threat model an attacker gets one your users to take an action on your site by visiting their site.
    by yaur
  • We had a project were the same developer wrote the frontend and backend and still managed to get CORS wrong. As the operations people we rewrote them correctly in the load balancer... well I assume correctly, at least the application now works.

    CORS is really hard to wrap your head around, but sadly there's also a ton of developers that not only fail understand the threat model that CORS guards against, they also don't understand webdevelopment in general, especially the http protocol. I find that somewhat strange, because they also can't do native application.

    by mrweasel
  • I wish more people read the CORS article on MDN[1] which helped me a lot at the time when I was trying to understand it. I knew some people had trouble with CORS but had no idea it was this bad, going by the comments here.

    [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

    by supriyo-biswas
  • Exactly this. I can only upvote you once, but this is one article that should answer all the questions. Not just the simple origin case, but also how a preflight works.
    by nedt
  • Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly:

    > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.

    No, that does not do that. JavaScript from any other website can still talk to localhost:19421 just the same. CORS doesn't restrict anything, it loosens the default set of restrictions (ignoring preflight requests for now and assuming we're talking just about "safe" Methods). That Access-Control-Allow-Origin header just allows JavaScript running on zoom.us to read the responses when it queries localhost:19421. The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects.

    by muvlon
  • “Can still talk to, but cant read the response” is a bit too simplied. You can’t post a json payload for example, which is how a JavaScript client would usually talk to a backend. You can only post using form data encoding, since this is already possible using a plain html form without any JavaScript. Anything beyound that, like json/xml payloads or methods other than post and get are blocked by default.
    by bazoom42
  • Importantly it only prevents clients that actually cares about the cors headers. Like ohh I'm from hacker.org and the http headers says it only allows zoom.us ohh nooooo. Like it's just a http header! Now if you use a mainstream browsers and you accidentally visits hacker.org in a iframe at some shady site - then the cors header will prevent your browser from accessing it.
    by z3t4
  • > (ignoring preflight requests for now and assuming we're talking just about "safe" Methods)

    You can't ignore those because they constitute the bulk of CORS' security model.

    Yes, you're technically right that CORS cannot prevent other websites from making any request to your server - this would be impossible, since the browser somehow has to get the CORS headers in the first place.

    However what CORS absolutely lets you do is prevent requests to particular endpoints - and you can then design your API in such a way that the dangerous actions are only available behind those endpoints and thus make it safe.

    I.e. what's missing in the TFA quote is that the server must also change the endpoint from GET to POST (in addition to setting the CORS headers) and remove the GET endpoint. Other websites would still be able to send a GET or a preflight OPTIONS request, but they wouldn't be able to send the actual POST request.

    As such, Zoom's workaround had two problems: They didn't set any CORS headers, which prompted the browsers to only allow "safe", i.e. GET requests - and then put an unsafe action behind the endpoint, therefore violating the "safe" assumption. Moral of the story: Don't put actions that do something else than returning a result behind a GET request.

    by xg15