Permalink can attach state changes to an authenticated buyer session on an unauthenticated GET: what protects against CSRF?

[vishkaty]

Summary

The shopping permalink (#523) is an unauthenticated browser GET that a Business MAY act on to change server-side state, and one of the permitted actions is merging items into an existing cart. When that existing cart belongs to a signed-in buyer, a cross-site link that mutates it on load is a cross-site request forgery. I could not find guidance on what is expected to protect this case, and the usual mitigations are not straightforward for a top-level GET, so this is a question rather than a proposed fix.

Observed

State construction (docs/specification/permalink.md, Redirect Resolution):

it MAY merge the permalink items into an existing cart, create a new cart, or stage a separate checkout

Security model (docs/specification/permalink.md, Security Considerations):

A permalink endpoint is an unauthenticated browser GET.

The Security Considerations section covers open redirect, header injection, mass assignment, log injection, and privacy, but a search for csrf, samesite, or forgery returns nothing.

The irreversible risks are already closed by the existing rule that a Business MUST NOT treat loading a permalink as authorization to place an order, charge payment, or complete checkout, so the residual case is narrower: an automated merge into an authenticated buyer's cart on a cross-site GET.

Why the mitigation is not obvious

The usual CSRF defenses do not map cleanly here. SameSite=Lax (the browser default) still sends cookies on top-level cross-site GET navigations, which is exactly how a permalink arrives, so it does not defend this case; SameSite=Strict would, but it would also break the legitimate flow of a buyer clicking a shared or campaign link and landing in their authenticated session. A CSRF token cannot ride an inbound top-level GET from an external link either.

Question

What is the intended protection for the automated-merge-into-authenticated-session case? One option would be to construct only anonymous, unattached state on load and require an explicit buyer action before attaching it to the signed-in session, but I did not want to assume that is the intended model. Guidance here (even a short note that the merge is expected to be anonymous-until-confirmed) would help implementers avoid shipping an accidental CSRF.

[vishkaty]

The Security Considerations section itself notes that browsers, prefetchers, link preview bots, and security scanners load permalink URLs without buyer intent, so a prefetcher mutating the cart of a signed in buyer needs no attacker at all. A minimal non breaking rule would settle it: state constructed from a permalink load SHOULD be unattached to any authenticated buyer session, and a Business MUST require an explicit buyer action before merging permalink initiated state into the existing cart of an authenticated buyer.

[westonale]

The rule you proposed is right, unattached until confirmed closes the actual gap, and it costs the legitimate flow nothing since a real buyer confirming is a normal step, not friction added for security theater.

One thing worth pinning down before it ships: what counts as the explicit action has to exclude anything that happens automatically as part of loading or redirecting the permalink itself. If a signed in buyer following a malicious link lands on a page that already auto merges on render, or auto redirects into a confirmation step with a pre filled submit, the attacker gets the same outcome through the front door of "the user was technically present for it." The MUST needs to bind to an action the buyer takes on state they can see, not an action the page takes on the buyer's behalf before they've seen anything.

Same shape of problem as a cached mirror of remote state, actually, the failure isn't the merge, it's trusting a signal that arrived without anyone actually deciding anything.

[vishkaty]

Good catch, and I agree the MUST has to bind to an action on state the buyer can see. Tightening the rule accordingly: a Business MUST require an explicit buyer action on rendered permalink state before merging it into an authenticated buyer's cart, and automatic merges on load, redirect, or a pre filled submit do not satisfy it.

[vishkaty]

Filed as PR #789: adds the explicit buyer action rule we settled on here directly to Redirect Resolution in permalink.md. It calls out that an automatic merge on load, on redirect, or through a pre-filled submit does not satisfy it.