In STRIDE, what is the Information Disclosure category and which security property does it violate?

## What the category means STRIDE is a mnemonic for six threat categories, and each letter is the negation of a security property you want to hold: | Letter | Threat | Property it violates | |---|---|---| | S | Spoofing | Authentication | | T | Tampering | Integrity | | R | Repudiation | Non-repudiation | | **I** | **Information Disclosure** | **Confidentiality** | | D | Denial of Service | Availability | | E | Elevation of Privilege | Authorisation | Information Disclosure is therefore not a named exploit and not a vulnerability class. It is the statement "data here could reach someone who is not entitled to it". The flaw that makes it possible (a missing check, a verbose handler, a world-readable bucket) is the *vulnerability*; the rated consequence is the *risk*; what you do about it is the *control*. Keeping those four words apart is most of what an interviewer is listening for. ## Where it lives on a diagram Classic STRIDE-per-element walks each element of a data-flow diagram and asks which letters apply to it. The chart is not uniform: - **External entity** (a user, a partner system): Spoofing and Repudiation only. You do not model disclosure *inside* something you do not control — the data going there is modelled on the flow that reaches it. - **Process** (a service, a function, a job): all six letters, Information Disclosure included. - **Data flow** (a call, a queue message, a file transfer): Tampering, Information Disclosure, Denial of Service. - **Data store** (a table, a bucket, a cache, a log file): Tampering, Information Disclosure, Denial of Service — plus Repudiation when the store is itself the audit record. So the practical rule is: anywhere data sits still or moves, ask who could read it. ## The channels are wider than the payload Junior candidates model disclosure as "attacker dumps the database". Real findings are usually smaller and stranger: - **The response body you meant to send** — an endpoint returns a whole record when the screen needed one field, or a list endpoint ignores the tenant filter. - **Error text** — an unhandled exception carries file paths, framework versions, a query, sometimes a credential. - **Names and structure** — sequential or guessable identifiers and filenames let someone walk the set; a directory listing reveals what exists. - **Metadata riding along** — an exported document keeps its author, editing history, device and location fields long after the visible text was reviewed. - **Differences in behaviour** — a distinct message, status code, response size or latency for "exists" versus "does not exist" is an oracle: the system answers a question you never meant to expose, without returning any data at all. - **Inference over time** — many small, individually harmless reads that add up. A leak counts even when the attacker only learns that something *exists*. Existence, volume and timing are information. ## Answering it The control family that answers Information Disclosure is confidentiality, and it splits by element type: - **On a flow**: encrypt in transit, and do not put secrets in URLs, query strings or headers that get logged along the way. - **On a store**: authorisation on reads, and scoping every query by tenant, owner or ticket rather than trusting the caller's parameters. - **On a process**: return less. Field-level minimisation, redaction by default, generic error responses with a correlation identifier for support, and uniform behaviour on paths where a difference would be an oracle. A fourth, cross-cutting answer is *detection*: for reads that are legitimate by design and cannot be blocked, an access record and a volume alert are what remain. ## Two things candidates get wrong First, **"we encrypt, so disclosure is handled"**. Encryption defends a specific channel — bytes an attacker can see without being the intended reader. It does nothing when the reader is authenticated and authorised and the application decrypts the data for them, which is how most real disclosure happens. Second, **confusing I with T and E**. Reading a store is Information Disclosure; writing it is Tampering. Being handed data the design already grants you is Information Disclosure; crossing a privilege boundary you were never given is Elevation of Privilege. Disclosure often *feeds* the other two — a leaked key or a harvested list of valid accounts is the first step of a later spoofing or elevation threat — but the finding you record for the leak itself is I. ## Why the category earns its place In a modelling session, Information Disclosure is the letter that most often produces findings nobody had thought about, because it is the only one where the system can be working exactly as written and still be wrong. Nothing is broken, nothing is overwritten, nobody is impersonated — data simply went somewhere it should not, through a channel that was never treated as an interface.