Browser Security: Same-Origin, CORS and CSRF

Origin. An origin is scheme + host + port. https://app.example.com and https://api.example.com are different origins. The same-origin policy stops a page from one origin from *reading* responses from another. It does not stop the request from being sent.

CORS. For a cross-origin request, the browser sends an Origin header and only exposes the response to the page if the server replies with a matching Access-Control-Allow-Origin. Requests that could change data (non-simple methods, JSON content type, custom headers) are preceded by a preflight OPTIONS request asking which methods and headers are allowed.

A correct policy. Compare the request's Origin against an allow-list of exact origins and echo back only a match (adding Vary: Origin). Pitfalls: reflecting any origin; using * together with credentials (browsers refuse it, and a reflect-everything workaround is a real vulnerability); trusting the null origin; and substring matches such as endsWith('example.com'), which accept evilexample.com.

ALLOWED = {'https://app.example.com', 'https://admin.example.com'}

def cors_headers(origin):
    if origin in ALLOWED:
        return {'Access-Control-Allow-Origin': origin, 'Vary': 'Origin'}
    return {}

CORS is not authentication. It is enforced by browsers only, protects the user's reading of data, and does nothing against curl, scripts or servers. The API still needs real auth on every request.

CSRF. Browsers attach cookies automatically. If you are logged in to bank.com and visit a malicious page containing a form that posts to bank.com/transfer, the browser sends your cookie along, and the bank sees an authenticated request. The attacker cannot read the response, but the action happens.

Defences. (1) CSRF tokens: a random per-session value placed in forms or a header, which the attacker's page cannot read; the server rejects state-changing requests without a matching token, compared in constant time. (2) SameSite cookies (Lax or Strict) so the browser omits the cookie on cross-site requests. (3) Check Origin/Referer. (4) Never change state on GET.

APIs using bearer tokens in an Authorization header (not cookies) are not CSRF-prone, because the browser does not attach that header automatically, but they trade it for the need to store the token safely (XSS then becomes the risk).