Do not expose internal technical detail
Aliases: error abstraction · safe disclosure · public reference ID
What it is
Safe error abstraction with support correlation keeps stacks, queries, paths, internal service names, policy detail, and raw reason codes in a controlled diagnostic layer while the user layer states a safe, understandable condition and action. A non-sensitive public reference ID may let users and support point to the same event. The ID is a correlation token, not a cause explanation, and must reveal no account, resource, or security-rule semantics.
Why it happens
A raw exception adds cognitive noise and can expose architecture or exploitable conditions. Erasing all diagnostic linkage instead prevents support from finding the incident and makes users repeat their story. A mapping layer chooses public copy from an internal reason code, retains detailed telemetry behind authorization, and joins the layers with an indirect reference. An unknown error still resolves to a reviewed safe state rather than passing through a message field or inventing a precise cause.
Studying it
Map error data through backend, SDK, frontend, localization, notifications, and support. Inject known, unknown, degraded, and adversarial inputs and inspect final rendering and logs. Verify that users can act without internals and that support can locate the event from the reference within authorization. Security review covers enumerability, semantic leakage, retention, and access logging. Do not probe public production errors to gather attack evidence.
Where it stops holding
Developer APIs, CLIs, and operator tools may expose more technical detail to authorized audiences, but never secrets, credentials, or cross-tenant data. A diagnostic bundle needs explicit action and redaction; “advanced user” is not blanket permission. Security copy may withhold exploitable thresholds and decision logic while still stating that the request did not complete, the data state, and a viable support path. A public reference is not an authentication credential.
Applying it
- Map internal reason code to public message key and safe recovery action; send raw exceptions only to controlled telemetry. Alert on unknown codes and show a reviewed fallback.
- Generate a separate reference ID with no business semantics or resource-access power and make it copyable. Protect support lookup with authorization, rate limits, retention, and audit.
- Scan CI and runtime output for stacks, paths, SQL, service names, tokens, policy reasons, and unresolved localization keys across toasts, email, status pages, and fallbacks.
- Exercise both ends: users act without internals and support correlates the event. Fix the supply-chain mapping when a leak appears rather than masking one rendered string.
Related
- Same group: T2.04.1 Say what happened, why, and what to do · T2.04.2 Do not blame the user in error messages · T2.04.4 Do not joke away real losses · T2.04.5 Same-class errors need consistent wording
- Adjacent: T1.05.3 Internal codenames must never reach the user interface · T3.04.2 Multi-channel content needs a single source of truth
- Search terms:
safe error disclosure·reference ID·support correlation