A loyalty scheme is adding partner-operated brand hosts under its shared registrable domain — how should that change its stateless double-submit CSRF choice?
answer
- the boundary is the domain
- not a coding question
- who operates each sibling host
- isolate, bind, or hold state
- write the assumption down
basics
~20 sIt makes explicit what the stateless choice always assumed: the defence's trust boundary is the whole registrable domain, not one host. Partners you do not operate are now inside it, so either shrink the boundary or stop depending on it.
solid answer
~50 sTreat the question as a trust-boundary decision rather than a coding one. A self-referential double-submit value is secure exactly while nothing else can write into your cookie namespace, and every host under the shared registrable domain can. Bringing in partner-run hosts hands that capability to operators whose patching, vendor code and incident response you do not control. Three responses are real: move partner brands to separate registrable domains, which isolates the cookie layer at the cost of everything that depended on a shared domain; keep statelessness and bind the value cryptographically to the session, which removes the dependency on sibling behaviour for a secret you must distribute and rotate; or accept server-held state, which reintroduces exactly the coupling the stateless choice was bought to avoid. The decision is about which assumption you are willing to keep holding.
go deeper
The takeaway is that a security choice can quietly depend on who else runs a host sharing your domain name.
Be able to say why a self-referential value depends on sibling hosts, and name the change that removes that dependency.
Enumerate the hosts under the domain with an operator for each, and pick the smallest change that makes a planted cookie useless.
Own the trade between isolating the domain, distributing a secret, and reintroducing shared state — and record the assumption so it can be challenged later.
## The question behind the question A team choosing a stateless CSRF check is usually answering an architecture question — *no brand's servers should hold session state for the others* — and paying an implicit security price they never priced. The price is that a self-referential pair is only as trustworthy as **every host under the registrable domain**, because every one of them can write a cookie the others will read and cannot attribute. While all of those hosts are yours, that is a defensible position: the trust boundary matches the operational boundary. Adding partner-operated hosts breaks the match. The decision is therefore not "is double-submit good" but **"am I still willing to extend my CSRF perimeter to hosts I do not operate?"** What comes with a partner host, specifically: - a patch cadence and an incident-response posture you do not set; - third-party marketing and analytics code you did not review, any of which is one injection away from writing a cookie; - an offboarding problem — when the partnership ends, the host may keep resolving for a while; - a disclosure path: their compromise becomes your forged writes, and your logs are where it surfaces. ## The three real options | Option | What it buys | What it costs | |---|---|---| | Separate registrable domains per partner brand | The cookie layer isolates the hosts outright; a partner's compromise cannot reach your cookie namespace at all | Everything that leaned on a shared domain has to be redesigned, including how one account is recognised across brands; usually the largest change | | Keep the stateless check, bind the value to the session cryptographically | Removes the dependency on sibling behaviour without reintroducing shared state; incremental and shippable | A server secret to generate, distribute and rotate with an overlap window; reissue on login; still assumes nobody runs script on your own host | | Hold the issued value in server-side state | The strongest coupling of value to session, with no secret to manage | Reintroduces the shared store the stateless choice existed to avoid, plus its availability and latency on the write path | Most estates land on the second, and the honest reason is that it is the only one that leaves both the architecture and the security posture intact. But it is a judgment, not a rule: a scheme with two partners and a simple account model may find the first option cheaper than it looks, and a scheme that already runs shared session storage for other reasons has no reason to avoid the third. ## How to decide 1. **Write down the boundary you are actually relying on.** If the answer is "the registrable domain", list every host under it and who operates each one. The list is usually longer than anyone expects and contains at least one host nobody owns any more. 2. **Decide whether that list can be shortened.** Retiring or re-homing two forgotten hosts is sometimes the whole remediation. 3. **Ask what a single partner compromise costs**, in forged writes and in the fact that your side shows the damage. Points transfers and account changes are the writes that matter here. 4. **Choose the smallest change that makes a planted cookie useless**, then treat cookie-name hardening as a second lock over it rather than as the decision. 5. **Put the assumption in writing where the next team will find it** — in the partner agreement and in the service's own documentation — because the failure mode of this decision is that nobody knows it was made. ## What does not resolve it - **Rotating the value more often.** Rotation changes what your server issues and says nothing about a value the attacker minted. - **More entropy.** Entropy defeats guessing; this adversary chooses. - **Trusting the partner's assurances.** The capability follows from the shared domain, not from intent, and it survives any promise about how carefully they operate. - **Auditing the partner once.** The exposure is continuous and their third-party code changes weekly. ## Making the decision reviewable The output of this exercise should be a one-line statement someone can challenge later: *"our forged-write defence assumes no host under this registrable domain can write a cookie we will accept — here is why we believe that, and here is what we changed when we stopped believing it."* An estate-wide posture question — which endpoints get a defence at all and where the check runs — is a separate decision from this one; what belongs here is only whether the stateless scheme's own trust assumption still holds.
- Why is "we will require partners to meet our security standard" not an answer here?Because the capability comes from the shared registrable domain, not from how carefully anyone operates. A partner meeting every standard still runs vendor code that changes weekly, and one injection is enough to write a cookie your host accepts. Contracts allocate blame; they do not remove the capability.
- What makes moving a partner brand to its own registrable domain expensive?Everything that leaned on the shared domain must be rebuilt: recognising one account across the brands, any shared credential, and every internal assumption that the hosts were interchangeable. It is the strongest isolation available and usually the largest change on the table.
- How would you know today whether this decision has already been made badly?Enumerate the hosts under the registrable domain and name an operator for each. If nobody can, or if a host still resolving belongs to an ended partnership, the perimeter is already wider than anyone believes and the stateless check is resting on it.
saying these in an interview costs you the question
- Frames it as a library choice rather than a trust boundary.
- Says a contract with the partner removes the exposure.
- Believes a forgotten sibling host is harmless because it holds no data.
- Assumes separate hosts under one domain are already isolated.
- Offers more entropy or faster rotation as the remediation.
- Leaves the assumption undocumented for the next team.