91–100 of 118 posts
Earlier quoted context omitted.
3. Don't allow cross-platform requests in the first place; have your API consumers go through a server-side proxy on the same domain instead, or host it on the same domain in the first place.
I feel like this is overkill when you have something like OPTIONS which is very minimalist in its response. Unless I'm missing some obvious drawback with calling OPTIONS?
Excellent suggestion. These days chrome hides the preflight requests by default and you miss to notice the latency added for each of those CORS calls. Also we don't deal with CORS unless it's an external plugin that we include in our site. Earlier we had subdomains like api. .com, static. .com to parallelize network requests which required CORS to be setup. With H2 we got rid of all of them and load everything from a…
What’s H2?
CORS = Cross-Origin Resource Sharing. There, that wasn't so hard, was it? I assume this is written for web developers who find this the most familiar acronym in the world, but ... still, it would not kill anybody to include the definition of the acronym, perhaps even with a friendly link [1] to make it Even More Accessible. I'll be off looking at the lawn mowing robot, now. [1]: https://developer.mozilla.org/en-US/do…
Downvotes for a comment like this is really the low-side of Hacker News. Me: web developer since 1996. I had to look it up. Came here to make the same comment, and see you being lambasted for it. Don't let these haterz get you down. It's standard practice across ALL domains to define acronyms, and those who give this article a pass because ReASonS!! aren't people I'd willingly choose to work with: anglo-saxons who be…
If instead this said something like: "For the uninitiated, CORS stands for ...", I don't think it would've attracted any downvotes.
Earlier quoted context omitted.
As I mentioned above this doesn't work for all CDNs and also involves trusting your CDN to MitM your API
This kind of comment falls under what I posted originally - people making up reasons why they can't go with proxy solution.
It's like saying that a house built without a lock is a made up issue and that no lock pr door is needed.
Earlier quoted context omitted.
So that would indicate that you don't do end-to-end TLS on your infrastructure for the API which means that Fastly man-in-the-middles your API. In a lot of sensitive businesses that wouldn't be allowed.
Are you sure about that? Have you talked to a good lawyer about it?
You can't guarantee the integrity and privacy of the full request and response chain.
This goes against various security standards and ISOs.
You might be able to get away with it and trust the CDN but that's an awful lot of trust.
Earlier quoted context omitted.
I'll bite. I'm working on an application that uses Firebase, so the front-end is hosted on Firebase hosting (probably with some kind of CDN before that) and available through a firebase-supplied domain, and the back-end runs on Cloud Run behind a cloud-run-supplied domain. The domains are different, so CORS happens. I'd like you to back up your claim that a server-side proxy or using the same domain is the easiest so…
There's 1 way to solve this, and it's to have the same domain that the end client (browser, app) uses. It means you'd create 1 domain that's exposed to client and on the web server level you perform routing (proxying) to appropriate firebase/cloud run domains. As for whether that's easier - I've been doing it like this since forever, so I'm biased and it's easy for me. It's easy because I don't have to worry about pr…
CORS ain't that hard.
Earlier quoted context omitted.
This kind of comment falls under what I posted originally - people making up reasons why they can't go with proxy solution.
I don't think that security requirements are a "made up" restriction. It's like saying that a house built without a lock is a made up issue and that no lock pr door is needed.
Public CDN should never be trusted. If you use a CDN in the first place and have strict security requirements, then you create your own private CDN. And if you can control that private CDN, you have all the ingredients to avoid CORS.
It's really that simple. No one is saying you are wrong, but you're refusing to look at the entire picture and you focus only on a subset, in which - of course - your argument works.
Earlier quoted context omitted.
I don't think that security requirements are a "made up" restriction. It's like saying that a house built without a lock is a made up issue and that no lock pr door is needed.
They're not, but you're blatantly refusing to read what's being written. Public CDN should never be trusted. If you use a CDN in the first place and have strict security requirements, then you create your own private CDN. And if you can control that private CDN, you have all the ingredients to avoid CORS. It's really that simple. No one is saying you are wrong, but you're refusing to look at the entire picture and yo…
I'm sorry but that's simply not an acceptable constraint.
Earlier quoted context omitted.
Are you sure about that? Have you talked to a good lawyer about it?
This is not necessarily only a legal issue it's also an information security issue. You can't guarantee the integrity and privacy of the full request and response chain. This goes against various security standards and ISOs. You might be able to get away with it and trust the CDN but that's an awful lot of trust.
Earlier quoted context omitted.
This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.
If you serve your static files from a CDN it's simply not possible to do so. It's a very common case.
Say you stand up a website with an API at https://example.com. You host your static assets on the CDN, at https://example.myfastcdn.com/. So example.com's home page looks like:
What am I missing here?