Recognize and Mitigate Cross-Site Request Forgery

Cross-site request forgery (CSRF) happens when Other site causes a user’s browser to perform an unwanted authenticated, state-changing request to Northstar Account.

In this illustrated scenario, the user already has a valid session. Other site triggers a request that changes the account email to learner@example.test. The Browser attaches the session credential automatically, and the Application server treats the request as authenticated.

The important point is the unwanted server-side action—not whether Other site can view the result.

Follow the request, not just the page that started it.

Automatic credentials are a condition to investigate, not proof of CSRF by themselves. A successful forgery also needs:

1. A request shape that Other site can trigger.
2. A state-changing operation that the Application server accepts.
3. No effective request-forgery check at the server.

The attacker does not need to know the value of the session cookie. They also do not need to read the response. Their goal is to cause the Browser to send a request that the server accepts.

This differs from XSS: CSRF induces a request from outside the application; XSS runs attacker-controlled code in the application’s own origin.

Vulnerable variant — illustrative endpoint contract. A form-compatible request is accepted without CSRF validation.

Two URL boundaries answer different questions.

An origin is the exact combination of scheme, host, and port. All three must match for two URLs to be same-origin.

A schemeful site uses the scheme and the shared registrable domain. It does not separate sibling subdomains or ports in the way an origin does. So two URLs may be same-site while still being different origins.

Use https://app.northstar.example as the reference. For origin comparison, an omitted HTTPS port is effectively 443.

First compare scheme, host, and port exactly. Then, if the origins differ, compare the scheme and registrable domain to determine whether the pair is still same-site.

https://app.northstar.example and https://promo.northstar.example have different hosts, so they are not same-origin. Yet they share the https scheme and the northstar.example registrable domain, so they are same-site.

Likewise, changing only the port creates a different origin without changing the site. Changing https to http changes both the origin and the schemeful site.

For a request that attempts to update the Northstar Account email to learner@example.test, SameSite answers one narrow question: is the session cookie eligible in this request context?

It does not prove that a request was sent, that a response is readable, or that application state changed. Those outcomes depend on additional browser and server behavior.

Assume a matching cookie host and path, an HTTPS target, any required request credentials, and no extra browser privacy blocking. Compare explicit policies only; do not rely on a browser default.

For the session cookie, Northstar Account uses an explicit attribute such as:

Set-Cookie: session=<opaque-session>; Path=/; Secure; HttpOnly; SameSite=Lax

The table compares explicit values at the SameSite layer. The sibling request originates at https://promo.northstar.example and targets https://app.northstar.example: it is same-site, even though it is cross-origin.

A state-changing request must not use GET. Consider the Unsafe GET variant:

GET /api/profile/email?email=learner@example.test

Assume the authenticated session was set with:

Set-Cookie: session=<opaque-session>; Path=/; Secure; HttpOnly; SameSite=Lax

From https://outside.example, a top-level navigation to that URL can be a cross-site safe-method navigation. At the SameSite layer, the Lax session cookie is eligible. If the server treats that GET as an email update, the navigation can change the account even though the user did not intend the update.

A navigation is not proof of user intent. Use GET for retrieval only; moving a write to POST fixes HTTP semantics, but POST alone is not a CSRF defense.

Response access and request delivery are separate questions. The Vulnerable variant accepts application/x-www-form-urlencoded without CSRF validation. A page at https://outside.example can submit a normal cross-origin form to it.

Assume this explicit cookie policy:

Set-Cookie: session=<opaque-session>; Path=/; Secure; HttpOnly; SameSite=None

At the SameSite layer, that cookie is eligible for the cross-site form submission. The other site's page does not need to read the response for the Application server to process the request and change state. A browser restriction on reading a cross-origin response does not undo a request already accepted by the server.

Vulnerable variant — the server accepts this form-compatible request without CSRF validation.

The Protected variant uses the documented JSON-and-token contract. Requiring JSON or a custom header can cause a browser to preflight a scripted cross-origin request. A rejected preflight prevents that particular scripted request from being sent.

That is narrower than a complete defense: it does not protect an Unsafe GET variant or a separate form-compatible endpoint. The server must enforce its contract for every state-changing request; changing GET to POST, or observing one CORS error, is not enough.

Northstar Account uses a synchronizer-token contract. The Application server creates an unpredictable anti-CSRF token associated with the authenticated session, then makes that token available to the legitimate same-origin client.

For the protected update, the client first requests GET /api/csrf-token. It then sends POST /api/profile/email with JSON and the token in X-CSRF-Token. The server must compare the submitted token with the authenticated session before it changes the email to learner@example.test.

A cookie can authenticate a request automatically; the anti-CSRF token is the additional value that an unrelated site should not be able to supply under this contract.

The client participates in the contract; it does not enforce it alone. It obtains the server-issued token, verifies the documented response shape, and attaches the token in the required header. credentials: "same-origin" allows the same-origin request to use the existing browser-managed session.

If token acquisition fails or its JSON shape is invalid, stop the update. If the update returns 403 Forbidden, surface that rejection. Do not retry the update without the anti-CSRF token.

The Application server must reject a missing, invalid, or session-mismatched token before changing state. A fixed client-generated value, a header whose value is never checked, or a check that only tests whether a header exists does not provide this defense.

The function stops if it cannot obtain a valid token and treats a 403 Forbidden update as a rejection rather than removing the protection.

Source validation is an additional server-enforced check for a state-changing request. For browser requests, the server examines the browser-reported Origin header. If Origin is absent, a documented policy may examine Referer instead.

This check answers where the browser says the request came from. It does not replace session authentication, authorization, or the anti-CSRF token check. The Application server must complete all required checks before it updates the account email.

Use an explicit allowlist containing parsed origins, not string fragments. In this policy, the only trusted source origin is https://app.northstar.example.

An origin includes scheme, host, and port. Therefore, a sibling origin is not trusted merely because it is same-site. Referer is a full URL, so the server parses it and compares its origin—not its complete page path—to the allowlist.

Review a proposed defense as a chain, not as a single setting:

1. What operation changes state?
2. Which request shapes can an untrusted site trigger?
3. Can the Browser attach session automatically in that context?
4. Which requests does the Application server accept and validate?
5. Did the server change state, regardless of whether the other site could read the response?

A CSRF finding needs both an attacker-triggerable state-changing request and server acceptance without an effective forgery check. Automatic credentials alone are not enough.

A repair must close every state-changing entry point and divide responsibilities correctly. The client follows the documented contract; the Application server enforces it. Cookie policy, CORS, and XSS controls contribute different protections.

Northstar Account has this proposed design:

• Unsafe GET variant: GET /api/profile/email?email=learner@example.test updates the account email.
• Vulnerable variant: POST /api/profile/email accepts application/x-www-form-urlencoded; its handler ignores X-CSRF-Token and performs no token validation.
• The team says the page sends an anti-CSRF token header, SameSite=Lax makes the session cookie safe, and CORS prevents any attack.

Assume a signed-in user visits https://outside.example. That site causes a top-level HTTPS navigation using the Unsafe GET variant. The target cookie host and path match, no additional privacy blocking applies, and the session cookie explicitly uses SameSite=Lax.