Your team keeps server-only code out of the browser by convention alone. How would you decide what enforcement to add?

## Start from blast radius, not from coverage The instinct when a convention feels fragile is to enforce it everywhere. That is the wrong first move, because the cost of a boundary violation is wildly uneven. A formatting library crossing the line costs bytes. A credential reader crossing the line costs a rotation, an incident review, and possibly a disclosure. Enforcement effort should follow that distribution, not the file count. So the first question is not "how do we check this?" but "**what leaks, and what does each leak cost us?**" Enumerate the categories actually present in the codebase — credentials, privileged access code, internal topology, rules that must not be readable, heavy render-only dependencies — and rank them. The ranking is the design input for everything below. ## Three layers, each covering what the previous cannot | Layer | Mechanism | Catches | Blind spot | |---|---|---|---| | Prevent | build-time guard on a module: client-reachable import fails the build and names the chain | every transitive import into a guarded module, on every build | anything not guarded; values already handed to client code | | Detect | pipeline step searching built client output for canaries and credential shapes | leaks through modules nobody guarded | says a value leaked, not which import caused it | | Recover | rotation, exposure scoping, use auditing | the leaks that shipped anyway | costs incident time; some leaks (topology) cannot be rotated | A strategy that stops at prevention is betting that the guard was applied everywhere it mattered — which is precisely the assumption that convention-only already failed at. A strategy that stops at detection ships defects and finds them late. The argument for all three is that each layer's blind spot is the next layer's job. ## Guard chokepoints, not files The highest-leverage decision is architectural. If every privileged operation has to pass through a small set of modules — one data-access layer, one credential reader, one internal client — then a guard on each of them covers the whole surface, and the guarded set is small enough to review as a unit. If privilege is scattered across a hundred files, no enforcement scheme will be cheap, and the right project is the consolidation rather than the checking. This also produces a better failure message. When someone violates the boundary, the build points at a named, deliberate module with an obvious server-side alternative, instead of at an arbitrary file. ## Budget for friction, and spend it once Enforcement that people route around is worse than none, because it converts an unknown risk into a believed-safe one. The practical controls: - **Keep the guarded set small** so failures are rare and meaningful rather than routine. - **Make the error actionable** — the chain plus the sanctioned alternative. - **Provide the alternative before you add the gate.** Most violations are someone doing something reasonable with no server-side route available. - **Treat suppressions as posture changes**, reviewed by whoever owns the boundary. ## A rollout that does not stop the team 1. **Inventory** what privileged access exists and where it lives; this alone usually surfaces surprises. 2. **Consolidate** it into as few modules as the codebase will tolerate in one pass. 3. **Guard the consolidated modules.** Fix the violations this exposes; they are real. 4. **Add output scanning to the pipeline** with a canary planted in a server-only module, so the detector itself is proven to work rather than assumed to. 5. **Write the rotation runbook** while nothing is on fire, and rehearse it once. 6. **Revisit when the shape changes** — a new integration, a new deployment target, a new team. ## When convention genuinely is enough Not every boundary deserves a gate. Where the reachable set holds nothing secret and the worst outcome is extra download weight, the failure is loud, cheap and self-correcting; that belongs to the team's performance controls, not a security gate. The criterion is the same one that justifies any build-time check: **enforce where the failure is silent and expensive; leave conventions where it is visible and cheap.** ## What the judgment call really is There is no single correct answer, and an interviewer is listening for whether you can price the options. The strong version reasons about what leaks and what that costs, picks enforcement proportional to that cost, funnels privilege through auditable chokepoints so enforcement stays small, and keeps recovery capability regardless of how good prevention looks — because the one thing that is certain about a boundary is that something will eventually cross it.