Your security reviewer wants every caller-facing Go error cut to one fixed string; support wants detail. How do you set the policy?

## Why this is a posture, not a bug fix "How much internal detail may a caller see" is not decided by whoever writes the next handler. It is a standing rule with three interested parties — the security reviewer who can veto, the support and on-call organisation who pay for terseness, and the API consumers who have to build against whatever you emit. In Go the question is unusually sharp, because a wrapped error chain is one flat string with no marking of which parts are internal, so the *only* place the distinction can exist is a rule you write and enforce. ## Default deny, with a named allowlist Blocklists lose. "Strip connection strings, strip SQL, strip file paths" needs updating for every new dependency, every new wrap site, and every wording change in a driver. An allowlist is stable and short: 1. **A stable error code** — a small, documented, machine-readable set (`not_found`, `invalid_argument`, `rate_limited`, `internal`). Codes are better than prose for both audiences: consumers can branch on them, and they disclose nothing about implementation. 2. **Values the caller supplied** — echoing back an id or a field name they sent reveals nothing new and makes the message actionable. 3. **A correlation id** — the join key between the terse response and the full chain in your logs. Everything else — the wrapped chain, driver wording, host names, internal identifiers you resolved on the caller's behalf, timings that hint at internal topology — stays on the operator side by default. "Default" is the operative word: the posture must name who can grant an exception, and exceptions should be written down next to the endpoint rather than living in someone's memory of a review. ## Answering support honestly The worst version of this argument is one where you tell support to accept less. Do not. Show them that a correlation id buys them the **whole** chain, the request fields, and the surrounding log context, instead of one truncated sentence pasted from a customer ticket. Then remove the friction that makes the id feel like a downgrade: it must appear in the response body, in the log line, and ideally in a response header, and there must be a one-click search that turns it into the incident. If that lookup is slow or gated behind an access request, the posture will erode, because engineers under pressure will re-add detail to the message. Retention matters too — a five-minute log retention makes the id useless for anything a customer reports the next day. ## Enforcement is the actual decision A policy nobody can violate is worth more than a policy everyone agrees with: - **One helper** that turns an error into a response, so the disclosure decision exists in one readable function per service. - **A test** that forces a failure and asserts on the captured response body: fixed text and id present, driver and query text absent. This is what a security reviewer can sign off, and it is what makes a regression a red build instead of an incident. - **A review rule** narrow enough to be mechanical: handlers never pass error text to the response writer. A style-guide paragraph and a review checklist are the weakest options, because both depend on attention. Prefer the version that fails loudly. ## Where the posture legitimately differs - **Internal service-to-service calls** are not automatically exempt. They cross trust boundaries in most estates, their responses get logged by the caller, and an internal caller pasting your message into a ticket ends up in the same place. If you do relax the rule internally, say so explicitly and say why. - **Public partner APIs** need the opposite of prose: a documented, versioned code set that partners can actually program against, plus a stable field for the correlation id. This is where investment pays, and where a free-text message is a liability you cannot change later. - **Debug and admin surfaces** may carry more, if they are authenticated, audited and clearly separated from the normal path — never as a flag that changes what the production path emits. ## The pattern to refuse Environment-gated verbosity — full chain in staging, fixed text in production — is the most common proposal and the one to reject. It means the code path that ships is the path nobody exercises, one bad config reinstates the leak, and the fault mode is silent. Keep one path; put the detail in the log. ## Owning the decision Finally, be explicit about who owns it and what would change it. The security reviewer can overrule an exception; the service owner writes the posture; a change in threat model (a public API launch, a compliance scope change, a partner integration) is a reason to revisit it. Write those three sentences down. The reason this is a principal-level question is not that the technique is hard — the helper is fifteen lines — it is that the rule has to survive people who never read the incident that motivated it.