Cybersecurity glossary
What is the Same-Origin Policy (SOP)?
Learn what the Same-Origin Policy is, how browsers define an origin, what cross-origin reads it blocks, and how CORS COOP and CSP relate to this foundational web security model.
Definition
The Same-Origin Policy (SOP) is a fundamental browser security rule that restricts how documents or scripts from one origin can interact with resources from another origin, preventing arbitrary cross-site reads of sensitive data.
Why the Same-Origin Policy matters
Browsers routinely hold authenticated sessions for banks, email, and corporate apps at once. Without isolation, any website you visit could read another site’s data with your cookies. The Same-Origin Policy (SOP) is the browser’s foundational rule that prevents that free-for-all.
Almost every web security control—CORS, cookies, CSP, XSS impact—is easier to reason about once you understand origins.
What is an origin?
An origin is typically the tuple of scheme, host, and port.
| URL | Same origin as https://example.com ? |
|---|---|
| https://example.com/ | Yes |
| https://example.com:443/path | Yes (default HTTPS port) |
| http://example.com/ | No (different scheme) |
| https://www.example.com/ | No (different host) |
| https://example.com:8443/ | No (different port) |
What SOP allows and blocks
Blocks cross-origin reads
Scripts generally cannot read another origin’s DOM or response bodies.
Allows many embeds
Images, scripts, and frames can often load cross-origin, with restrictions on reading results.
Allows some writes/requests
Forms and navigations can trigger cross-origin requests—hence CSRF concerns.
Relaxes via explicit opt-in
CORS, postMessage, and related APIs enable controlled cross-origin cooperation.
How SOP shapes attacks and defenses
Browser isolates origins
Each site’s scripts run with privileges only inside their origin boundary.
Attackers seek same-origin code
XSS is powerful because it executes as the victim origin under SOP.
Cross-site requests still happen
CSRF abuses the fact that requests can be sent even when responses cannot be read.
Servers opt into reads via CORS
APIs that need cross-origin frontends must configure CORS carefully.
Extra policies harden isolation
COOP, COEP, CSP, and cookie SameSite add complementary boundaries.
Developers design with origins in mind
Auth cookies, APIs, and admin hosts are separated intentionally.
Practical checklist
- Treat scheme/host/port changes as security boundary changes.
- Do not use document.domain relaxation patterns in new code.
- Configure CORS explicitly; never reflect arbitrary Origin with credentials.
- Remember SOP does not stop CSRF by itself—use tokens/SameSite appropriately.
- Prioritize XSS prevention because XSS inherits the origin’s power under SOP.
- Separate high-value apps onto distinct origins when blast radius matters.
- Use postMessage with strict origin checks for cross-window communication.
- Test mobile webviews for origin quirks that differ from desktop browsers.
The practical takeaway
The Same-Origin Policy isolates web origins so one site cannot freely read another’s data in the browser. It is the bedrock of web security—and the reason XSS inside an origin is so dangerous.
Design APIs, cookies, and frontends around origin boundaries, relax them only with explicit mechanisms like CORS, and never confuse “can send a request” with “can read the response.”
Related security terms
Cross-Origin Resource Sharing (CORS)
The controlled way servers opt into relaxing cross-origin read restrictions.
Cross-Site Scripting (XSS)
Attacks that run inside the victim origin and therefore inherit its privileges under SOP.
Cross-Site Request Forgery (CSRF)
A threat that exists partly because browsers still send cross-site requests with cookies.
Cross-Origin Opener Policy (COOP)
An additional isolation control for browsing context relationships.
Frequently asked questions
What is the Same-Origin Policy in simple terms?
SOP stops a website from reading another website’s data inside your browser. A page on a.example generally cannot read your mail on mail.example even though both are open on your machine.
What makes two URLs the same origin?
They share the same scheme (https), host (example.com), and port. https://example.com and https://a.example.com are different origins.
Does SOP block all cross-origin requests?
No. Browsers can often send cross-origin requests (images, forms, some fetches). SOP primarily restricts reading the responses unless CORS or other mechanisms allow it.
How does CORS relate to SOP?
CORS is an opt-in system for servers to relax SOP’s cross-origin response-read restrictions for legitimate web apps.
Why does XSS bypass SOP’s protection?
XSS runs script as the trusted origin itself. SOP still applies, but the attacker is already inside the victim origin’s privilege boundary.
Are subdomains the same origin?
No. Different hosts are different origins, even if they share a registrable domain—unless special document.domain practices apply (discouraged/restricted).
What about file:// or null origins?
Local files and some sandboxed contexts have special origin behaviors that can surprise developers; treat them carefully in security reviews.
References
Explore authoritative guidance and frameworks related to same-origin policy (sop).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.