4 ms·

I understand that it isn't possible to check if the external assets are hosted on a CDN bucket which is under the control of the website (but under a different

I understand that it isn't possible to check if the external assets are hosted on a CDN bucket which is under the control of the website (but under a different domain name), but without the ability to discriminate such cases it makes your statistics on externally hosted content pretty meaningless.

jacquesm 11y ago
I don't agree with that. From the point of view of the user that content might as well have come from a third party since - just like the headless browser used in the testing - they have absolutely no way to verify that short of doing a bunch of whois lookups. And if there is one thing that a user should be able to verify then it is that the entity sending them the main page is the same entity as the one that sends them the rest of the stuff on that page and to refuse all or part of the transaction if that isn't the case. After all: there is only one slot in the URL bar, which strongly suggests to the user that that is the entity they are transacting with. What technical tricks are pulled behind the scenes have no bearing on that.
- johncolanduoni 11y ago
  > From the point of view of the user that content might as well have come from a third party since - just like the headless browser used in the testing - they have absolutely no way to verify that short of doing a bunch of whois lookups. How many users, even among the extremely security conscious, do you expect to actually verify such things? And among these, how many do you expect will turn their noses up at a CDN url that is serving a number of obviously website-specific assets in addition to jQuery and friends? The real issue (and the one you focus on in your article) is the actual dangers you expose yourself to by using uncontrolled external asset sources. If I set up a CloudFront bucket that mirrors the static asset directory on my web server (and use it via HTTPS), what is the vulnerability? CloudFront could be hacked, but so could my web server (and the later is a more likely culprit since it is executing more dynamic code). The difference makes even less sense if my website is also hosted by Amazon. If I want to keep my static assets on a CDN (and save myself a lot of server load) while keeping my assets URLs on the same domain, the only two things I can think of are: 1. Using a CNAME record, which precludes using HTTPS (introducing a real, not perceived, security vulnerability). 2. Use a local url that gives a 301 redirect to my CDN url. Which means extra requests to my website, for no real security benefit.
- deleted 11y ago
  [deleted]

jacquesm 11y ago

I don't agree with that. From the point of view of the user that content might as well have come from a third party since - just like the headless browser used in the testing - they have absolutely no way to verify that short of doing a bunch of whois lookups. And if there is one thing that a user should be able to verify then it is that the entity sending them the main page is the same entity as the one that sends them the rest of the stuff on that page and to refuse all or part of the transaction if that isn't the case. After all: there is only one slot in the URL bar, which strongly suggests to the user that that is the entity they are transacting with. What technical tricks are pulled behind the scenes have no bearing on that.

johncolanduoni 11y ago
> From the point of view of the user that content might as well have come from a third party since - just like the headless browser used in the testing - they have absolutely no way to verify that short of doing a bunch of whois lookups. How many users, even among the extremely security conscious, do you expect to actually verify such things? And among these, how many do you expect will turn their noses up at a CDN url that is serving a number of obviously website-specific assets in addition to jQuery and friends? The real issue (and the one you focus on in your article) is the actual dangers you expose yourself to by using uncontrolled external asset sources. If I set up a CloudFront bucket that mirrors the static asset directory on my web server (and use it via HTTPS), what is the vulnerability? CloudFront could be hacked, but so could my web server (and the later is a more likely culprit since it is executing more dynamic code). The difference makes even less sense if my website is also hosted by Amazon. If I want to keep my static assets on a CDN (and save myself a lot of server load) while keeping my assets URLs on the same domain, the only two things I can think of are: 1. Using a CNAME record, which precludes using HTTPS (introducing a real, not perceived, security vulnerability). 2. Use a local url that gives a 301 redirect to my CDN url. Which means extra requests to my website, for no real security benefit.
deleted 11y ago
[deleted]