SI-11: Error Handling

Quick-reference card

What this control requires

SI-11 requires organizations to generate error messages that help users take corrective action without exposing information an attacker could exploit. You need to design systems so that when something goes wrong, the message reveals enough to fix the problem and nothing more.

The control has two core obligations. First, every error message your systems produce must strike a balance between being useful and being safe. Stack traces, database query details, internal file paths, and implementation-specific data all fall outside the boundary of what’s acceptable to display. Second, you must restrict who can see detailed error messages to specific personnel or roles defined in your organization’s policy. A generic user should never encounter the same diagnostic output that a system administrator receives.

This requirement exists because error messages are one of the most overlooked attack surfaces in production environments. Verbose error output gives adversaries a map of your system’s internals, from technology stack and software versions to database schemas and authentication logic. By enforcing structured, role-appropriate error handling, NIST SP 800-53 ensures that the feedback loop between system failures and corrective action doesn’t become a feedback loop between system failures and exploitation.

Why it matters

Poor error handling is a known enabler of information disclosure, a vulnerability class that consistently appears in the OWASP Top 10. When systems expose implementation details through error messages, they lower the cost of reconnaissance for any threat actor probing your environment. The risk isn’t theoretical; it’s structural.

Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. For organizations pursuing or maintaining a FedRAMP authorization, an Authority to Operate (ATO), or any NIST SP 800-53-aligned assessment, an auditor who discovers verbose stack traces or unmasked credentials in error output has clear grounds for a finding. That finding can delay authorization timelines by months and trigger remediation cycles that consume significant engineering resources.

Beyond compliance, uncontrolled error output creates operational risk that compounds over time. Passwords mistakenly entered in username fields get logged in cleartext. Personally identifiable information (PII) such as account numbers or Social Security numbers surfaces in application error pages. Error messages can even function as covert channels, transmitting data to unauthorized parties through the structure or content of the output itself.

The technical exposure goes further than most teams realize. Detailed error messages can reveal session tokens, API keys, or internal IP addresses that enable lateral movement across systems. Without a deliberate error handling strategy, every unhandled exception becomes a potential intelligence source for attackers.

What attackers exploit

Threat actors actively probe error handling weaknesses to gather intelligence before launching deeper attacks. The most common vectors include the following.

• Verbose stack traces that reveal framework versions, library dependencies, and code paths, enabling targeted exploit selection
• Database error messages that expose query structure, table names, and schema details, making SQL injection attacks more precise
• Authentication error differences that allow username enumeration when login failures return distinct messages for invalid users versus invalid passwords
• Unmasked PII in error output that surfaces account numbers, credit card numbers, or Social Security numbers when input validation fails
• Internal path disclosure that maps server directory structures, configuration file locations, and deployment architecture through file-not-found errors

How to implement

The most common failure mode with SI-11 isn’t a lack of error handling. It’s inconsistency. Organizations implement custom error pages for their web applications but overlook API endpoints, batch processes, middleware layers, and legacy systems that still dump raw exceptions to end users.

For your organization

Start by inventorying every system component that generates user-facing error output. This includes web applications, APIs, command-line tools, batch jobs, and any integration endpoints. Most organizations discover that their web frontends have custom error pages while backend services and APIs still return raw exceptions.

Define a standard error message taxonomy for your environment. Create a mapping between internal error codes and the external messages users see. Internal logs should capture the full diagnostic detail, including stack traces, variable states, and request context. External-facing messages should contain only a reference code, a human-readable description of the problem, and guidance on next steps. Secure coding standards should mandate this separation at the framework level, not leave it to individual developers.

Configure role-based access to detailed error information. System administrators and developers may need diagnostic output for troubleshooting, but that output should live in centralized logging systems with appropriate access controls, not in user-facing responses. Define which roles can access verbose error logs and document those decisions in your system security plan.

Test your error handling under adversarial conditions. Submit malformed inputs, trigger authentication failures, force database timeouts, and send oversized payloads. Review every error response for information leakage. Automated security scanners can catch some of this exposure, but manual review of edge cases is essential.

Produce the evidence your auditors will need. Maintain documented operating procedures for error handling that cover message taxonomy, role restrictions, review cadence, and exception handling for legacy systems. Keep configuration artifacts that show custom error pages are active and verbose output is suppressed in production.

Common mistakes include forgetting to suppress debug mode in production deployments, leaving default framework error pages active, and failing to sanitize error messages from third-party libraries and middleware that your application wraps.

For your vendors

When assessing vendor compliance with SI-11, focus on whether the vendor has a deliberate error handling strategy or just default framework behavior.

Start your assessment with targeted questionnaire questions. Ask vendors to describe their error message taxonomy and how they separate internal diagnostic information from user-facing output. Request their policy on which personnel roles can access detailed error logs. Ask whether they conduct periodic testing for information disclosure in error responses, and how often.

Request specific evidence artifacts. You should receive a copy of their error handling procedures, a sample of their standardized error message templates, and configuration documentation showing that debug modes and verbose error output are disabled in production environments. If the vendor has completed secure authentication assessments, request those results as well, since authentication error handling is a frequent weak point.

Watch for red flags during your review. Generic responses like “we follow industry best practices” without supporting documentation indicate a lack of formal error handling controls. If a vendor can’t produce error handling procedures or demonstrate that they test for information leakage, that’s a material gap. Similarly, if their public-facing applications return stack traces, framework version numbers, or database error details during normal error conditions, their SI-11 posture is deficient.

Verify vendor claims by testing their production endpoints with common error-triggering inputs, where your agreement permits. Check login pages for username enumeration through different error messages for valid versus invalid accounts. Submit malformed API requests and review the error responses for internal details. Cross-reference what you observe against the documentation they provided.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for SI-11.

Related controls

• AU-02 — Event Logging: defines which events, including error conditions, must be logged, providing the audit trail that complements restricted error output
• AU-03 — Content of Audit Records: specifies what information audit records must capture, ensuring detailed diagnostic data lands in logs rather than in user-facing error messages
• SC-31 — Covert Channel Analysis: addresses the risk that error messages could function as covert channels for transmitting data to unauthorized parties
• SI-02 — Flaw Remediation: covers the patching and remediation process that addresses the underlying software defects error handling is designed to contain
• SI-15 — Information Output Filtering: governs the validation and filtering of system output, complementing the error-specific restrictions in SI-11

Frequently asked questions

What is NIST SP 800-53 SI-11?

SI-11 is a NIST SP 800-53 control that requires organizations to produce error messages providing corrective guidance without revealing exploitable details such as stack traces, database schemas, or implementation specifics. The control falls within the System and Information Integrity family and applies to systems at the moderate and high baselines. It also mandates that detailed error information be restricted to authorized personnel or roles, ensuring that diagnostic output isn’t accessible to general users. Organizations must address both the content of error messages and the audience who can see them.

What happens if SI-11 is not implemented?

Without SI-11, your systems will generate error messages that expose internal architecture details, creating a reconnaissance advantage for attackers. Auditors evaluating your environment against NIST SP 800-53 will flag uncontrolled error output as a finding, which can delay authorization decisions or trigger remediation requirements. The risk extends beyond audit findings. Unmasked error output can reveal PII such as account numbers or Social Security numbers, and error messages themselves can serve as covert channels for unauthorized data transmission. Failing to implement this control also weakens your posture on related requirements like event logging and information output filtering.

How do you audit SI-11?

Auditing SI-11 starts with reviewing your system error handling procedures and verifying that a documented error message taxonomy exists separating internal diagnostics from user-facing output. Auditors will examine system configuration settings to confirm that debug modes are disabled and custom error pages are active in production. They’ll also test system behavior by triggering common error conditions and inspecting the responses for information leakage, including stack traces, internal paths, and database details. Finally, auditors verify that role-based restrictions limit who can access detailed error logs, checking access control documentation and system audit records for evidence of enforcement.

What information should error messages not reveal?

Error messages should never expose stack traces, internal file paths, database query structures, software version numbers, or implementation-specific technical details that map your system’s architecture. The NIST supplemental guidance explicitly calls out passwords mistakenly entered as usernames, PII such as Social Security numbers and credit card numbers, and mission or business information that can be inferred from error output. Error messages should also avoid providing distinct responses for different failure conditions when that distinction leaks sensitive context, such as returning different messages for invalid usernames versus invalid passwords. The goal is to give authorized users enough information for corrective action while denying adversaries any intelligence about your system’s internals.