What does a build-time server-only guard give you that a naming convention plus code review does not?
answer
- prevention beats intention
- a poison pill in the client build
- catches transitive, not just direct
- fails the build and names the chain
basics
~20 sIt fails the build whenever a protected module is reached from a client entry point, and names the import chain that did it. Review catches direct imports; the guard also catches the transitive ones introduced later.
solid answer
~50 sMechanically the guard is a sentinel module that resolves normally in the server compilation and to a compile-time error in the client one; the sensitive module imports it at the top. If any chain of imports connects a client entry to that module, the client build fails and reports the chain. That turns an invariant a human had to evaluate — *is this reachable from client code?* — into one the build evaluates exhaustively on every commit, including commits that never touch the sensitive file. Review cannot do that reliably: the dangerous imports are transitive, arrive through re-export barrels or a value import that should have been type-only, and are added by people who have never seen the guarded file. The limits are worth stating: it guards modules, not values already handed to client code, and it only protects modules that opted in.
go deeper
Know that a build can be made to fail when server-only code is imported by browser code, and that this is better than relying on people to remember. Be able to say why the build sees more than a reviewer.
Explain the mechanism: a module that errors in the client compilation, imported by the sensitive file, so any reachable chain fails the build and reports the path that caused it.
Name the limits honestly — module reachability only, opt-in only, build-time only — and pair the guard with output scanning before deploy and rotation afterwards, since each layer covers a blind spot of the previous one.
Decide where the guards live. Consolidating privileged access into a few guarded chokepoints buys more safety per unit of friction than blanket enforcement, which teams route around and then believe themselves protected.
## What review can and cannot see A naming convention plus code review is a control that depends on a human evaluating a property that is not visible in the diff. The property is: *is this module reachable by import from any client entry point?* Answering it requires walking an import graph that may be dozens of modules wide and that changes on every commit — including commits that do not touch the sensitive file at all. Review catches the direct, obvious import. It systematically misses: - an import added three modules deep in a shared helper, months later, by someone who has never seen the sensitive file; - a re-export barrel that gains one new line and silently starts dragging a privileged module wherever it is imported; - a third-party package upgrade that begins re-exporting more than it did; - a type reference written as a value import, which looks harmless and is not; - a refactor that moves a component across the boundary without changing the import it carries. ## What a build-time guard actually is Mechanically it is small: a sentinel module that resolves to one thing in the server compilation and to a compile-time error in the client compilation. The sensitive module imports it at the top. Nothing about the sensitive module's own code changes. The consequence is what matters. If any chain of imports connects a client entry point to that module, the **client build fails**, and the error carries the chain that caused it. The guard converts an invariant that a human had to evaluate into one the build evaluates exhaustively, on every build, for free. | Scenario | Convention + review | Build-time guard | |---|---|---| | Direct import from client code | usually caught | fails the build | | Import added three modules deep later | rarely caught | fails the build | | Barrel re-export gains a line | rarely caught | fails the build | | Value import that should be type-only | almost never caught | fails the build | | Someone copies the literal into a client file | sometimes caught | not caught | | A value already handed across the boundary | sometimes caught | not caught | ## What it does not cover The last two rows are the honest limits, and a strong answer names them: - **It guards modules, not values.** Once something has been read on the server and handed to client code as data, the guard has nothing to say — that is a different control. - **The protected module must opt in.** A guard is a per-module decision. Anything nobody marked is unprotected, which is why the placement question below matters more than the mechanism. - **It is a build-time control, not a runtime one.** It proves nothing about what a deployed server does; it only prevents a bundle from containing what it must not. - **It can be removed.** Someone who deletes the import to make a build pass has defeated it, which is an argument for treating the guard line as reviewed code and the failure as a signal to fix, not to suppress. ## Where to put it The leverage comes from **chokepoints**, not from coverage. Guarding every file produces noise, suppressions, and eventually a team habit of deleting the line. Guarding the handful of modules through which every privileged operation passes — the data-access layer, the credential reader, the internal client — covers a far larger surface with one decision each, and it pushes the architecture in a useful direction: if privilege has to funnel through a guarded module, privilege is now enumerable. ## Making the failure useful A guard is only as good as the moment it fires: 1. **Fail the build, not a warning.** A warning in a log nobody reads is a convention with extra steps. 2. **Name the chain.** The error should say which client entry reached which module and through what, because the fix is almost always "split the shared symbol out", and you cannot do that without the path. 3. **Give people the sanctioned route.** Most violations are someone trying to do something reasonable. If there is no server-side way to do it, the guard will be routed around. 4. **Review suppressions as changes to the security posture**, because that is what they are. ## The layer it belongs to Prevention of this kind is the cheapest control available and it is still not sufficient alone. The complete shape is prevent (the guard), detect (search the built client output for a canary before deploying), and recover (rotate anything that was disclosed). Each layer covers a failure the one before it cannot: the guard cannot see what it was never applied to, the scan cannot tell you which import caused it, and rotation is the only step that actually revokes a value a browser already downloaded.
- Should the guard go on every sensitive file, or on a few?On a few. Guarding everything produces noise, routine suppressions, and eventually a habit of deleting the line. Guarding the chokepoints that all privileged work passes through — the data-access layer, the credential reader, the internal client — covers a much larger surface per decision and pushes the codebase toward having enumerable privilege.
- Can the guard stop someone from deliberately exposing a secret to the client?No. It governs module reachability, so a literal copied into a client file, or a value read on the server and handed across as data, passes straight through it. Those need different controls: review, scanning the built output for canaries, and the ability to rotate anything that was disclosed.
A convention is a sign on the door asking people not to enter; the guard is a tripwire. The sign works only on those who read it, while the tripwire fires the first time anyone walks through, including someone who arrived down a corridor nobody knew connected.
saying these in an interview costs you the question
- Thinks review reliably catches an import added three modules deep.
- Believes the guard also protects values already handed to client code.
- Expects the guard to work on modules that never opted into it.
- Treats the build failure as a lint warning to suppress when inconvenient.
- Assumes a runtime error is as good as a build error for a bundling problem.