Error Handling SI-11

System and Information Integrity · Moderate baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds SI-11 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, System and Information Integrity family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

SI-11 (Error Handling) is about making sure your systems and applications produce error messages that help you fix problems — without handing an attacker a map of how the system works. A stack trace, a full file path, a database error, or a raw SQL (Structured Query Language) statement shown on a public page can reveal exactly what an attacker needs. This control also limits who is allowed to see the detailed errors. It sits in the Moderate baseline.

What good looks like

Show users a plain, safe message (for example ‘Something went wrong — please try again’) and keep the technical detail out of what they see.
Log the full detail privately to a file only administrators can read, so you still have what you need to diagnose the problem.
Never expose stack traces, file paths, version banners, or database errors to anonymous users or the public internet.
Restrict detailed errors to defined roles — decide who is allowed to see them, and enforce it.
Turn off verbose or debug output in production; leave it on only in a controlled test environment.

Framework mapping

How to move it toward Implemented

Hide server version banners: set ServerTokens Prod and ServerSignature Off in Apache, or server_tokens off; in Nginx, then reload the service.
Stop applications from printing errors to visitors — in /etc/php/*/php.ini set display_errors = Off and log_errors = On so detail goes to a log, not the page.
Serve a generic error page to users and send the real detail to a log file only admins can read (for example chmod 640, owner root:adm, under /var/log).
Write down which role may view detailed errors, then confirm the public site shows only the safe message.
Attach the config diff and a screenshot of the sanitized error page as hardening evidence on the asset, naming SI-11 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.