Across several front-end applications, how would you decide which configuration values may be marked public, and make that decision hold?

## What you are actually governing The mechanism is simple and unforgiving: a naming convention decides what gets copied into downloadable files, and it obeys whoever types the name. There is no authority in the toolchain that knows a signing key from a base URL. So the thing to govern is not the mechanism but the **classification decision** — who makes it, how it is recorded, and what happens when someone under pressure makes it differently at 6 p.m. Across several applications the difficulty compounds. Each team has its own environment file, its own pipeline, and its own idea of what is sensitive, while the failure is uniform: one wrong name publishes a value permanently. ## A three-tier classification | Tier | Test | Delivery | Examples | |---|---|---|---| | **Server-only** | Possession of the string grants access to something | Never leaves the server; requests needing it are made server-side | Upstream credentials, signing keys, database URLs | | **Delivered at render** | Not a credential, but differs per environment or must change without a build | Read privately on the server, embedded as an enumerated subset | Base URLs, tenant identifiers, flag states, telemetry destinations | | **Inlined at build** | Identical in every environment and safe to freeze until the next build | Substituted into the bundle by the public naming rule | Public product identifiers, build stamps, release-scoped flags | Default-closed: an unclassified value is server-only until someone argues it down, and the argument is recorded in the diff that reclassifies it. ## The tier that needs the sharpest line The boundary that matters is the first one, and the test has to be mechanical because judgement varies under deadline: **if holding the string is sufficient to act, it is server-only** — regardless of how obscure the caller is, how short-lived the value is, or how private the network is said to be. Obscurity, minification and "only our admin screen uses it" are not part of the test. The adjacent case deserves an explicit answer too, because teams argue about it endlessly: vendor keys that the issuer expects to be visible. They belong in the public tiers, and their protection is a **restriction at the issuer** — allowed origins, scope, quota, referrer rules. Write that down so the discussion happens once, and require the restriction to be configured before the key is exposed. ## Enforcement that does not depend on vigilance 1. **Pattern check on names.** Fail the build when a publicly marked name contains credential-shaped words, or when its value matches a known credential format. Cheap, noisy in a useful way, and it fires on the exact diff that causes the incident. 2. **Scan the artifact, not the source.** After the build, search emitted client files for the values of names classified private. This is the only check that catches a private value reaching the client by a route other than the naming rule. 3. **Publish the exposed set.** Each application emits the list of public keys it ships. A reviewer sees the blast radius in one screen, and a diff to that list is a visible event rather than a buried rename. 4. **Validate required public names at build end.** A missing value inlines as empty and fails silently in production; asserting presence turns that into a pipeline failure. ## Removing the pressure that causes the mistake Almost every wrongly published value starts as a broken client read: code in the browser wanted a private value, got nothing, and the one-line fix was to rename it. Policy that only punishes the rename loses to the deadline. The durable moves are to make the failing read **fail at build time with an explanatory message**, and to make the correct alternative — have the server make the call and return only the result — the paved path, with a template every application already has. ## Where to stay flexible - **Do not over-privatise.** Routing every value through render-time delivery grows the payload on every response and buys nothing for values that are identical everywhere. - **Let team ownership stand at tier two and three**, but keep tier one central: the cost of a wrong call there is not local. - **Re-examine tier three periodically.** Values inlined because they were identical everywhere are the ones that quietly stop being identical, and nothing in the build notices. ## What good looks like a year later The list of publicly exposed keys per application is short, reviewed, and shrinking. The pipeline, not a reviewer, is what catches a rename. Nobody argues about vendor keys because the rule was written once. And when a value is wrongly exposed, the response is rehearsed: replace it at the issuer, check its usage, then ask why client code wanted it.