This year, I collaborated with Noam Rosenthal on standardizing a new web platform feature: dynamically adjusting image size and resolution. Success! However, the journey was a steep learning curve.

While I anticipated challenges like browser feedback and unforeseen technical hurdles, I underestimated the impact on web security and privacy principles. My prior understanding of these principles was insufficient.

Our goal was to modify the default display size of images. An 800x600 image, by default, renders at 800x600 CSS pixels. This is its intrinsic size (or natural size), with a default density of 1x.

The challenge arose when serving high-, low-, or variable-density images without CSS or HTML. This is a common need for image hosts like my employer, Cloudinary.

Our solution involved:

1. Browsers reading and applying metadata within image resources to declare intended display size and resolution.
2. Default browser respect for this metadata, overridable via CSS (image-resolution) or markup (srcset's x descriptors).

This seemed sound – flexible and building on existing patterns. However, HTML spec editor Anne van Kesteren rejected it, citing a violation of the Same-Origin Policy (SOP). Image orientation also needed re-evaluation. The ability to toggle EXIF metadata effects via CSS/HTML violated SOP.

My initial understanding of SOP was limited to CORS errors. Now, it was hindering a major project. I had to learn!

My key takeaways:

• SOP is not a single rule, nor is it solely about CORS errors.
• It's an evolving philosophy, inconsistently implemented.
• The core principle is that web security and privacy boundaries are defined by origins. Shared origin implies unrestricted interaction; otherwise, restrictions apply.
• Many cross-origin interactions are allowed. Websites can generally write across origins (POST requests) and embed cross-origin resources (iframes, images). However, reading cross-origin resources in JavaScript requires explicit permission (CORS).
• Crucially, preventing cross-origin reads protects user privacy. Each user sees a personalized web, influenced by cookies and local context. Allowing websites to read data from other sites through a user's browser would be a major security flaw.

SOP primarily concerns preventing cross-origin reads. Other cross-origin actions are often permitted by default.

The image size/resolution issue:

Imagine https://coolbank.com/hero.jpg, returning different content based on user login status. The logged-in version might include EXIF resolution information, while the logged-out version doesn't. A malicious actor could embed this image, check its intrinsic size (with and without EXIF), inferring login status, and potentially launching phishing attacks.

While not accessing pixel data (due to CORS), the actor gains information across origins – a violation.

Our solution: In cross-origin contexts, EXIF modifications are always applied, making the information unreadable. An image with EXIF-specified size will always render according to that size, regardless of CSS overrides.

Understanding SOP clarified other web security concepts:

• Cross-site request forgery (CSRF) exploits the default allowance of cross-origin writes.
• Content Security Policy (CSP) controls allowed embeds, addressing cross-site scripting (XSS) vulnerabilities.
• COOP, COEP, CORP, and CORB aim to eliminate cross-origin interactions, addressing inconsistencies in SOP implementation and mitigating vulnerabilities like Spectre.

In short:

• Web security and privacy are robust, based on origin-based interaction restrictions.
• Cross-origin reads are forbidden by default to protect user privacy.
• Any SOP loophole, however small, is a security risk.

My 2020 experience highlighted the critical importance of SOP and the need for stringent web security practices. A safer and more secure future requires unwavering defense of these principles.

The above is the detailed content of I learned to love the Same-Origin Policy. For more information, please follow other related articles on the PHP Chinese website!