Glossary Term
Same-Site vs Same-Origin
Site and origin are not the same. Learn how eTLD+1 and the Public Suffix List define same-site, and why it decides SameSite cookie and CORS behavior.
TL;DR: A site is the registrable domain (eTLD+1), so
app.example.comandapi.example.comare the same site but different origins. CORS cares about origin;SameSitecookies care about site.
Two URLs are same-site when they share a registrable domain, also called eTLD+1: the effective top-level domain plus one more label. The effective TLD comes from the Public Suffix List, a maintained list of suffixes under which anyone can register names. Same-site is a looser test than same-origin, and mixing the two up causes most SameSite and CORS confusion.
Worked examples
| A | B | Same-site? | Same-origin? |
|---|---|---|---|
https://app.example.com | https://api.example.com | Yes | No |
https://example.com | https://example.com:8443 | Yes | No |
https://example.com | http://example.com | Depends (see below) | No |
https://shop.example.co.uk | https://blog.example.co.uk | Yes | No |
https://alice.github.io | https://bob.github.io | No | No |
co.uk and github.io are both on the Public Suffix List, so example.co.uk and alice.github.io are the registrable domains, not co.uk or github.io. You cannot find this by counting dots; you need the list.
Where each one applies
GET /account HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Sec-Fetch-Site: same-site
Cookie: session=abc123
- Origin decides CORS. This request is cross-origin, so the response needs
Access-Control-Allow-Origin. - Site decides cookies. It is same-site, so a
SameSite=Strictcookie is still attached. Sec-Fetch-Siteis the request header that tells the server which relationship the browser computed:same-origin,same-site,cross-siteornone.
Non-obvious facts
- The HTML Standard defines both “same site” (scheme must match) and “schemelessly same site”. Which one a feature uses varies, so
http://tohttps://on the same domain is cross-site for some checks and same-site for others. Test in the browsers you support. - Sibling subdomains are mutually trusted for SameSite purposes. An XSS hole on
blog.example.comcan send authenticated requests toapp.example.comthat SameSite will not block. - Hosting platforms that give each customer a subdomain only stay safe because they are on the Public Suffix List.
Go deeper
Frequently asked questions
What is the difference between same-site and same-origin?
Same-origin requires identical scheme, host and port. Same-site only requires the same registrable domain (eTLD+1), so subdomains and different ports are same-site but cross-origin.
What is eTLD+1?
It is the effective top-level domain plus one label, such as example.com or example.co.uk. The effective TLD is determined by the Public Suffix List, not by counting dots.
Are alice.github.io and bob.github.io same-site?
No. github.io is on the Public Suffix List, so each subdomain is its own site. That is what stops one user page from sharing cookies with another.
Does CORS use same-site or same-origin?
CORS and the same-origin policy use origin. SameSite cookies and the Sec-Fetch-Site header use site.
Sources
Related
Origin (Scheme, Host, Port)
An origin is the scheme, host and port of a URL. See how browsers compare origins for the same-origin policy, CORS and the Origin header, with examples.
SameSite Cookie Attribute: Strict, Lax and None
How SameSite works: Strict, Lax and None, what counts as same-site, why Lax-by-default is Chromium behavior, and how to fix cookies blocked cross-site.
Cookie Security: HttpOnly, SameSite, and Secure Flags
A comprehensive guide to understanding and implementing secure HTTP cookies to protect against XSS, CSRF, and session hijacking attacks.
Cross-Origin Resource Sharing (CORS)
Master Cross-Origin Resource Sharing (CORS) for secure cross-origin HTTP requests. Learn preflight requests, headers, credentials, and common error solutions.