I learned to love the Same-Origin Policy
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:
- Browsers reading and applying metadata within image resources to declare intended display size and resolution.
- Default browser respect for this metadata, overridable via CSS (
image-resolution
) or markup (srcset
'sx
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!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

It's out! Congrats to the Vue team for getting it done, I know it was a massive effort and a long time coming. All new docs, as well.

I had someone write in with this very legit question. Lea just blogged about how you can get valid CSS properties themselves from the browser. That's like this.

I'd say "website" fits better than "mobile app" but I like this framing from Max Lynch:

The other day, I spotted this particularly lovely bit from Corey Ginnivan’s website where a collection of cards stack on top of one another as you scroll.

If we need to show documentation to the user directly in the WordPress editor, what is the best way to do it?

There are a number of these desktop apps where the goal is showing your site at different dimensions all at the same time. So you can, for example, be writing

Questions about purple slash areas in Flex layouts When using Flex layouts, you may encounter some confusing phenomena, such as in the developer tools (d...

CSS Grid is a collection of properties designed to make layout easier than it’s ever been. Like anything, there's a bit of a learning curve, but Grid is
