SI-11 has two requirements. Generate error messages that provide the information needed for corrective action without revealing information that could be exploited. Reveal error messages only to the roles you designate.
800-53 binds federal systems and contractors. For product teams it is the formal home of a familiar rule: do not show a stack trace to a user.
What it means in practice
NIST gives examples of exploitable information in errors: stack traces and implementation details, logon attempts where a password was mistyped into the username field, business information that can be derived from what is recorded, and personal data such as account numbers, social security numbers and card numbers. It adds that error messages can also be a covert channel for passing information out.
The balance is the point. An error that says "something went wrong" helps nobody. One that prints the database host and query helps an attacker. The user sees a short, safe message with a reference id. The detail goes to logs that only authorized staff can read.
Evidence to collect
- A coding standard section on error handling, with an example of the safe pattern.
- Production configuration showing debug mode and verbose errors are off.
- Screenshots or captured responses for common failures such as bad input, missing resource and server error, showing generic bodies.
- Logging configuration showing details go to a restricted log store, with access controls on it.
- Log scrubbing rules that keep secrets and personal data out of messages.
- Test cases that trigger errors and check responses.
Common gaps
Debug flags left on in one environment that is internet facing. Framework default error pages. Different messages for "user not found" and "wrong password," which let someone enumerate accounts. Error details sent to a third party service that many employees can read. Logs that contain passwords typed in the wrong field, which NIST mentions directly.
How to implement it
- Set one global error handler per service that returns a safe body and a correlation id.
- Turn off debug output and stack traces in production by configuration, and test that the setting holds after each deploy.
- Send full detail to a log system with role based access. Document who may read it.
- Make authentication errors identical for unknown user and wrong password.
- Scrub secrets and personal data before logging.
- Add negative tests that assert no stack trace or internal path appears in a response.
- Scan the running application for verbose errors, since a fresh release can bring the problem back.
Support teams need a path too. Give them the correlation id so they can ask engineering for the detail without asking the customer to paste it.
Quick check
Who should see detailed errors?
Only the roles you designate, such as engineers and support staff with access to restricted logs.
Why should login errors be identical for unknown user and wrong password?
Different messages let an attacker discover which accounts exist.
