CWE-1230 applies when a product prevents direct access to a resource holding sensitive information, but does not sufficiently limit access to metadata derived from it. Anyone who builds search, analytics or reporting on top of sensitive data should read it.
How it happens
Developers often protect the primary store correctly and forget the derived copies. MITRE lists metadata, search indices and statistical reports as places where portions of the original information may be recorded. If those are not restricted too, an attacker may extract some or all of the original information, or infer details about it.
The record gives two concrete ideas. An attacker could submit search terms known to be unique to a particular person, and learn from the results whether that person appears in the data. Or an attacker could view metadata such as activity or creation dates to identify usage patterns.
Neither requires reading the protected record itself.
What an attacker gains
The record lists a confidentiality impact: reading application data, in whole or in part, directly or by inference.
How to find it
The record has no detection methods. For each sensitive dataset, list every derived artifact: indexes, caches, exports, reports, counters, timestamps and logs. Then check that each has an access policy at least as strict as the source. Try queries as a low privilege user and look at what the answers reveal.
How to fix it
The record has no formal mitigations. The description points to a straightforward rule. Apply the same access control to derived data that you apply to the original, and review what a search result, count or date can reveal on its own.
Quick check
How can a search index leak data?
An attacker can search for terms unique to a person and see whether results come back, which reveals details of the protected data.
