A production API returns unhandled stack traces and still routes /debug/env — why is this an information-disclosure threat?

## Why this is the textbook Information Disclosure finding STRIDE's Information Disclosure category is data reaching someone not entitled to it — a loss of confidentiality. What makes this pair the canonical example is that the *system is the leak*. Nothing is broken into. The service is asked an ordinary question, and it answers with material it was never meant to hand out. The attacker position is the weakest possible one — an anonymous caller with no account — and the asset at stake is the most valuable one a system holds: credentials and keys, which are the raw material for every later threat. ## What a stack trace actually gives away Read it the way an attacker does: - **Framework and version strings** in the frame list, which narrow down what is worth trying next. - **Absolute file paths**, which reveal the runtime layout, the deployment user and sometimes the internal project or team name. - **Class, package and method names**, which sketch the internal design and the names of things not exposed publicly. - **The failing statement or query**, which reveals table and column names and how input is used. - **Values interpolated into the message** — the row that failed, the identifier that was not found, and in this scenario the connection string the driver was constructing when it threw. None of these are, individually, a compromise. Together they replace a week of guessing with a map. And the connection string is not a hint at all — it is the credential. ## What a debug route gives away An endpoint that prints the process environment is a different order of problem. Modern deployments inject configuration as environment variables, so the dump typically contains database passwords, third-party API keys, signing secrets and internal hostnames. One unauthenticated GET yields everything the process can authenticate as. Debug and diagnostic routes get added during an incident and survive because nothing links to them and nobody remembers. ## Fixing it properly **Errors.** Split the audience. The caller gets a stable, generic body — an error code, a human-readable sentence with no internals, and a correlation identifier. The full exception goes to the server-side log, keyed by that identifier, so an engineer can still find it in seconds. Set this at the framework level as a default handler rather than per-endpoint, because the leak comes from the paths nobody anticipated. Make sure the non-production configuration is not the one that ships: the classic root cause is a debug flag left on in the production profile. **Debug routes.** The strong answer is that the route does not exist in the production build, or is behind a compile-time or deploy-time flag. Weaker answers that interviewers hear and dislike: renaming it to an unguessable path (security by obscurity — it is in the build, in the repository and possibly in a client bundle), or relying on nothing linking to it (crawlers and word lists find it). **The exposed secret.** This is the part juniors miss. Disclosure is not reversible. Once a connection string or key has been served in a response, it must be rotated, and you should assume the response was seen even if you have no evidence it was. Fixing the handler stops the *next* leak; rotation is what closes this one. ## The wider family The same category covers channels that never involve an error at all: - **Verbose headers** that name the server, framework or version on every response. - **Predictable identifiers and filenames** — if attachments are served as sequential names, anyone with one link can walk the set, and each retrieval is a fresh disclosure. - **Document metadata** — an exported file typically keeps its author, the editing device and, for photographs, location fields, so a document that was reviewed for its visible text still ships facts about the person and the machine that made it. When you model a process on a diagram, the useful habit is to ask not only "what does this endpoint return" but "what does it return when it fails, and what rides along with what it returns". ## How to rate it Be honest that the two halves are not equal. The stack trace is high likelihood and moderate impact on its own — easy to trigger, useful rather than fatal — unless it carries the credential, which makes it critical. The environment dump is critical on both axes: trivially triggered, and it yields the keys. In a modelling session this is exactly the moment to show you rate the *consequence* rather than assigning one severity to a bucket called "error handling".