The browser security principal
An origin is primarily the tuple of scheme, host, and port. The same-origin policy uses this principal to limit how a document or script from one origin reads and manipulates resources from another. The policy separates many DOM objects, storage areas, script-visible responses, and communication channels.
Path is not part of the origin. Two applications under different paths on the same scheme, host, and port usually share origin authority. A script compromised in one can often act against the other.
Reads, writes, and embedding
The policy does not block every cross-origin action. Browsers can send many cross-origin requests, follow links, submit forms, and embed selected resources. They usually prevent the initiating page from reading a protected cross-origin response unless the target grants access through CORS or another defined mechanism.
This distinction explains why CSRF is possible: an attacker can cause a credentialed request without reading its response. It also explains why CORS is a read-sharing policy, not a request firewall.
Origin design
Place applications with different trust, script, and administrator boundaries on different origins. Do not assume that separate paths isolate them. Limit third-party script because it executes with the embedding page's origin authority. Use explicit postMessage target origins and validate the sender origin and message schema.
Cookies have domain, path, security, and same-site rules that do not exactly match script origin. A parent-domain cookie can affect several origins. Browser storage is generally origin-scoped. Service workers, frames, opener relationships, redirects, and opaque origins add specific rules that design and tests must cover.
Failure and residual risk
Same origin does not mean equally trusted code. One XSS defect can affect other applications on that origin. DNS or hosting takeover can grant an attacker a trusted host. A permissive cross-origin policy can reopen reads. Browser extensions and local compromise operate outside ordinary page assumptions.
Pomerium boundary
Pomerium can expose protected applications on selected hosts and manage the route session. Operators choose host names, cookie settings, and application placement. Pomerium does not create isolation between two upstream applications served under one browser origin. Each application must implement its browser, script, storage, and message boundaries.
Evaluation checklist
- What are the exact scheme, host, and port for each application and administrative surface?
- Which applications and third-party scripts share one origin authority?
- Which cross-origin requests can be sent, and which responses can be read?
- Are cookies, storage, frames, service workers, and messages scoped as intended?
- Does every
postMessagesender and receiver validate the exact origin and message schema? - Could DNS, host takeover, or one XSS defect compromise another application on the same origin?
