Hacker News Reader

Comment by 3pt14159 | Hacker News Reader

I'm ideologically against third party on the web because it is a privacy nightmare. But I'm in the system that I'm in, and I don't take on fights that aren't possible to win, so barring my becoming a billionaire I've kinda just accepted that third party is here for at least a little while and I'm not going to refuse to use ads and analytics. Except on my personal website, that gets to stay cool.

That said, CORS is the only thing about third party that I actually like. It's secure by default. That the ensure header and accept header are different things is amazing. I know all about the performance issues[0], but I'm ok with it in the right context.

[0] It's kinda funny how against the herd I am here. I think it is shitty that the preflight sometimes doesn't happen. It's so weird to me that we carved out exceptions for this and seems like an otherwise secure-by-default system should have come with the guaranteed preflight.

View on HN

CORS is not necessarily about third parties.

It's common to have app.example.org point to a CDN and api.example.org point to an API.

And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself.

The reason it's implemented this way is because of the organic evolution of web security.

> rather than just enforcing access itself.

Could you elaborate on that? I can't picture the alternative you're suggesting.

Same here... from what I can tell, only the browser has reliable information about what's happening. How could the server know code from another domain is making the requests? And if anything, the web is more secure - desktop native applications can usually access each other's data and do malicious requests to remote servers using stolen credentials just fine.

Via the Origin header, just like the preflight requests use. The server is ultimately the one telling the browser what the rules are already. The reason a preflight is needed is so that there is effectively a default deny policy, since both historically and even today you can’t assume all APIs that accept authentication tokens from the browser take into account any kind of cross origin access.

Even still, a lot of people just put ‘Access-Control-Allow-Origin: *’ on everything as soon as they run into an issue, so that rule has to ban credentialed requests altogether.

You are talking about the Origin header set by the browser that you don't trust?

The whole point of CORS is that you trust the browser to do the preflight requests and obey them, otherwise it doesn’t do anything. If you have access to the credentials (which the browser does) and the ability to send whatever HTTP requests you want, you can bypass CORS entirely.

Using HMAC or API keys.

The alternative is for the idea agent to send the Origin header on all requests.

Then the server responds with 200 or 403.

The origin could still be falsified client-side.

No, it can't be falsified by JS in the browser. CORS is only relevant for JS in the browser; it doesn't impact curl at all, for example.

This is kind of like the reports I see every so often to Django's security address, where someone demonstrates that they can CSRF their own session.

The reply is always "yes, you can CSRF yourself, because it's not supposed to protect against that; it's supposed to protect you from other people". In exactly the same way, CORS is there to protect you from other people. You can always hack your own user-agent to disregard CORS, but the only person you can harm that way is yourself.

The people with the security problem are the users of browsers, and the browser vendors have a solution to solve that problem built into the browser. If they didn’t enforce it at the browser level, the owners of the servers would have little incentive to enforce CORS and most just wouldn’t. See https adoption.

Bingo. I still kind of wish there was an ability to make the browser invoke some kind of request that servers would reject by default (e.g. with a non-standard HTTP method) that could combine the preflight check and the request while still making servers that don’t anticipate CORS blanch and not take any dangerous actions. But the browser security model is complex and messy enough as it is, so I doubt it’s worth it.

> the owners of the servers would have little incentive to enforce CORS and most just wouldn’t

Huh? They already implement authorization. (Transport security is similar but different.)

And I've seen plenty of Allow-Origin-Access-Control: * because people get frustrated with CORS, e.g. they can't allow access for *. example.org.

Then it means that a service is vulnerable by default unless it implements the list of allowed origins. With CORS if there are no headers then it means no authorization.

CORS protects users, not services, so it's entirely reasonable that the evaluation of policy occurs in the user agent.

Actually, CORS protects both.

If CORS aimed to only protect users, there would be no need for a preflight at all. The only reason preflights exist is to protect services from receiving requests they might really not expect (e.g. malformed data) and doing bad things as a result.

In particular, the idea is to protect non-publicly-routable services. Publicly-routable ones, where you can just issue an attack request with cURL or the like, have to be hardened against malformed requests to start with.

But there are tons of non-publicly-routable things (think printers and the like behind firewalls) that could be attacked via browsers that are running behind the firewall loading web pages from outside the firewall. And CORS aims to mitigate or prevent some of those attacks.

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself.

The only concerns of CORS is with Javascript running in the browser. CORS is not about server-side security but what Javascript can or cannot access. It is there to protect the browser's user and make script execution more secure.

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself.

That's a typical misunderstanding of purpose of CORS. Regardless of your website setting or not setting CORS, an attacker with a modified browser or a custom browser can ignore it. That's not what CORS protects from - CORS protects against a non-modified browser uased by Joe Random User installed via a factory/distribution path being tricked into doing something against the site policy, therefore exposing the user.

I don't misunderstand.

My beef with CORS is that I have to encoded the validation logic into its HTTP headers.

But maybe what I want doesn't fit in its headers, e.g. I want to allow requests from *.example.org. So then I am writing server code, and if I am writing server code anyway, why have the extra step of encoding validation logic in CORS headers in the first place?

Surely you can implement your security rules this way. But for most people CORS are a cheaper way to enable cross origin requests. And clueless people are stuck with same origin policy which secure by default.

> CORS are a cheaper way to enable cross origin requests

Is it really that much more expensive to check the Origin header than to check the Authorization and Cookie headers?

If your server can handle Origin checks that way, then leave your CORS headers wide open and problem solved.

The problem is that existing servers don’t generally check origin headers, so browsers needed some other mechansim to understand which requests were safe.

You are still thinking about a server checking if a browser is trusted to run some code on a server, when the CORS is about a browser deciding if it should trust some of the server response.

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself.

I disagree. The current model where the server has to opt-in to cross origin access by explicitly sending an Access-Control-Allow-Origin header is secure-by-default, whereas a model relying on the server to enforce access would be insecure-unless-the-server-properly-checks-the-origin-header, leading to all sorts of vulnerabilities.

It's already insecure-unless-the-server-checks-the-cookie-header.

Something servers already do.

It’s secure in a “trust the client” manner. Any server code not still doing its own authentication is in for a rude awakening.

If you don’t trust the client, there is nothing you can do. An insecure browser could spoof the origin header too.

I think you’re missing my point. While you can assume well behaved clients will reduce unwanted traffic, a malicious client will spoof everything it can. Thus, there is definitely something you can do: you should never trust the client and the server should authenticate every request (as if CORS didn’t exist) instead of assuming all requests from clients are valid.

> The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself.

That's not true. You can set CORS: * and validate all requests in your server. The extra rules are for vast majority of servers that never inspect Origin headers.

Exaclty. This is a big concern for me. The server is really telling the browser what to do. But the browser can ignore it. It is quite a hacky an inellegant model. Very broken.

CORS are about browser security. A browser can have terrible security in lots of ways (allowing JavaScript to access http only cookies, etc). In this case you have a bad browser and you should not use it.

But you can still use IE, edge, chrome and Safari and trust that they implement CORS and most other basic security features correctly.

Our microservices stack is pretty dependent upon clients making cross-origin requests. I don't necessarily consider these "3rd party".

Case by case basis, but it's not uncommon to have clients hit a single domain and route the traffic based on the url. Exposing a microservice architecture to clients has pros and cons, of which this is a con.

That would mean each call made by the client would require a preflight OPTIONS call.

That means extra delay, extra db connections and calls, etc.

How do you deal with them?

Pre-flight overhead, yes (maybe 30ms?)

DB connections are pooled and cached using AWS Lambda.

btw- Our app is a plugin, so origin is always the platform provider... then our app makes CORS calls to AWS.

Reply on news.ycombinator.com