Hacker News Reader

Comment by ship_it | Hacker News Reader

From an Infosec perspective, this is normal. CORS should be put on place per local network visibility or host to disallow such feature.

View on HN

I thought CORS is blocked by default in modern browsers?

It 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

What are the arguments against?

If 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.

CORS is only applied to javascript, not GET requests via img, link or other tags that load resources.

Reply on news.ycombinator.com