Live data from Hacker News

How to win at CORS

jakearchibald.com

111–120 of 128 posts

Re: How to win at CORS

#111

Earlier quoted context omitted.

Not 100%. There are a small handful of really wicked gotchas. I think there’s a lot of articles on them. I can’t find the one I like and don’t want to share one I haven’t read yet.

Here’s an example in each direction. In this first example, ASI inserts an undesired semicolon: return {a: 0} This returns undefined, and doesn’t continue on to execute the block containing a statement 0 with label a. (Change it to {a: 0, b: 0} and you get a syntax error because of this reinterpretation of what was intended as an object literal.) In this second example, ASI doesn’t insert a desired semicolon: f() [].…

The second example could be replaced with something more common like:

    f()
    ['foo', 'bar'].forEach(...)
Which is probably a type error, except if `f()` returns something like:

    function f() {
      return {
        bar: ['Not the array', 'you were expecting'],
      }
    }
Then you would actually iterate over the returned `bar` array, not the expected `['foo', 'bar']` array.

Another fairly likely example of a desired semicolon not inserted is when the following line starts with a template string literal:

    f()
    `This is tagged with whatever f() returns`
This will most likely be a type error, except if `f()` returns a function, that function will then be called on the template string to do whatever. However I have a hard time imagining when you would want to start a statement with a template string literal without doing something smelly like:

    `some ${interpolated} string`.includes(someVar)
      ? sideEffectA()
      : sideEffectB()

Re: How to win at CORS

#112

Earlier quoted context omitted.

Being an engineer who doesn't understand CORS is ok; I've worked with a few good ones who struggled with it, so clearly CORS is not a very intuitive tech. Not understanding CORS and making a comment like this is taking that ignorance to a new level though. Please read up on what you're talking about.

Please tell me more about how publically accessible by anyone REST API's need CORS. Are you actually suggesting people have to tell companies what domains they will be calling an API from, in order to add it to the list of allowed domains, in the code base?

Does your publicly accessible API provide contextual information based on client-state? It probably doesn't, in which case you're right, CORS isn't needed, and lo and behold, this is exactly what the Origin wildcard is for. Adding it isn't a big deal.

But no, it's not really a great idea to make every single privileged API in the world completely insecure just so the admins of public APIs can avoid adding a wildcard header to their servers.

Re: How to win at CORS

#113

Earlier quoted context omitted.

Just use http-proxy to set up a local domain so you can access your dev environment at frontend.yoursite.local (proxied to localhost:3000) and the api at api.yoursite.local (proxied to whatever 3rd party api). Boom, problem solved. You can even rewrite headers and content of the requests in and out.

Do you have any recomendations, which proxy to use? Specifically on Win.

https://www.npmjs.com/package/http-proxy

Integrates nicely with existing JS frontend tooling.

Re: How to win at CORS

#114
post #103

Earlier quoted context omitted.

I tried to achieve the same thing in the past and have run across issues with HSTS. The details are escaping me but I think it might have been that when using the production app without a proxy, the SSL certificate was associated with the HSTS records in the browser and when I switched to a proxy, the HSTS started failing because the certificate has changed. Have you run into this at all? How have you solved it?

HSTS doesn't complain as long as there's a valid certificate. If you ran into problems because of different certificates, you probably had HPKP.

I run into occasional HSTS issues on my home network sometimes because I've wildcarded HSTS and not everything internal has a cert. It's usually recently arrived IoT stuff that hasn't been cordoned off behind a stronger proxy.

Additionally, I run my own internal CA for various reasons and Firefox/Android seems to have stopped recognizing it. Irritating but it's a good razor for whether to upgrade internal or experimental apps to a Let's Encrypt cert.

Re: How to win at CORS

#115
post #93

I've banged my head against some CORS puzzles recently. That's a pretty good guide, but I actually know an extra quirk that was missed: You know that nice "Access-Control-Allow-Credentials: true" header? In theory, it means that you can make authorized requests with cookies included to the cross-origin API. It actually has some extra rules that aren't obvious though. The cookies won't actually send unless they explic…

The article mentions the SameSite stuff early on, then kinda mentions it in passing when it comes to CORS + credentials "The same-site rules around cookies still apply, as do the kinds of isolation we see in Firefox and Safari. But these only come into effect cross-site, not cross-origin". Seems like I need to word it better though.

Is it fair to say that the strongest CORS request allows the weakest? That is, if your server supports a preflighted, credentialed, cached CORS request with weird headers and methods, then it would support just about anything?

Perhaps a detailed walkthrough of that one specific scenario, which would enable almost all others, would be helpful.

Re: How to win at CORS

#116

Earlier quoted context omitted.

I don't develop at the same URL as I publish at - I'll generate keys with mkcert and host my site locally via a proxy at local.realdomainhere.com for a site that has dev.realdomainhere.com and the prod domain www.realdomainhere.com.

I see, I misunderstood. My dream setup is one where I have the same URL for TEST/STAG/PROD and just switch which BE the URL resolves to based on some configuration/tool.

I have a certain workflow similar to this.

1. Let testing/staging environments present the same, valid certificates and keys as your production domain. Simply keep a copy for your internal use.

2.1 modify /etc/hosts so that production aliases localhost

or

2.2 let an internal DNS service do the spoofing work.

You'll still need some action to switch between environments. Full ownership of certificates is a recommendation. At your own risk.

Re: How to win at CORS

#117

> remember, the 's' in 'IoT' stands for security I don't know why, but this cracked me up. :D

Worth noting that it's a fairly common saying, not something he came up with for the article

Re: How to win at CORS

#118

Earlier quoted context omitted.

Being an engineer who doesn't understand CORS is ok; I've worked with a few good ones who struggled with it, so clearly CORS is not a very intuitive tech. Not understanding CORS and making a comment like this is taking that ignorance to a new level though. Please read up on what you're talking about.

Please tell me more about how publically accessible by anyone REST API's need CORS. Are you actually suggesting people have to tell companies what domains they will be calling an API from, in order to add it to the list of allowed domains, in the code base?

> Please tell me more about how publically accessible by anyone REST API's need CORS

It's not security for the provider of the API, it's security for the user of a web browser

Re: How to win at CORS

#119
post #101

Earlier quoted context omitted.

ServiceWorkers also don't play nice with CORS in my experience. We often need to bypass them in Angular when making certain requests.

Author here! I'm also an editor on the service worker spec, so I'm interested to know where the pain points are.

Hi Jake! (I watch your videos ;)) Many times, the (Angular) ServiceWorker has given us CORS headaches on various requests to our APIs and AWS storage files. The only method we've found, after various AWS configs and ngsw-config.json attempts, was to add `ngsw-bypass=true` to all requests. I'll see if I can find the Github issue, where this has come up before.

Incidentally, while you're here, I'm planning on building something which will require use of SharedArrayBuffer. Will adding the (now) required Cross-Origin isolation COOP/COEP headers cause any issues to existing CORS setups?

:)

Re: How to win at CORS

#120
post #119

Earlier quoted context omitted.

Author here! I'm also an editor on the service worker spec, so I'm interested to know where the pain points are.

Hi Jake! (I watch your videos ;)) Many times, the (Angular) ServiceWorker has given us CORS headaches on various requests to our APIs and AWS storage files. The only method we've found, after various AWS configs and ngsw-config.json attempts, was to add `ngsw-bypass=true` to all requests. I'll see if I can find the Github issue, where this has come up before. Incidentally, while you're here, I'm planning on building…

COOP+COEP won't change how CORS works, but it means you can't have no-cors resources on your page unless they have CORP headers
Post reply on HN