Browsers as security guards: the same-origin rule

Right now you might have your email open in one tab, your bank in another, and some random website in a third. All three run code inside the same browser, on the same computer, often at the same time. So why can’t that random website just reach into the other tabs and read your inbox?

The answer is one of the most important rules on the web: the same-origin policy. Your browser enforces it on every page, all day, without you ever noticing.

What an “origin” is

An origin is three things put together:

1. The scheme: https or http
2. The host: for example cybersearch.in
3. The port: usually hidden, 443 for HTTPS

Two addresses have the same origin only if all three match:

Compared with https://cybersearch.in/blog/	Same origin?	Why
https://cybersearch.in/tools/	Yes	Only the path differs
http://cybersearch.in/blog/	No	Different scheme
https://news.cybersearch.in/	No	Different host, even though it’s a subdomain
https://cybersearch.in:8443/	No	Different port

The rule itself

The same-origin policy says, roughly: a page can freely use content from its own origin, but it cannot read data that belongs to another origin.

That doesn’t mean sites can’t touch each other at all. A page can still:

• show images from other sites,
• load scripts and stylesheets from a CDN,
• embed a video from another site,
• submit a form to another site.

What it can’t do is read the response. A random site can embed your bank’s logo, but its JavaScript can’t fetch your bank’s account page and read your balance, even though your browser would happily send your bank cookies along with the request.

Why it matters for security

Think back to Day 3. Your browser holds session cookies for every site you’re logged in to, and it attaches them automatically. Without the same-origin rule, any page you visited could quietly request your email, your bank statement or your company dashboard, with your cookies attached, and read the results.

The same-origin policy is the wall that makes it safe to have many sites open at once. Most of what we’ll cover later in the series is either about protecting that wall or about attacks that try to get around it:

• Cross-site scripting (XSS), Day 19, gets attacker code to run inside the trusted origin, where the wall no longer applies.
• Cross-site request forgery (CSRF) works because sending a request isn’t blocked, only reading the answer. That’s why SameSite cookies from Day 3 matter.
• Clickjacking hides a real site inside an invisible frame on a malicious page and tricks you into clicking it.

When sites open the door: CORS

Sometimes a site genuinely needs to share data across origins. A frontend at app.example.com might call an API at api.example.com. Those are different origins, so the browser blocks reading the response by default.

CORS (Cross-Origin Resource Sharing) is how a server says “it’s fine, this other origin may read my responses”. It does that with response headers such as:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true

CORS is useful and safe when configured narrowly. Problems come from configuring it too loosely, for example:

• Reflecting any origin. The server copies whatever Origin the request claims into Access-Control-Allow-Origin, and also allows credentials. That effectively tells the browser that every website may read logged-in responses.
• Trusting null. Some sandboxed pages and local files send Origin: null. Allowing it opens the door wider than intended.
• Loose pattern matching. Checking that an origin merely contains example.com also lets in example.com.evil-site.net.

The key point: CORS is not a protection you add. It’s a relaxation of the browser’s protection. Every line of it should be deliberate.

Frames and clickjacking

The same-origin policy stops a framing page from reading a framed site’s content, but it doesn’t stop the framing itself. That’s where clickjacking comes from: a page loads your site in a transparent frame and lines up a button so visitors click it without knowing.

The fix is a response header that tells browsers who may frame your pages:

Content-Security-Policy: frame-ancestors 'self'

The older X-Frame-Options: DENY or SAMEORIGIN does the same job and is still widely supported. Pages with any important action, like login, payment or account settings, should never be frameable by other sites.

See it in action

You can watch the rule work in your own browser:

1. Open any website and press F12, then go to the Console tab.
2. Type fetch('https://example.org').then(r => r.text()).then(console.log) and press Enter.
3. Unless that site has chosen to allow it, you’ll see a CORS error. That red message is the same-origin policy doing its job.

What you can do today

If you browse the web:

1. Keep your browser updated. The same-origin rule is only as strong as the browser enforcing it, and browser updates often fix bugs in exactly this area.
2. Be careful with extensions that ask to “read and change all your data on all websites”. Extensions can step around protections that ordinary pages can’t.
3. Log out of sensitive sites when you’re done, so fewer logged-in sessions are sitting in your browser.

If you run a website:

1. Find out whether your site or API sends any Access-Control-Allow-* headers, and check that the allowed origins are an exact list, not a reflection of the request.
2. Never combine a wildcard or reflected origin with Access-Control-Allow-Credentials: true.
3. Add frame-ancestors 'self' (or X-Frame-Options: SAMEORIGIN) so other sites can’t frame your pages.
4. Read MDN’s guide to the same-origin policy and the OWASP guidance on CORS for the details.

Coming up next

Tomorrow is Day 7, the end of our first week. We’ll pull everything together into a website security checklist, version 1: the handful of checks from this week that every site owner can do in an afternoon.