5 ms·

There are many reasons. One old reason is because your browser will only make so many concurrent Connections to one domain, so this spreads the load. I'm not su

by ejcx 11y ago

There are many reasons. One old reason is because your browser will only make so many concurrent Connections to one domain, so this spreads the load. I'm not sure how many concurrent resources they will download nowadays though. Another big one is security of cookies and data, like you mentioned. Most of the time CDNs will return an access allow origin * header. This is literally the worst thing you can do for security of your users if they have a secret cookie. A different domain minimizes the risk of making a mistake to zero since it is completely separate, and is easier since you don't need any nginx funny business proxy passing to a server with static assets with a location directive. The allow access origin * is a death sentence that breaks same origin policy if you make a mistake.

dogma1138 11y ago
Cookies should be secured using the domain and path attributes. You share quite a bit of things with your CDN quite often various API keys, as well as SSL certificates unless you do not serve your main content over SSL in the first place. Most (I'm pretty sure all) CDN's give you the ability to set your own CORS policy if you see a CDN on cdn.example.com returns allow origin * then it means it's user did not set the CORS headers properly. Also the CDN can return allow allow and it still will not make a difference if you issue your cookies to the proper domain and path e.g. www.example.com/account if that's the domain and path there is no way a modern browser will attach that request to anything which doesn't sit on www.example.com and is located under /account. If you issue your auth cookies to .example.com and the / path don't be surprised why ever XSS and other client side attacks end up compromising your users, you can have 100 XSS's in your site, you can have a shitty CORS policy and if your cookies are issued and restricted properly it's more likely than not that those vuln's could not be leveraged to compromised your users' sessions (not through a classic session theft that is).
- ejcx 11y ago
  I'm not sure what your comment adds and if I'm reading it right there is a lot of information that's just blatantly wrong I cant discuss your whole comment because it's long and I'm on a phone. "If you issue your auth cookies to .example.com and the / path don't be surprised why ever XSS and other client side attacks end up compromising your users, you can have 100 XSS's in your site, you can have a shitty CORS policy and if your cookies are issued and restricted properly it's more likely than not that those vuln's could not be leveraged to compromised your users' sessions (not through a classic session theft that is)." There is so much wrong about this paragraph. Who needs session theft in the scenario you provide.. If you have 100s of XSS on your site and a bad CORs policy there is a lot an attacker can do... Data exfiltration is very easy if you can execute js and so are things like XSRF. A correct path and domain setting for cookies is important but web security is a lot harder than your acting like it is..
  - dogma1138 11y ago
    If you have XSS you can take control over many things including the browser whats your point? Using a CDN on a sub domain will not affect the security of your cookies if you issue them properly, it should not even be a consideration given the privilege level you already grant your CDN provider.

by ejcx 11y ago

dogma1138 11y ago

Cookies should be secured using the domain and path attributes. You share quite a bit of things with your CDN quite often various API keys, as well as SSL certificates unless you do not serve your main content over SSL in the first place. Most (I'm pretty sure all) CDN's give you the ability to set your own CORS policy if you see a CDN on cdn.example.com returns allow origin * then it means it's user did not set the CORS headers properly. Also the CDN can return allow allow and it still will not make a difference if you issue your cookies to the proper domain and path e.g. www.example.com/account if that's the domain and path there is no way a modern browser will attach that request to anything which doesn't sit on www.example.com and is located under /account. If you issue your auth cookies to .example.com and the / path don't be surprised why ever XSS and other client side attacks end up compromising your users, you can have 100 XSS's in your site, you can have a shitty CORS policy and if your cookies are issued and restricted properly it's more likely than not that those vuln's could not be leveraged to compromised your users' sessions (not through a classic session theft that is).

ejcx 11y ago
I'm not sure what your comment adds and if I'm reading it right there is a lot of information that's just blatantly wrong I cant discuss your whole comment because it's long and I'm on a phone. "If you issue your auth cookies to .example.com and the / path don't be surprised why ever XSS and other client side attacks end up compromising your users, you can have 100 XSS's in your site, you can have a shitty CORS policy and if your cookies are issued and restricted properly it's more likely than not that those vuln's could not be leveraged to compromised your users' sessions (not through a classic session theft that is)." There is so much wrong about this paragraph. Who needs session theft in the scenario you provide.. If you have 100s of XSS on your site and a bad CORs policy there is a lot an attacker can do... Data exfiltration is very easy if you can execute js and so are things like XSRF. A correct path and domain setting for cookies is important but web security is a lot harder than your acting like it is..
- dogma1138 11y ago
  If you have XSS you can take control over many things including the browser whats your point? Using a CDN on a sub domain will not affect the security of your cookies if you issue them properly, it should not even be a consideration given the privilege level you already grant your CDN provider.