Understanding the Same-Origin Policy (SOP)

In our previous lesson, we dissected the anatomy of HTTP, learning how browsers and servers communicate through a structured language of requests and responses. You saw how this "conversation" reveals crucial information and can even be manipulated to control a server. Now, we turn to a fundamental security principle that keeps these conversations from descending into chaos.

This lesson explores the Same-Origin Policy (SOP), arguably the most important security concept in the modern web. We will define what an "origin" is and, through a fascinating look back at the early internet, understand why SOP was created. You'll see what a world without it looks like and why it's the bedrock upon which web application security is built. For a bug bounty hunter, understanding SOP isn't just academic; it's the key to understanding an entire class of vulnerabilities like Cross-Site Scripting (XSS).

What is an "Origin"?

Before we can understand the policy, we need to be crystal clear on what the browser considers an "origin." An origin is not just the domain name. It's a specific combination of three parts of a URL:

Protocol (e.g., http, https)
Host (e.g., www.example.com, api.example.com)
Port (e.g., :80, :443, :8080)

If any one of these three parts differs between two URLs, they are considered to be from different origins. The path part of the URL (e.g., /users/profile) does not affect the origin.

Let's look at some examples with the origin http://www.example.com:80:

URL	Same Origin?	Reason
`http://www.example.com/page.html`	Yes	Same protocol, host, and port (80)
`https://www.example.com`	No	Different protocol (`https` vs `http`)
`http://api.example.com`	No	Different host (`api` subdomain)
`http://www.example.com:8080`	No	Different port (`8080` vs `80`)
`http://different-site.com`	No	Different host

The following video provides a concise explanation of this concept.

Same Origin Policy explained | what is Same Origin policy?

Watch this short segment from the video "Same Origin Policy explained" to solidify your understanding of what constitutes an origin.

Focus on the definition of an origin. The presenter clearly breaks down how the protocol, host, and port must all match for two URLs to be considered from the same origin.

A World Without SOP: The Wild West of the Early Web

To truly appreciate why SOP is so critical, we need to travel back to a time before it existed. In the mid-1990s, the web was evolving at a breakneck pace. Technologies like cookies, frames, and—most importantly—JavaScript were introduced, making websites dynamic and interactive for the first time.

However, this new power came with unforeseen dangers. The following video from LiveOverflow uses an old Netscape browser to demonstrate what was possible before the Same-Origin Policy was invented. It's a powerful history lesson that reveals the genesis of modern web security.

The Same Origin Policy - Hacker History

Watch this segment from "The Same Origin Policy - Hacker History". It demonstrates a vulnerability in an early version of Netscape that made the creation of SOP essential.

First, the video sets the stage by describing the early web and the introduction of JavaScript and frames (JavaScript and frames). Then, pay very close attention to the attack demonstration. You will see an attacker's page loading a separate login page from a different domain into a frame. The attacker's JavaScript then reaches across origins, into the login page's frame, and steals the username, password, and session cookie in plain sight.

What you just witnessed is catastrophic. Imagine visiting a malicious website today, and it could invisibly load your online bank, your email, and your social media accounts in hidden frames, stealing every password you type and every session cookie that keeps you logged in. The web would be unusable.

This attack was possible because there was no rule preventing a script from one origin (attacker.com) from reading the contents and properties of a document from another origin (your-bank.com).

The Birth of a Policy

Browser developers at Netscape quickly realized the immense danger. A malicious script couldn't just steal data from other websites; it could also read files from the user's local computer if they were opened in a frame. This had to be stopped.

The Same Origin Policy - Hacker History

Now, watch the next part of the same video, which explains how Netscape fixed this critical flaw.

The segment shows how an updated version of the browser prevents the attack from working. The crucial part comes when the presenter examines the release notes for Netscape 3.0 (the release notes), which contains this landmark statement: "Navigator version 2.02 and later automatically prevents scripts on one server from accessing properties of documents on a different server."

This was it. With that single rule, the Same-Origin Policy was born. A script loaded from one origin could no longer freely access data from another. A security boundary was drawn between websites.

How SOP Works in the Modern Web

The core principle remains the same today. The Same-Origin Policy is a security mechanism enforced by your web browser that controls how documents and scripts from one origin can interact with resources from another origin.

The general rules are:

Cross-origin writes are generally allowed. A website can send requests to another origin. For example, a form on site-a.com can be configured to submit data to site-b.com. This is why embedding images (<img>), scripts (<script>), and stylesheets (<link>) from different origins works.
Cross-origin reads are generally blocked. This is the heart of SOP. A script on site-a.com cannot read the data returned from a request to site-b.com. If it could, it could read your private emails, bank balance, or any other sensitive data.
Cross-origin embedding is generally allowed. As seen with frames, one site can embed another. However, SOP prevents the parent page from accessing the content of the embedded page if it's from a different origin.

The video we looked at earlier provides a good summary of these interactions.

Same Origin Policy explained | what is Same Origin policy?

Let's revisit the "Same Origin Policy explained" video for a modern perspective on these rules.

First, watch the explanation of why SOP is needed in a modern context with multiple tabs and embedded iframes. Next, focus on the clarification that SOP is primarily about scripts and how a script's origin is determined by the document it runs in, not where it was loaded from. Finally, understand the distinction between what SOP allows and disallows, particularly the difference between sending requests and reading responses.

SOP and Its Security Implications for Hackers

As a bug bounty hunter, SOP is not just a defense mechanism you need to know about; it is the central pillar that many attacks are designed to subvert. When you find a web vulnerability, you are often finding a way to bypass the protections that SOP provides.

Cross-Site Scripting (XSS): This is the most direct attack on SOP. If you can inject malicious JavaScript into your-bank.com, that script executes within the origin of your-bank.com. Since it's now considered "same-origin," it has full permission to read cookies, access data on the page, and make requests on behalf of the user. You haven't broken SOP; you've tricked the browser into putting your malicious code on the trusted side of the security boundary.
Cross-Site Request Forgery (CSRF): This attack exploits a feature of SOP. SOP allows cross-origin writes (requests). An attacker on evil.com can create a hidden form that sends a request to your-bank.com/transfer?amount=1000. When you visit evil.com, your browser submits that form, and because it automatically includes your cookies for your-bank.com, the bank processes the transfer. The attacker can't read the response, but they don't need to—the damage is already done.

Understanding the Same-Origin Policy is the foundation for understanding these and many other client-side vulnerabilities.

Conclusion

In this lesson, we've established the what, why, and how of the Same-Origin Policy. It's a simple but profound security control enforced by the browser to maintain isolation between different websites.

Key Takeaways:

An origin is defined by the combination of protocol, host, and port.
SOP was created in response to early, devastating attacks that allowed scripts from one website to steal sensitive data from another.
The core rule of SOP is that a script from one origin cannot read data from a different origin.
SOP generally allows sending requests and embedding resources across origins, which has its own security implications (like CSRF).
Major vulnerabilities like XSS are effective precisely because they represent a bypass of the separation that SOP is meant to enforce.

Now that you understand the fundamental rule governing browser interactions, our next lesson will equip you with the essential tool for observing and manipulating these interactions. We will learn how to configure and use an intercepting proxy, Burp Suite, to get a hands-on view of the web traffic your browser sends and receives.