A municipal API returns stack traces that include resident email addresses in error bodies. How should the tester classify this?

Municipal APIs that return stack traces containing resident email addresses illustrate information disclosure: verbose errors can leak PII, tokens, paths, versions, or internal design details to unauthorized clients. Testers should classify and severity-rate the disclosure based on data sensitivity and audience of the endpoint.

Expecting APIs to always echo full exception objects to clients is incorrect hardening guidance. Treating the issue as DNS misconfiguration misattributes an application-response problem. Calling it proof of domain-administrator privilege escalation invents an AD outcome the error body does not demonstrate.

Exam caveat: distinguish debug-mode leakage in non-production from production APIs that still emit verbose faults under edge cases.

Operational check: trigger controlled error paths on the civic API within RoE, capture response bodies showing PII or internals, and recommend generic client errors with detailed logging only server-side. Note privacy and records-handling implications for the municipality. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.