Quick-reference card
| Field | Detail |
|---|---|
| Control ID | SI-15 |
| Control name | Information Output Filtering |
| Framework | NIST SP 800-53 Revision 5 |
| Control family | System and Information Integrity |
| Baselines | — |
| Relevance | System (First Party and Third Party) |
| Risk severity | Medium |
What this control requires
SI-15 requires organizations to validate that software and application output contains only expected content before reaching users or downstream systems. This control targets a gap most teams overlook: while input validation gets the lion’s share of security attention, unfiltered output is where injection attacks, data leakage, and unexpected system behavior surface in production.
In practice, you need mechanisms that inspect outbound data from applications, detect extraneous or anomalous content, suppress that content before it renders, and alert your monitoring tools when something unexpected appears. The classic example is a web application vulnerable to SQL injection returning raw database error messages or records that were never meant to be displayed. Output filtering catches what input validation misses.
The scope here is broad. Any application that generates dynamic output, whether that’s a customer-facing web portal, an API endpoint, or an internal reporting tool, falls under SI-15. You’re expected to define what “normal” output looks like for each application, build validation logic that enforces those expectations, and create alerting workflows that flag deviations so your security operations team can investigate.
Why it matters
Most organizations invest heavily in input validation and perimeter defenses but treat output as a trusted channel. That assumption creates a blind spot. When application output isn’t filtered, attackers can exploit it to extract sensitive data, inject malicious content into downstream systems, or manipulate what legitimate users see.
Failure to implement output filtering introduces audit risk and may result in certification withdrawal or regulatory findings. Assessors evaluating your System and Information Integrity controls will look for evidence that output validation rules exist, that they’re actively enforced, and that anomalous output triggers alerts. A gap here doesn’t just weaken your security posture; it signals to auditors that your organization hasn’t addressed a known class of vulnerabilities.
The compliance exposure extends beyond audit findings. Organizations that can’t demonstrate output filtering controls may face challenges during Federal Information Security Modernization Act (FISMA) reviews, Federal Risk and Authorization Management Program (FedRAMP) assessments, or any authorization process that references the NIST SP 800-53 framework. Without documented procedures and supporting evidence, you’re left defending an incomplete control implementation.
What attackers exploit
Output filtering gaps create several attack vectors that threat actors actively target:
- SQL injection output disclosure exposes raw database content, error messages, or schema details when applications fail to validate query results before rendering them to users
- Cross-site scripting (XSS) through unescaped output allows attackers to inject malicious scripts into web pages viewed by other users, because the application didn’t sanitize or encode outbound HTML content
- Verbose error messages leak stack traces, file paths, database connection strings, or software version numbers that give attackers reconnaissance data for follow-on attacks
- Data leakage through API responses occurs when applications return more fields or records than the requesting user is authorized to see, often because output isn’t filtered against access control policies
- Log injection and log forging lets attackers insert crafted content into application logs, potentially misleading security analysts or triggering false automated responses
How to implement
The biggest implementation challenge with SI-15 isn’t building the filters themselves. It’s identifying every output channel that needs coverage and keeping validation rules current as applications change.
For your organization
Start by inventorying every application and system component that produces dynamic output. This inventory should capture the output type (HTML, JSON, XML, plain text), the intended audience (internal users, external customers, other systems), and the expected content structure. You can’t filter output if you haven’t defined what legitimate output looks like.
Build output validation rules for each application. These rules should specify the expected data types, field lengths, character sets, and structural patterns for every output channel. For web applications, this means implementing output encoding and escaping routines that neutralize any injected content before it reaches the browser. Context-aware output encoding is the recognized best practice here: HTML entity encoding for content rendered in HTML body, JavaScript escaping for content embedded in scripts, and URL encoding for content placed in URLs.
Deploy web application firewalls (WAFs) and application-layer monitoring as enforcement points. WAFs can inspect outbound responses for anomalous patterns like embedded SQL syntax, script tags, or unexpected error codes. Configure your WAF to block or sanitize suspicious output and generate alerts for your security operations center (SOC) to investigate.
Integrate output filtering alerts with your attack surface management and monitoring infrastructure. Your security information and event management (SIEM) system should correlate output anomalies with other indicators, such as unusual request patterns or authentication failures, to identify active exploitation attempts.
Common mistakes include treating output filtering as a one-time configuration rather than an ongoing process, failing to update validation rules when application code changes, and relying solely on input validation without a corresponding output check. Document your output filtering procedures, maintain a record of validation rule changes, and schedule periodic reviews to verify that rules still align with current application behavior.
For your vendors
When evaluating third-party vendors, output filtering is a critical area to assess because you’re trusting their applications to handle your data without leaking it through unvalidated output channels.
Include these questions in your vendor security assessments:
- Do your applications implement output encoding and escaping for all dynamic content rendered to users?
- What output validation rules are in place to prevent SQL injection, XSS, and data leakage through application responses?
- How do you monitor application output for anomalous or unexpected content?
- Can you provide documentation of your information output filtering procedures and the most recent review date?
- Are output filtering controls tested during your penetration testing and code review cycles?
Request specific evidence from vendors, including their system and information integrity policy, output filtering procedures, recent penetration test results showing output validation coverage, and WAF configuration documentation. A vendor risk management program that includes output filtering in its assessment criteria helps you identify gaps before they become your organization’s problem.
Red flags to watch for include vendors who can’t distinguish between input validation and output filtering, vendors whose penetration test reports don’t cover output-related vulnerabilities, and vendors who lack documented procedures for updating output validation rules. If a vendor treats output filtering as “handled by input validation,” that’s a gap. The two controls address different stages of the data flow and aren’t interchangeable.
Evidence examples
| Evidence type | Example artifact |
|---|---|
| Policy documentation | System and information integrity policy defining output filtering requirements, roles, and review cadence |
| Output filtering procedures | Documented procedures specifying output validation rules, encoding standards, and anomaly response workflows for each application |
| System design documentation | Architecture diagrams and data flow documents showing where output validation and encoding occur in the application stack |
| Configuration records | WAF rule sets, output encoding library configurations, and application framework settings that enforce output filtering |
| Audit and monitoring records | System audit logs showing output anomaly detection events, alert triggers, and investigation outcomes |
| Test results | Penetration test and code review reports covering output validation effectiveness, including XSS, SQL injection, and data leakage tests |
| Security plan | System security plan sections referencing SI-15 implementation details, scope of covered applications, and planned improvements |
Cross-framework mapping
No applicable cross-framework mappings for this control.
Related controls
- SI-03 — Malicious Code Protection: output filtering complements malicious code defenses by catching harmful content that bypasses signature-based detection and appears in application output rather than inbound payloads
- SI-04 — System Monitoring: monitoring tools consume the alerts that output filtering generates, creating the feedback loop needed to detect and respond to anomalous application behavior in real time
- SI-11 — Error Handling: error handling controls what information your applications reveal when something goes wrong, while output filtering validates that all outbound content, not just error messages, meets expected format and content rules
Frequently asked questions
What is NIST SP 800-53 SI-15
SI-15 is the NIST SP 800-53 control that requires organizations to validate information output from software programs and applications to confirm the content is consistent with expected results. It focuses on detecting and suppressing extraneous content in application output, then alerting monitoring tools to the anomaly. This control sits within the System and Information Integrity family and directly addresses risks like SQL injection output disclosure, cross-site scripting, and unintended data leakage through application responses.
What happens if SI-15 is not implemented
Without SI-15, your applications may display or transmit unexpected content to users and downstream systems, including sensitive data, error details, or injected malicious code. Assessors will flag the absence of information output filtering procedures as a control gap, which can result in a plan of action and milestones (POA&M) entry or a failed authorization decision. The lack of output validation rules also leaves your organization exposed to exploitation techniques that input validation alone can’t prevent.
How do you audit SI-15
Auditing SI-15 starts with verifying that documented output filtering procedures exist and that output validation rules are defined for each in-scope application. Assessors examine system design documentation to confirm that output encoding and filtering are implemented at the correct points in the application architecture. They also review system audit records for evidence that anomalous output events trigger alerts and that those alerts are investigated, establishing that the control is operational and not just documented.
What is the difference between input validation and output filtering
Input validation checks data coming into an application to reject malformed or malicious requests before processing, while output filtering validates data leaving an application to ensure only expected content reaches users or downstream systems. Both controls are necessary because input validation can’t catch every attack payload, especially in complex applications where data transforms between input and output. SI-15 specifically addresses the output side, complementing input validation controls like SI-10 to create defense in depth across the full data flow.