4 ms·
From an Infosec perspective, this is normal. CORS should be put on place per local network visibility or host to disallow such feature.
by ship_it 6y ago
From an Infosec perspective, this is normal. CORS should be put on place per local network visibility or host to disallow such feature.
- revanx_ 6y agoI thought CORS is blocked by default in modern browsers?
- 19870213 6y agoCORS is only applied to javascript, not GET requests via img, link or other tags that load resources.
- wongarsu 6y agoIt is, but it's a bit leaky simply because it's such a late addition. Img tags aren't subject to CORS (you can display images from anywhere). Access to the loaded image data is CORS controlled, but the onload and onerror handlers or the dimensions of the final img tag aren't restricted. If you know for example the path of the netgear logo on a router, you can try loading it and determine success/failure. Existing CORS isn't strict enough to prevent this, and it's debatable whether it should be
- intricatedetail 6y agoWhat are the arguments against?
- wongarsu 6y agoIf we could go back 30 years we might decide that img tags can only show images from the same domain. That would also have solved the whole hotlinking mess of the 2000s. We might also decide that img tags need explicit width/height declarations. That would also have prevented lots of reflow issues. But we didn't do either of those. Changing that now would be too disruptive, the web is built on the assumption of basically eternal backwards compatibility. And with the amount of insight JavaScript has into the DOM of its own page it's basically impossible to hide the dimensions of a rendered element such as an image. So once you have an img tag without explicit size declaration, onload is basically a performance optimization that could be replaced by polling the position of surrounding elements.