The Concept of eTLD+1#

Browsers need to know where a “company” domain ends and a “public” domain begins. They use a hardcoded list called the Public Suffix List (PSL).

• An eTLD (Effective Top-Level Domain) is a public suffix where anyone can register a domain. Examples: .com, .co.uk, .github.io.

• An eTLD+1 is the eTLD plus the one specific name registered right beneath it.

  • For api.target.com, the eTLD is .com. The eTLD+1 is target.com.

  • For user1.github.io, the eTLD is .github.io. The eTLD+1 is user1.github.io.

What it is#

An Origin requires a strictly exact match of three elements:

Scheme + Hostname + Port

If any of these three change, you are Cross-Origin.

Why it is used#

It drives the Same-Origin Policy (SOP). The SOP is the browser’s primary defense against malicious code. It dictates that JavaScript executing on one Origin cannot read the DOM or the network responses of another Origin. Without it, visiting evil.com would allow a malicious script to read your banking details on bank.com.

How it is set#

Sometimes, developers need to share data across origins (e.g., app.target.com fetching user data from api.target.com). To bypass the SOP, they configure Cross-Origin Resource Sharing (CORS).

The server sends an HTTP header: Access-Control-Allow-Origin: https://app.target.com. This tells the browser to punch a specific hole in the SOP for that exact origin.

What Hackers Do When It Fails#

If a developer misconfigures CORS, the SOP is functionally broken.

• The Flaw: Developers often use lazy regex to check the incoming Origin header and reflect it back to the user to allow multiple subdomains dynamically.

• The Exploit: If the regex only checks if the request contains “target.com”, a hacker registers target.com.evil.com. The server reflects this malicious origin, allowing the hacker’s site to read sensitive API responses across the boundary.

What it is#

A Site is a broader, looser boundary. It requires a match of only two elements:

Scheme + eTLD+1

Ports do not matter. Subdomains do not matter. https://api.target.com:8443 and https://www.target.com:443 are Cross-Origin, but they are exactly the Same-Site because they share the https:// scheme and the target.com eTLD+1.

Why it is used#

It controls session state and cookies. Browsers use the Site boundary to decide if they should attach a user’s session cookie when a request is made. This defends against Cross-Site Request Forgery (CSRF)—where an attacker tricks your browser into executing an action on a site where you are currently logged in.

How it is set#

Developers enforce this via the SameSite attribute on the Set-Cookie HTTP header.

• Strict: The cookie is only sent if the request originates from the Same-Site.

• Lax: (Modern default). The cookie is not sent on cross-site POST requests (blocking most CSRF), but is sent on safe top-level navigations like clicking a standard link.

• None: The cookie is sent everywhere.

What Hackers Do When It Fails#

If SameSite is absent (defaulting to Lax) or misconfigured, hackers target the fact that subdomains share the Site boundary.

• The Flaw: A company has a forgotten, vulnerable subdomain like promo.target.com with a Cross-Site Scripting (XSS) vulnerability.

• The Exploit (Subdomain Takeover to CSRF): The hacker hosts a CSRF payload on promo.target.com that targets app.target.com. Because both subdomains are Same-Site, the browser attaches the victim’s session cookies. SameSite protections are entirely bypassed.

• The Exploit (Cookie Tossing): The hacker uses the XSS on the subdomain to write a new session cookie scoped to the parent .target.com. The victim’s browser will now send this attacker-controlled cookie to the main application, resulting in a forced session or account takeover.