CORS is shit
Stupid useless shit that protects from nothing. It is harmful mechanism that does nothing but randomly blocks browser from accessing resources - nothing more.

Main idea of CORS is that if server does not send proper header to OPTIONS request, browser will block other requests to that server.

What does stupid cocksuckers that invented CORS, think their retarded shit can protect from?
- If server is malicious, it will send any header required to let you access it.
- If client has malicious intents - he will never use your shit browser to make requests, he will use curl or any ther tool available. Also if server security bases on something as unreliable as http headers it sends to the client - its a shit server, and CORS will not save it.

Can anyone give REAL examples when CORS can really protect from anything?

Well. Yes.
The idea of CORS is to allow some sort of client side defense against cases where a 3rd party can control an element on the regular served page.
Think Github issue, with an html block in it, that was created by a malicious party. CORS will prevent the injected html from loading a resource from the attacker server.
However - nothing prevents the attacker to include the attack directly in the html.
Developers hate CORS - it is not helpful for them during the dev process.

@magicMirror Even though you’ve given a valid use case for CORS, I still hate it with a burning passion

Most of such algorithms protect from bots scanning the internet looking for known vulns. They do not protect from targeted elaborate attacks.

How does that even make sense? CORS is the relaxing mechanism for SOP so that without CORS, you'd only have SOP.

@magicMirror Of course dropping any securty makes things easier for devs - unfortunately, also for black hat ones.

Like, being logged in to a banking site, also visiting an unrelated site that was hacked, and presto, the hacked site can use a malicious script to read any data from the banking site. Well, actually not, because the banking server did not put the unrelated site in the CORS list so that SOP applies.

@Fast-Nop it's funny how always CORS, the solution gets blamed.
Either learn about same origin policy or don't do web development.

If you like to be open to the world and don't use protection your "site" will get infected...

@magicMirror
"CORS will prevent the injected html from loading a resource from the attacker server" - No it will not. Broser will send option to attacker server and server will provide headers that will allow browser to access it.

@netikras
"Most of such algorithms protect from bots scanning the internet looking for known vulns. They do not protect from targeted elaborate attacks" - How? can you provide an example?

@magicMirror
"Like, being logged in to a banking site, also visiting an unrelated site that was hacked, and presto, the hacked site can use a malicious script to read any data from the banking site." - How would it read any information from banking site? It does not have access to login tokens. Banking site server will reject conenctions with 401

@hjk101
"Either learn about same origin policy or don't do web development." - looks like you know a lot about web development and same origin policy, now please show an example on how CORS can protect from any kind of attack.

@Argos As long as you're logged in to the banking site, the browser sends the required cookies. It's not the malicious script that has or would even need the authentication details, it's the browser. That's a direct consequence of HTTP's stateless design.

@Argos Let me use something you perhaps understand:

@Argos: "port fowards are stupid. They are a hasle and don't protect against any attack"

Me/@Fast-Nope: "well actually a firewall is the security mechanism that blocks ports. Forwarding is a solution to allow exceptions"

CORS is not a security measure it is an explicit relaxation. It allows to break same origin policy. So CORS will never prevent any attack...

https://developer.mozilla.org/en-US...

Please read up on same origin policy to see the host of XSS attacks it prevents.

@Fast-Nop
"As long as you're logged in to the banking site, the browser sends the required cookies"

Do you mean that if I have cookies for a.site and script on b.site in other tab sends request for a.site, browser will automatically add all cookies set by a.site to request actually sent from another tab?

If that is thuth - then this is what should be disabled in browser, not actually sending the request. It is stupid to block tool made for sending requests(browser) from doing its job. It's also stupid to attach auth tokens to request that was sent not from the tab that received that tokens.

Also it sounds more sound that server should examine request origin and decide to send sensitive data back or not rather than rely on that browser will not try to access that data.

@Argos Yes, that's how it works with the cookies. Note that the browser does actually block that because of SOP. CORS in turn is what can override SOP, but that would require a.site to use CORS to allow the browser to give read access to a script from b.site.

The a.site server in turn cannot block that because it has no way to discern that the script is from b.site, given that it is running client-side and not on the b.site server.

It is not stupid to attach cookies to another tab because cookies aren't even related to any tab. That's because they were originally meant to reliably implement something like a shopping cart, and that should work even if the browser crashes (with session persistent cookies).

I think you should read up on the basics of cookies, SOP, and CORS. While you're at it, also on CSRF because CORS doesn't capture everything, by design.

@Argos backend and frontend are complementary. Through frontend you are accessing the backend. Frontend knows how exactly to access BE (what headers to send, what Origin to supply, etc.). FE is publicly available, hence that info is also publicly available.

However, if you are scanning the internet and you come across some BE server, you have no clue where its FE is, nor how to find it. Even though it's public. And w/o FE server you don't know how to access the BE API properly.

@Argos just blocking cookies is not enough. One can encode your session cookie for example in POST data, get parameters, and even path

@Fast-Nop
"The a.site server in turn cannot block that because it has no way to discern that the script is from b.site, given that it is running client-side and not on the b.site server."
- But server can access headers.origin to determine that, can't it?

"It is not stupid to attach cookies to another tab because cookies aren't even related to any tab."
- That is sad, isolating cookies to tab could protect from CSRF better than everything else I think. What about localStorage? It is tab related, thus I think it could be better to store tokens there and manually attach them when needed, rather than trust that to cookies that are auto attached, thus can be used for actions that require authentication on a.site by scripts running on b.site. Which sounds really bad.

"I think you should read up on the basics of cookies, SOP, and CORS."
- Already done it on MDN, still has a lot of questions, can you suggest any good article/book/video about it?

Thanks for the reasonable replies.

@Argos The main problem with the origin header check is that this is "opt-in" security, server-side. SOP/CORS, on the other hand, provides "opt-out" security.

If you mess up "opt-in" security, you won't notice until you get hacked. However, messing up "opt-out" security gives a clear indication that more work is required because things simply don't work.

Also, there are much fewer browsers around than servers, so it's a lot easier to put it in the browsers. Plus that the point is protecting the user, so it makes sense that the user's software does that part. A user won't want to rely on random website operators.

Relating cookies to a tab would mean that your shopping cart would be gone if the browser crashes or you accidentally close the tab. Not good. You couldn't shop with several tabs in the same shop, either.

I usually start with Wikipedia to get a first overview, then MDN, then searching e.g. for SO threads.

CORS is a setting servers send to tell browsers that they allow the specific request. Its client side protection and solely depends on web browsers to implement it and there is no other way to do this kind of protection.

Without it, I can make a specific JS code on my web site for every person which visits that I can harvest their facebook info if they are logged in it with their cookies (as it was the case before) and store it on my web server and they would never know.

Without it, if you are admin on a wordpress website for example, I can make a request to create an user with admin privileges which browser will happily do using your cookies and you wont have any idea.

These are examples of CSRF which were possible before CORS was added.

@Argos localStorage is not tab based. It is website domain based, similar to cookies. You can have multiple tabs sharing one same localStorage access as long as they are on the same domain. It is sometimes used for communication between tabs.

@Fast-Nop
Thanks.
Why cookies can not be isolated by domain then? Like if I am in a tab that is displaying b.site it is impossible to attach any cookies that were saved by a.site to any requests that tab makes.
Looks like perfect protection to me. We still can load images and other not secure stuff from cross-origin, but no sensitive data that requires authentication can be received from a.site by scripts running on b.site.
Rather than completely blocking browser from making requests we can block it from sending cookies.

@Argos @Fast-Nop
CORS is not the solution for all web attacks. JS exploitation still exists, expolit kits are still out there, the log4j crap is here to stay, along with many other unpatched security holes.

Also - there are many attack scenarios where CORS is not relevant.

The important take away here is to make sure you do not disable security when developing/testing your work.

@arekxv
Why just don't block browser from sending cookies to cross domain requests rather than completely blocking it from sending any request?

The CSRF attacks you describe could be completely avoided if browser would not attach cookies aquired from a.site to requests made in tab that is showing b.site.

Like it works with local storage, if I never save login information into cookies and store it in localStorage instead, let's consider your example with website that tries to steal facebook information. How can it steal it if facebook auth token is in localStorage of facebook domain and is manually attached to requests made by facebook scripts rather than rely on browser cookies? Isn't that better than inventing SOP that blocks everything even harmless requests?

@Argos Mostly because of legacy apps, browsers and hardware using the cookies that way. Also new browsers added a solution for that already. Google chrome forced it two years ago with SameSite property in cookies. All cookies without anything set default to SameSite=Lax. Meaning cookies are only sent with the request if the user is actually navigating to it. It would effectively prevent the exploits I mentioned, unless you do SameSite=None.

Sometimes you want to have that ability. There are some solutions for cross login to two applications with one cookie: login to admin, logs you into the frontend. Basically not to have two login places. Some applications use that cookie approach for verification across the suite of apps. Others use cookies to track you across domains, etc.

Its a product of its time and there still are some ok uses for it, but I think its on its way out.

@Argos We're getting there, but third party cookies are still used. Mostly for cross-website tracking, i.e. the ads cancer.

Google wants to kill third party cookies, but there's resistance because the ad fuckers fear that Google might abuse that transition to further its own position.

On the other hand, data protection activists fear that whatever Google might introduce would be even worse than third party cookies because you can disable them completely already, right now.

@Argos read my last comment than you see why just blocking cookies does not prevent hijacking cookies.

@arekxv
"Also new browsers added a solution for that already. Google chrome forced it two years ago with SameSite property in cookies"
- Yeah I've read about that, looks much better than SOP. Why don't they replace SOP with SameSite property? It solves all of the problems the SOP does, but without so much restrictions. (Why blocking requests that don't send cookies)

@hjk101
"One can encode your session cookie for example in POST data, get parameters, and even path"
- How can he do that? Is it possible to access cookies from a.site, for a script running on b.site domain? I think no, how then?

@Fast-Nop
Damn ads are pain indeed

I wanna say thx to you all guys for the talk esppecially for
@Fast-Nop and @arekxv
Now I understand that it should be called SOP (and CORS is a mechanism to bypass SOP if needed) and its main idea is that legit browser and legit server can protect the data of a user, that visits "bad" webpage running malicious scripts, from being acessed.
And scripts are possible to do such harm because cookies work like shit. SameSite cookie property can help that as well, but it arrived later than SOP.

@Argos Btw., in the old days, domain sharding was hot because splitting one's stuff over several domains improved performance. That's mostly gone now with HTTP/2 of course and will be completely removed with HTTP/3.

However, it still makes sense to put data with cookie requirement on a different subdomain so that generic assets (CSS, company logo etc.) can be loaded without cookies. That saves mobile data volume.

The consequence is that limiting the tab loading permissions to exactly that full domain including the subdomain wouldn't make sense. At the very least, you need to allow non-cookie data.

@Argos the key word there is running. If a.site loads a script from b.site or runs otherwise injected js than it runs on a.site and thus has access and can send it wherever. There is also cross site request forgery and other trucks for you to read up on.

@hjk101
"a.site loads a script from b.site or runs otherwise injected js than it runs on a.site and thus has access and can send it wherever"
- oh my... I didn't thought about that, that would definitely break the isolation! Thank you for the explanation, a lot.

its clear that you have had issues with CORS and are super mad at it. probs cuz u code like a retard and ur site is also super insecure like ur SSH server is dogshit and ur login page on port 8080 is so easy to hack a baby could do it