9 ms·

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from

• leowoo91 7y ago
  As a motivation to use: To prevent other sites using your resources, causing you an extra bandwith cost.
  • davidw 7y ago
    Back in the day, we used to use some Apache redirect magic to redirect to, say, an image of our choosing when the Referrer header was wrong. I had a relatively polite 'hey, you can see this image here:' message. Other people redirected to less friendly things.
    • jefftk 7y ago
      You can still do this. The Referer header is sent by default on requests, and you can make your server interpret it to do anything you want.
      • gmfawcett 7y ago
        This is true unless the referring URL is secured (HTTPS), and the destination URL is not. In that case a conformant user-agent will leave Referer out. https://tools.ietf.org/html/rfc7231#section-5.5.2 https://tools.ietf.org/html/rfc7231#section-5.5.2
        • jefftk 7y ago
          True, though you should run HTTPS on your site. Which means you'll get the Referer unless the other site or the user's browser has been configured to suppress it.
  • icebraining 7y ago
    On the contrary: CORS is what enables other sites to use your resources (in a way allowed by your policy). It was created because, by default, browsers don't let you do that.
    • Drdrdrq 7y ago
      I think what GP commented is a very common misconception. CORS is not the source of the developer trouble (that would be cross-origin restrictions), it is a way around them. But it is perhaps understandable where the confusion comes from... Browsers always mention CORS headers as part of error messages, after all.
      • csours 7y ago
        +1 - This is a large part of the trouble. It leads to a lot of stuff being defined as the inverse of some other behavior - behavior that the developer does not have control or understanding of.
    • falcolas 7y ago
      But only one domain at a time. The lack of a way to specify multiple domains in a header makes it absurdly painful to actually implement when you want to make your content available to a specific set of domains. I’m personally at the point where I’d rather handle unnecessary request authentication than trying to do anything with CORS.
      • icebraining 7y ago
        I'm curious, why was it painful? We just had a middleware do an Origin check and copy the header if it matches.
        • falcolas 7y ago
          90+ microservices with 5+ environments. Mostly a matter of scaling a solution across a rather large surface area and across a number of languages and teams.
• edejong 7y ago
  I read extensive parts of the CORS specification and it is indeed teflon (and just as toxic as teflon as well). The spec is full of exceptions and leaves many choices to the browser vendors. To truly understand CORS, you have to fundamentally understand 'the origin' as a security and execution context. Sharing means that content normally intended for another origin is shared with the initial origin. Perhaps that is blatantly obvious and you are more confused by the myriad of headers, exceptions and lifetime. In that case, I propose to read more of the spec.
  • therein 7y ago
    > In that case, I propose to read more of the spec. Ingest more teflon when in doubt about its toxicity.
    • klodolph 7y ago
      But Teflon is non-toxic and biocompatible. You can eat it, your body is unable to process it or break it down and it will pass through your digestive system. You can coat surgical instruments and medical implants with Teflon. (Above 300°C Teflon will generate toxic fumes, but then again, so will wood.)
      • pil4rin 7y ago
        Wood tastes better
      • therein 7y ago
        > Above 300°C Teflon will generate toxic fumes, but then again, so will wood Unless you are a parrot. I've heard it is disproportionately toxic to birds. (or is it just parrots?)
      • hn23 7y ago
        I have read $somewhere that it accumulates in testicles. And why would I coat surgical instruments? Edit: Just one article how healthy Teflon is: https://fortune.com/longform/teflon-pollution-north-carolina/ https://fortune.com/longform/teflon-pollution-north-carolina...
• rolltiide 7y ago
  The only thing I know about CORS is when every web project I do starts generating funky errors and the fix is some CORS related copy-pasta I have to add. Very little objective thought involved.
  • alexbanks 7y ago
    I came to this thread hoping to find that I am not alone. Thanks for validating that for me.
• tgsovlerkhgsel 7y ago
  CORS stands for Cross-origin resource sharing. It allows you to make arbitrary HTTP requests across origins, even those that would normally be blocked by the same-origin policy, as long as the server collaborates and allows it, easily and in a secure way. If you control the server (or can get someone to adjust it, or it already supports it), you can use it to make requests from one website to another, directly from the client. For example, you can have JS on a site served on www.example.com make calls directly to api.someservice.net, without any kludges. Any time you think of some contrived proxy solution, JSONP, or other kludges to bypass the same-origin policy, you want CORS. For non-anonymous APIs, authentication can still be a challenge.
  • euroclydon 7y ago
    Well... CORS controls whether the browser lets the other page read the response, not issue the request, preflight not withstanding.
    • tgsovlerkhgsel 7y ago
      Yes, because issuing the request was already allowed despite the same-origin policy. For example, you can do GET requests with iframes, images or redirects, and POST requests with HTTP forms. The important part is that CORS can be used to relax any existing same-origin restrictions on HTTP requests. 1. If the same-origin policy isn't a problem for you, no need to change anything, obviously. 2. If you want to _tighten_ the same-origin policy, CORS isn't going to help you (as far as I know). 3. You can get rid of any request-related same-origin policy restriction with CORS, easily and in a way that is easy to secure. There is no need to build around it. 4. If you try to use something custom to achieve that instead, you're likely making a dumb mistake, because you're not only creating unnecessary work, but also most likely either breaking many more users than there are users that don't support CORS, or introducing a gaping security hole, or both. Usually both.
• superasn 7y ago
  I have some basic understanding of it. I'll try to simplify what I know if anyone else is feeling confused about CORS. - You visit evil.com. - Evil tries to makes an HTTP request to bank.com/transfer.php - But before the request goes through the Browser says, hey, wait a minute I first need to make sure if evil.com can access bank.com - Browser asks bank.com, if evil.com (also known as origin) is allowed by sending an "OPTIONS" request first (this is before making the actual request) - Bank.com replies in header saying "sure, everyone is allowed" (e.g. my bank), technically by setting a HTTP "Access-Control-Allow-Origin: * " header (or just evil.com instead of * ) - Browser is happy, it makes the requests and you get the data Of course there is more to this like the server can tell which HTTP methods evil.com can do like "POST", "GET", "PUT", etc using "Access-Control-Allow-Methods". If the browser needs to send the cookies too with the request ("Access-Control-Allow-Credentials"), etc. But that is pretty much the gist of it as I understand.
  • abstractbarista 7y ago
    Thanks for this; it helped me. Very naively, I don't understand why evil.com origin was allowed to make any request to other domains using any cookies/session/identity of the browser/user in the first place. Why was this accepted standard? I was blown away when I first learned that a request made to xyz.com while in a browser tab showing abc.com would actually complete the request using my identity on xyz.com.
    • tcheard 7y ago
      By default, under the same origin policy, a browser won't allow requests cross origin. But there are valid situations where you want a request from 1 domain to be made to other domains. This is where CORS comes in. CORS is a mechanism to loosen security, not increase it. It allows a server to say, these are the domains (outside my own domain) who can make requests. CORS headers should be set carefully so that you are only allowing the domains that should be allowed through.
      • ergothus 7y ago
        > By default, under the same origin policy, a browser won't allow requests cross origin. Save a rather short-but-impactful list of exceptions. > CORS is a mechanism to loosen security, not increase it. Would that everyone shared your understanding. Add in these two insights to those we are enlightening: * CORS is enforced by the browser, so no, your curl command working doesn't say your service is fine * That error message in the browser about 'no-cors'? It is 99% likely that no-cors is NOT what you want, so the error message is just misleading and unhelpful ...and you'll have covered my CORS wishlist :)
• anderspitman 7y ago
  Love the teflon analogy; can totally relate. At this point our team his literally anthropomorphized CORS into some sort of a malevolent entity actively trying to ruin our lives. But stick with it. It does slowly sink in. Something that especially confused me at first was that all of the CORS blocking happens in the browser. So you never run into CORS using curl, etc.
• ChrisCinelli 7y ago
  I was also surprised to read: "the browser explicitly ignores any CORS policy for servers running on localhost." on the Zoom vulnerability writeup. Among all the W3 specs, the CORS one is definitely not the largest spec. See https://www.w3.org/TR/cors/ https://www.w3.org/TR/cors/ Ultimately the Zoom vulnerability reminded us that there is always a trade off between usability and security. Most of the developers default to usability and simplicity. The average developer looks for the fastest way to achieve "what I want to do". And they do not even question installing stuff with "curl https://any.domain.com/any-script https://any.domain.com/any-script | sudo bash". And that is the root of all evils.
• WhitneyLand 7y ago
  This Teflon you're talking about, it's a thing. Not just with CORS, not just with you. For example, I've gotten decent at regular expressions a few times but have to keep relearning it. Adding insult to injury, I might relearn something from Stackoverflow, and realize afterwards I posted the answer! Not for trivial stuff. But a string of punctuation with capture groups or whatever, forget about it [1]. Any support for this informal draft definition below? ------------------ Teflon tech (draft definition v0.1 [2]) Knowledge that could be learned by most with reasonable effort, but often must be relearned or is never fully grokked. This can be due to infrequent opportunities to recall the concepts in a particular role, or insufficient need to apply (thereby practicing) the relevant techniques. It may also occur when a tech is used frequently but the foundational theory is hidden by the use of higher level abstractions. [1] https://stackoverflow.com/questions/1381097/how-do-i-get-the-name-of-captured-groups-in-a-c-sharp-regex https://stackoverflow.com/questions/1381097/how-do-i-get-the... [2] content provided under MIT license.
  • justinclift 7y ago
    Javascript is like this with me. I have no idea why. Probably my having a super low opinion of it's whole ecosystem doesn't help. ;)
    • lacampbell 7y ago
      I think it's 100% because you don't like Javascript. You resent having to learn it. I feel the exact same way about Git, I've never been able to stomach it, I'm bewildered as to why the entire programming community have decided it's the one VCS to rule them all, and I resent having to grok its UI. The Javascript ecosystem is huge. It's also the wild west, completely non-curated, open to anyone, and you have to treat it accordingly. It's not really one entity.
      • james_s_tayler 7y ago
        Git is amazing, beautiful piece of software. But... sigh I feel exactly how you feel about Git about Vim. It's the one editor everyone has decided despite it's arcane and bizarre UX that you aren't a real programmer if you don't know. Refuse to learn it. Absolutely refuse. I think everyone has one of those things.
• _bxg1 7y ago
  I think my personal brain-fog when it comes to web security is that it isn't just protecting the server from malicious clients, or the client from malicious data, or the user from a malicious client, but all of the above and then some. The attack vectors point every-which-way and it can get confusing whom you're trying to guard against whom in a given case.
• andrewflnr 7y ago
  I love that we're not alone in this. CORS is an antimeme, confirmed: http://www.scp-wiki.net/antimemetics-division-hub http://www.scp-wiki.net/antimemetics-division-hub