Category: Attack Techniques

Same-Origin Policy

Also known as: SOP, same origin policy, single-origin policy

Simply put

The Same-Origin Policy is a security rule built into web browsers that prevents a website from freely reading or manipulating data belonging to a different website. An "origin" is defined by the combination of the protocol (such as HTTPS), the hostname, and the port number, and the policy blocks scripts on one origin from accessing resources loaded from another origin. This helps protect users from malicious websites that might try to steal sensitive information from other sites the user is logged into.

Formal definition

The Same-Origin Policy (SOP) is a fundamental browser-enforced security mechanism that restricts how documents or scripts loaded from one origin can interact with resources from a different origin, where an origin is defined by the tuple of scheme, host, and port. SOP primarily governs DOM access (preventing cross-origin scripts from reading or manipulating another page's Document Object Model), restricts cross-origin network reads for responses obtained via APIs such as XMLHttpRequest and Fetch, and limits certain forms of cross-origin embedding and data extraction. It is important to note that cookie access is governed by its own model based on domain and path attributes rather than the full scheme/host/port origin tuple, so SOP's protections and cookie scoping rules, while related, are not identical. SOP can be selectively relaxed through mechanisms such as Cross-Origin Resource Sharing (CORS), the document.domain property (now deprecated in some browsers), and postMessage. SOP does not typically block cross-origin resource embedding (e.g., images, scripts, stylesheets loaded via HTML tags), which means it does not prevent all classes of cross-origin data leakage without complementary defenses.

Why it matters

The Same-Origin Policy is one of the most foundational security boundaries in the web platform. Without it, any website a user visits could freely read data from other sites the user is simultaneously logged into, such as banking portals, email accounts, or corporate applications. SOP prevents a malicious page from using JavaScript to silently extract sensitive information from another origin's DOM or from reading the responses to cross-origin network requests. This baseline isolation is what makes it possible for users to have multiple tabs open to different sites without those sites being able to interfere with or spy on each other.

However, SOP alone does not constitute a complete defense against all cross-origin attacks. It does not typically block cross-origin resource embedding (for example, images, scripts, and stylesheets loaded via HTML tags), which means that certain classes of data leakage or injection attacks remain possible without complementary controls. Additionally, cookie access follows its own scoping model based on domain and path attributes rather than the full scheme, host, and port tuple that defines an origin under SOP. This distinction means that assumptions about SOP protections do not directly translate to cookie isolation, and developers must apply additional measures such as cookie flags (Secure, HttpOnly, SameSite) and proper CORS configuration to achieve robust cross-origin security.

Misconfigurations in mechanisms that relax SOP, particularly overly permissive CORS policies, are a recurring source of real-world vulnerabilities. When applications reflect arbitrary origins in Access-Control-Allow-Origin headers or set Access-Control-Allow-Credentials without strict origin validation, attackers can leverage trusted user sessions to exfiltrate sensitive data cross-origin. Understanding how SOP works, where its boundaries lie, and how its relaxation mechanisms can be abused is essential for building secure web applications.

Who it's relevant to

Web Application Developers

Developers must understand SOP to correctly configure cross-origin interactions. Misconfigured CORS policies, improper use of postMessage without origin validation, or reliance on deprecated relaxation mechanisms like document.domain can introduce vulnerabilities that undermine the browser's built-in isolation.

Application Security Engineers

Security engineers need to assess whether applications correctly rely on SOP and whether any relaxation mechanisms are implemented safely. This includes reviewing CORS configurations for overly permissive origin allowlisting, verifying that cookie scoping (which follows its own domain/path model rather than the SOP origin tuple) is properly handled, and ensuring complementary headers are in place for resources that SOP does not block by default.

Frontend Architects

Architects designing systems with multiple subdomains, micro-frontends, or third-party integrations must plan around SOP constraints. Decisions about how origins are structured, how cross-origin data sharing is facilitated, and which relaxation mechanisms are employed have direct implications for the security posture of the overall application.

Penetration Testers

Testers routinely probe for SOP bypass conditions, including misconfigured CORS policies that reflect arbitrary origins, missing or incorrect SameSite cookie attributes, and client-side code that accepts postMessage events without validating the sender's origin. Understanding the boundaries of SOP, including what it does not protect against, guides effective test coverage.

Inside SOP

Origin Definition

An origin is defined by the tuple of scheme (protocol), host (domain), and port. Two URLs share the same origin only when all three components match exactly.

DOM Access Restriction

Scripts running in one origin are typically prevented from reading or manipulating the DOM of documents loaded from a different origin, limiting cross-origin interaction at the document level.

Cross-Origin Network Request Constraints

While browsers generally allow cross-origin requests to be sent (such as form submissions or resource loads), the Same-Origin Policy restricts the ability of the requesting origin to read responses from a different origin unless explicitly permitted.

Cross-Origin Read Restrictions

The policy prevents scripts from reading data returned by cross-origin HTTP responses by default. This is a core SOP behavior enforced by the browser, distinct from implementation-specific mechanisms like Chrome's Cross-Origin Read Blocking (CORB), which provides additional server-side-informed enforcement.

Cookie Scoping (Related but Distinct)

Cookie access is governed primarily by domain and path attributes rather than the full scheme/host/port origin tuple. While SOP and cookie scoping both serve as browser security boundaries, cookies follow their own matching rules and should not be conflated with strict same-origin checks.

CORS as a Controlled Relaxation Mechanism

Cross-Origin Resource Sharing (CORS) provides a standards-based way for servers to explicitly opt in to allowing cross-origin access, using HTTP response headers to declare which foreign origins may read responses.

Common questions

Answers to the questions practitioners most commonly ask about SOP.

Does the Same-Origin Policy govern cookie access using the same scheme, host, and port matching it applies to DOM and network requests?

No. This is a common misconception. Cookie access is governed by domain and path attributes (and the Secure flag for scheme), not the full scheme/host/port tuple that SOP uses for DOM access and XMLHttpRequest/Fetch restrictions. Cookies follow their own rules defined by cookie attributes, which in practice may be less restrictive than SOP's origin matching. Treating cookie scoping as identical to SOP origin matching can lead to security misconfigurations.

Does the Same-Origin Policy's restriction on reading cross-origin responses refer to the same mechanism as Chrome's Cross-Origin Read Blocking (CORB)?

No. The Same-Origin Policy's general restriction on reading cross-origin responses is a browser-enforced policy that applies across all major browsers. Chrome's Cross-Origin Read Blocking (CORB) is a separate, Chrome-specific implementation mechanism that strips certain cross-origin response bodies before they reach the rendering process, primarily as a defense against Spectre-class side-channel attacks. While related in intent, CORB is an additional, implementation-specific protection layered on top of SOP, not a synonym for generic SOP read restrictions.

How should developers configure CORS headers when they need to allow cross-origin access from specific trusted origins?

Developers should set the Access-Control-Allow-Origin header to the specific trusted origin rather than using the wildcard value '*', particularly when credentialed requests are involved (since browsers reject wildcard origins with credentials). The allowed methods and headers should be explicitly listed in Access-Control-Allow-Methods and Access-Control-Allow-Headers. Preflight response caching via Access-Control-Max-Age should be tuned to balance security with performance. Developers should typically validate the requesting origin against an allowlist server-side before reflecting it in the response header.

What practical steps can teams take to audit whether their application's cross-origin policies are correctly enforced?

Teams should inventory all endpoints that return CORS headers and verify that Access-Control-Allow-Origin is not set to a reflected, unvalidated origin or an overly broad wildcard. Automated scanners can check for permissive CORS misconfigurations, though they may produce false negatives for context-dependent issues such as origin validation logic that is only exploitable with specific request sequences. Manual review of server-side origin validation logic is typically necessary to catch subtle bypasses, such as regex flaws in origin allowlists.

How does the Same-Origin Policy interact with postMessage, and what security precautions should developers take?

The postMessage API is designed to allow controlled cross-origin communication between windows or frames, intentionally bypassing SOP for message passing. Developers should always validate the origin property of incoming messages against an expected value before processing the data. Failing to check message origin is a common implementation mistake that may allow an attacker-controlled page to send malicious messages. Additionally, when calling postMessage, developers should specify the target origin rather than using '*' to prevent unintended recipients from receiving sensitive data.

When embedding third-party content via iframes, what SOP-related controls should be applied to limit risk?

Developers should use the sandbox attribute on iframes to restrict the capabilities of embedded content, such as disabling scripts, form submission, or same-origin treatment. The Content-Security-Policy frame-ancestors directive (or the older X-Frame-Options header) should be set on the parent application to control which origins may embed it. SOP prevents the parent page from reading the DOM of a cross-origin iframe and vice versa, but developers should be aware that certain interactions, such as navigation of the iframe's top-level window, may still be possible unless explicitly restricted.

Common misconceptions

SOP prevents all cross-origin requests from being sent by the browser.

SOP does not typically block cross-origin requests from being sent. Instead, it restricts the requesting origin's ability to read the response. Cross-origin requests such as form submissions, image loads, and script includes are generally allowed to be dispatched; the restriction applies to programmatic access to the returned data.

Cookies are governed by the same scheme/host/port origin tuple that defines SOP for scripts and DOM access.

Cookie access follows its own rules based on domain and path attributes (and, optionally, the Secure flag for scheme restriction). This model is broader and less strict than the full origin tuple used by SOP for script and DOM isolation. Practitioners should not assume that SOP's origin matching applies uniformly to cookies.

SOP alone is sufficient to prevent all cross-origin attacks in web applications.

SOP provides a foundational boundary but does not address all cross-origin threats. Attacks such as Cross-Site Request Forgery (CSRF) can exploit the fact that cross-origin requests are still sent with ambient credentials. Additional defenses, including CSRF tokens, SameSite cookie attributes, and proper CORS configuration, are typically required.

Best practices

Configure CORS response headers with the narrowest set of allowed origins necessary, avoiding wildcard ('*') configurations when credentials or sensitive data are involved.

Use the SameSite cookie attribute (Lax or Strict) in combination with the Secure flag to limit cookie transmission across origins, recognizing that cookie scoping rules differ from SOP's origin model.

Implement CSRF protections (such as anti-CSRF tokens or verifying the Origin and Referer headers) to defend against attacks that exploit SOP's allowance of cross-origin request dispatch.

Audit and test cross-origin configurations in deployed environments, since SOP enforcement is a browser-side control and may not protect server-to-server or non-browser clients.

Leverage response headers such as X-Frame-Options or Content-Security-Policy's frame-ancestors directive to control whether your content can be embedded cross-origin in iframes, supplementing SOP's default protections.

When relying on browser-specific mechanisms like Cross-Origin Read Blocking (CORB), understand that these are implementation-specific optimizations and not universally applied across all browsers. Always enforce server-side access controls as the primary boundary.