Home / Knowledge hub / Same-origin policy
Knowledge hub
Same-origin policy
The browser rule that stops one site's scripts reading another site's data.
What it means
The same-origin policy is a browser rule: a script from one origin cannot read data from another origin. An origin is the scheme, host and port together, so https://app.example.com and https://api.example.com are different origins, as are http and https versions of one host.
The detail people miss is what it limits. A page can usually still send a request to another origin. What it cannot do is read the response. That is why the rule protects your signed-in session data from a hostile page open in the next tab.
Why it matters
Everything your users do in a browser assumes this rule holds. Their webmail, bank and your app sit in separate tabs, and the policy is why a script on a random site cannot read your customers' invoices. When it is weakened, the damage reaches data in someone else's session.
Most weakening is done by your own team. A permissive CORS setting, a wildcard postMessage target, or a shared parent domain for cookies can all hand access to an origin you did not intend. The rule does not stop the request itself, so it does not replace CSRF defences.
How it shows up
You meet it when a front end on one host calls an API on another and the browser blocks the reply, which sends developers to CORS settings. Fixes that follow are often too wide: reflecting any origin back, or allowing credentials with a wildcard.
Check which origins your API trusts, whether a trusted origin includes sub-domains you do not control, and whether any page uses document.domain or postMessage with a loose target. Also remember that cookies follow their own rules: they are scoped by host and path, not by full origin, so sibling sub-domains can share them.
Questions people ask
Same-origin policy, answered
What counts as the same origin?
Same scheme, same host and same port. https://example.com and https://example.com:8443 are different origins, and so are https://example.com and https://www.example.com.
Is CORS the same as the same-origin policy?
No. The policy is the default restriction. CORS is a way for a server to relax it for chosen origins, by sending headers the browser reads. A bad CORS setting weakens the policy.
Does it stop other sites sending requests to my app?
No. A page can still send requests, and cookies may go with them depending on cookie settings. The rule blocks reading the response. Defend against forged requests with tokens and SameSite cookies.
Does the same-origin policy protect my API from attackers?
No. It runs in browsers only. A script, a command-line tool or another server is not bound by it, so your API still needs its own authentication and authorisation.
How do we test our CORS and origin settings?
Send requests with different Origin headers and see which ones are echoed back with credentials allowed. Test lookalike and sub-domain origins as well as plain ones.
Sources
Where this comes from
Related
Terms that sit next to this one
CORS
The browser rule for which sites may read responses from your API.
CSRF
An attacker's page makes a logged-in user's browser act on your site.
Clickjacking
Tricking someone into clicking your button while it is hidden from them.
XSS
An attacker's script running in your pages, in your customers' sessions.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Which origins does your app trust?
We test the origin and cross-site settings your app really enforces, and each finding comes with the exact request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.