5 ms·

Given that CDNs are used on many different sites, it's easy for people running CDNs to track other people around the internet. There are also security issues:

by walrus 11y ago

Given that CDNs are used on many different sites, it's easy for people running CDNs to track other people around the internet. There are also security issues: if you're referencing some JavaScript from a CDN, you're trusting the people running the CDN to actually serve the JavaScript you request.

herge 11y ago
Also, you have to be very careful to not share your apps cookies, or only the right cookies if necessary, with the CDN.
reacweb 11y ago
Do not trust the CDN: link(href='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css', rel='stylesheet' integrity='sha256-MfvZlkHCEqatNoGiOXveE8FIwMzZg4W85qfrfIFBfYc= sha512-dTfge/zgoMYpP7QbHy4gWMEGsbsdZeCXz7irItjcC3sPUFtf0kuFbDz/ixG7ArTxmDjLXDmezHubeNikyKGVyQ==' crossorigin='anonymous') script(src='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js' integrity='sha256-Sk3nkD6mLTMOF0EOpNtsIry+s1CsaqQC1rVLTAy+0yc= sha512-K1qjQ+NcF2TYO/eI3M6v8EiNYZfA95pQumfvcVrTHtwQVDG+aHRqLi/ETn2uB+1JqwYqVG3LIvdm9lj6imS/pQ==' crossorigin='anonymous')
- ejcx 11y ago
  To be fair SRI is brand new and doesn't exist yet in most browsers (just went live in chrome in the last..month?). It isn't realistic to expect most people to already be using it.. You can check a particular browser for SRI support using https://ejj.io/sri/ https://ejj.io/sri/
  - smithclay 11y ago
    Despite minimal browser support, it's still nice to start seeing projects like this that make it very easy to implement SRI (for Wordpress users, in this case): https://id.wordpress.org/plugins/wp-sri/ https://id.wordpress.org/plugins/wp-sri/
- jdorfman 11y ago
  as @ejcx said it is Sub Resource Integrity (SRI) and we (BootstrapCDN/MaxCDN) should be more clear on what SRI is so it doesn't cause any panic. Thanks for the feedback. If you have any questions or concerns you or anyone can email me jdorfman at maxcdn .com
- mervinej 11y ago
  Here's the W3C spec on SRI -- http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ -- if you still prefer not to use it, you can opt to remove the 'integrity' attribute, it's being provided as a convenience. link(href='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css', rel='stylesheet' crossorigin='anonymous') script(src='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js' crossorigin='anonymous')
  - Animats 11y ago
    Subresource integrity keeps CDNs honest. If a CDN is "incompatible" with subresource integrity, they're doing a MITM attack on your users and your site.
- securefail 11y ago
  So Integrity checking it just that, checking that the code is actually what you have uploaded. Having worked closely with the great people have made the SRI specification(www.w3.org/TR/SRI/) I can guarantee any CDN supporting integrity checking want to ensure you get the correct content. If they didn't care about delivering the correct content they would be pushing back against the specification / using it. This is why I have pushed bootstrap to start using integrity checking to prevent this form of code injection. But yeah there isn't a requirement for you to use this with a CDN either (I get whilst the browser support isn't there on a bank site it wouldn't perhaps be ideal - this has always been the case unless you are in charge of the CDN content) what it does do it inform me that they won't be delivering variable content of any kind whatsoever as SRI would break that code if they tried to load malicious content. Justin who has also replied to this message works closely with developer outreach at MaxCDN and cares greatly about their product 'doing the right thing'™ Let me know if you have any further questions about SRI as I can probably answer then for you. Jonathan Kingston
buro9 11y ago
> There are also security issues: if you're referencing some JavaScript from a CDN, you're trusting the people running the CDN to actually serve the JavaScript you request. In the HTTP/2 world, it will likely be better to not do this. The old tricks of relying on it being in browser cache already doesn't forego the fact that the connection to the server is expensive and HTTP/2 gives you a nice open connection to your server already... I would bet that a site is faster by taking as many third-party or other domain assets and putting them back on the same domain and same server.
- elithrar 11y ago
  > I would bet that a site is faster by taking as many third-party or other domain assets and putting them back on the same domain and same server. There are other advantages to using a CDN beyond 'optimizing' browser cache usage: getting assets closer to your users reduces latency (and therefore increases throughput), which can be a noticeable benefit if you're hosting in San Francisco and serving Oceania/SE Asia. HTTP/2 won't change that: it will just mean distributing assets over multiple domains (to circumvent browser pipelining limits) will make less sense, but putting one asset domain behind a CDN will still be beneficial.
  - buro9 11y ago
    Ah, I should clarify... if you already have your whole site on a CDN, and that CDN supports HTTP/2, then you are probably best not sending request to lots of other domains if you are able to serve the request from your own domain. The connection overhead of DNS + connection + TLS is still significant... and HTTP/2 means you'll already have a connection to your server, and the assets could already be being pushed to you, but at the least you'll be able to grab them from the same open connection.
- Encosia 11y ago
  Assuming you serve the CDN content with good caching headers, there's no connection required in the case of a cache hit.
  - 11y ago
ultramancool 11y ago
crossorigin='anonymous' solves the privacy issue, SRI will solve the security issue. If you use JS blocking like NoScript, which doesn't appear to support per-site access restrictions, I'd suggest you switch to something like ublock origin's advanced mode, which allows you to allow individual sites to access specific CDNs.
cbr 11y ago
> you're trusting the people running the CDN to actually serve the JavaScript you request Subresource Integrity [1] lets you fix this, and is in FF 43 and Chrome 45. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/

by walrus 11y ago

herge 11y ago

Also, you have to be very careful to not share your apps cookies, or only the right cookies if necessary, with the CDN.

reacweb 11y ago

Do not trust the CDN: link(href='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css', rel='stylesheet' integrity='sha256-MfvZlkHCEqatNoGiOXveE8FIwMzZg4W85qfrfIFBfYc= sha512-dTfge/zgoMYpP7QbHy4gWMEGsbsdZeCXz7irItjcC3sPUFtf0kuFbDz/ixG7ArTxmDjLXDmezHubeNikyKGVyQ==' crossorigin='anonymous') script(src='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js' integrity='sha256-Sk3nkD6mLTMOF0EOpNtsIry+s1CsaqQC1rVLTAy+0yc= sha512-K1qjQ+NcF2TYO/eI3M6v8EiNYZfA95pQumfvcVrTHtwQVDG+aHRqLi/ETn2uB+1JqwYqVG3LIvdm9lj6imS/pQ==' crossorigin='anonymous')

ejcx 11y ago
To be fair SRI is brand new and doesn't exist yet in most browsers (just went live in chrome in the last..month?). It isn't realistic to expect most people to already be using it.. You can check a particular browser for SRI support using https://ejj.io/sri/ https://ejj.io/sri/
- smithclay 11y ago
  Despite minimal browser support, it's still nice to start seeing projects like this that make it very easy to implement SRI (for Wordpress users, in this case): https://id.wordpress.org/plugins/wp-sri/ https://id.wordpress.org/plugins/wp-sri/
jdorfman 11y ago
as @ejcx said it is Sub Resource Integrity (SRI) and we (BootstrapCDN/MaxCDN) should be more clear on what SRI is so it doesn't cause any panic. Thanks for the feedback. If you have any questions or concerns you or anyone can email me jdorfman at maxcdn .com
mervinej 11y ago
Here's the W3C spec on SRI -- http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ -- if you still prefer not to use it, you can opt to remove the 'integrity' attribute, it's being provided as a convenience. link(href='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css', rel='stylesheet' crossorigin='anonymous') script(src='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js' crossorigin='anonymous')
- Animats 11y ago
  Subresource integrity keeps CDNs honest. If a CDN is "incompatible" with subresource integrity, they're doing a MITM attack on your users and your site.
securefail 11y ago
So Integrity checking it just that, checking that the code is actually what you have uploaded. Having worked closely with the great people have made the SRI specification(www.w3.org/TR/SRI/) I can guarantee any CDN supporting integrity checking want to ensure you get the correct content. If they didn't care about delivering the correct content they would be pushing back against the specification / using it. This is why I have pushed bootstrap to start using integrity checking to prevent this form of code injection. But yeah there isn't a requirement for you to use this with a CDN either (I get whilst the browser support isn't there on a bank site it wouldn't perhaps be ideal - this has always been the case unless you are in charge of the CDN content) what it does do it inform me that they won't be delivering variable content of any kind whatsoever as SRI would break that code if they tried to load malicious content. Justin who has also replied to this message works closely with developer outreach at MaxCDN and cares greatly about their product 'doing the right thing'™ Let me know if you have any further questions about SRI as I can probably answer then for you. Jonathan Kingston

buro9 11y ago

> There are also security issues: if you're referencing some JavaScript from a CDN, you're trusting the people running the CDN to actually serve the JavaScript you request. In the HTTP/2 world, it will likely be better to not do this. The old tricks of relying on it being in browser cache already doesn't forego the fact that the connection to the server is expensive and HTTP/2 gives you a nice open connection to your server already... I would bet that a site is faster by taking as many third-party or other domain assets and putting them back on the same domain and same server.

elithrar 11y ago
> I would bet that a site is faster by taking as many third-party or other domain assets and putting them back on the same domain and same server. There are other advantages to using a CDN beyond 'optimizing' browser cache usage: getting assets closer to your users reduces latency (and therefore increases throughput), which can be a noticeable benefit if you're hosting in San Francisco and serving Oceania/SE Asia. HTTP/2 won't change that: it will just mean distributing assets over multiple domains (to circumvent browser pipelining limits) will make less sense, but putting one asset domain behind a CDN will still be beneficial.
- buro9 11y ago
  Ah, I should clarify... if you already have your whole site on a CDN, and that CDN supports HTTP/2, then you are probably best not sending request to lots of other domains if you are able to serve the request from your own domain. The connection overhead of DNS + connection + TLS is still significant... and HTTP/2 means you'll already have a connection to your server, and the assets could already be being pushed to you, but at the least you'll be able to grab them from the same open connection.
Encosia 11y ago
Assuming you serve the CDN content with good caching headers, there's no connection required in the case of a cache hit.
- 11y ago

ultramancool 11y ago

crossorigin='anonymous' solves the privacy issue, SRI will solve the security issue. If you use JS blocking like NoScript, which doesn't appear to support per-site access restrictions, I'd suggest you switch to something like ublock origin's advanced mode, which allows you to allow individual sites to access specific CDNs.

cbr 11y ago

> you're trusting the people running the CDN to actually serve the JavaScript you request Subresource Integrity [1] lets you fix this, and is in FF 43 and Chrome 45. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/