Same Origin Policy (SOP) is a fundamental security feature implemented in web browsers that restricts how documents or scripts loaded from one origin can interact with resources from another origin. In simpler terms, it’s like a bouncer at a club who checks IDs to make sure only authorized people can access certain areas.

What is an “Origin”?

An origin consists of three parts:

1. The protocol (http, https)
2. The domain (example.com)
3. The port number (80, 443)

For example, https://example.com:443 is a complete origin. Two URLs have the same origin only when all three components match exactly.

Let’s see a few examples of same origins for https://example.com:

How SOP Works?

Imagine your browser as a series of secure isolated containers. When you visit bank.com, everything from that site goes into the “bank.com container.” Similarly, content from social-media.com goes into its own separate container.

The Same Origin Policy ensures that code running in the “social-media.com container” cannot access or modify data in the “bank.com container” without explicit permission.

Each site gets its own independent container that cannot be accessed by other sites.

As a high level example, cookies/ session data or any other information pertaining to bank.com should not be accessible to any other websites.

---

When SOP Helps: Real-World Examples

Scenario 1: Protecting Your Banking Information

Without SOP:

1. You log into your bank at secure-bank.com and stay logged in
2. Later, you visit evil.com
3. Code on evil.com could potentially:
   • Read your bank account details
   • Make transactions on your behalf
   • Steal your session cookies

With SOP: The browser blocks evil.com from accessing any resources or making any requests to secure-bank.com, protecting your banking information.

Scenario 2: Preventing Session Hijacking

Let’s say you’re logged into your email account. SOP prevents scripts from other websites from reading your email session cookie and impersonating you.

Think of it this way: without SOP evil.com would be able to read cookies from gmail.com and send mails on your behalf without you knowing.

Scenario 3: Stopping Cross-Site Request Forgery (CSRF)

SOP helps prevent attackers from making you unknowingly submit forms to other websites where you’re already authenticated.

---

How SOP Is Implemented

SOP restricts several types of interactions:

• DOM access: A script from one origin cannot read or modify the DOM of a document from another origin.

  Example: You are unknowningly using an external CDN based script for viewing PDF injected with malicious code.

• Cookies and localStorage: Scripts can only access cookies and storage set by their own origin.

  Example: Cookies often store session ids and authentication tokens, evil.com can read these if SOP is not in place.

• XMLHttpRequest and Fetch API calls: By default, these requests are restricted to the same origin.

  Example: Browsers automatically sends cookies for any network requests, this may also include auth tokens. evil.com can send a direct network request to websites like below and empty your bank account.

  fetch('https://secure-bank.com/send-money/', {
      method: 'POST',
      body: {
         beneficiary: 'Evil Hacker',
         account-num: 12345678,
         amount: 10000
      }
   });

---

When SOP Doesn’t Help

Cross-Site Scripting (XSS)

If an attacker manages to inject malicious code directly into your website (for example, through a form), that code runs in the context of your origin. SOP can’t protect against this because the malicious code appears to be from the same origin.

Misconfigured CORS

If a website implements Cross-Origin Resource Sharing (CORS) with overly permissive settings, it can bypass SOP protections. For example, using Access-Control-Allow-Origin: * allows any website to access your resources. Access-Control-Allow-Credentials: true is even more dangerous if not implemented properly as it tells browser that it is allowed to send and receive credentials (like cookies, HTTP auth, or TLS client certificates) with cross-origin requests to this server.

DNS Rebinding Attacks

Sophisticated attacks can trick the browser into thinking a remote resource has the same origin when it doesn’t.

Intentionally Bypassing SOP (When Needed)

Sometimes legitimate cross-origin interactions are necessary. Modern web standards provide several mechanisms to safely bypass SOP:

1. CORS (Cross-Origin Resource Sharing): Allows servers to specify who can access their resources
2. postMessage API: Enables secure communication between windows/frames from different origins
3. JSONP: An older technique that leverages the fact that script tags aren’t restricted by SOP

---

Conclusion

The Same Origin Policy serves as a critical first line of defense in the browser security model. It isolates potentially untrusted content from different origins, significantly reducing the attack surface for many common web vulnerabilities.

While not foolproof, SOP forms the foundation upon which other security mechanisms are built, helping to keep your sensitive information safe as you browse the web. Understanding SOP is essential for both web developers building secure applications and security professionals evaluating web application defenses.