Quick-reference card
| Field | Value |
|---|---|
| Control ID | SI-10 |
| Control name | Information Input Validation |
| Framework | NIST SP 800-53 Revision 5 |
| Control family | System and Information Integrity |
| Baselines | MODERATE, HIGH |
| Relevance | System (First Party and Third Party) |
| Risk severity | Critical |
What this control requires
SI-10 requires organizations to validate all information inputs against defined rules for format, length, character set, and acceptable values before processing. Without input validation, applications accept whatever data an attacker sends, turning user-facing fields into attack vectors for injection, overflow, and data corruption.
In practice, this control means every system component that accepts external input must enforce checks against a defined specification. Those checks cover syntax (is the input well-formed?), semantics (does the value make sense in context?), and boundary conditions (does a numeric field fall within its allowed range?). The System and Information Integrity family groups SI-10 alongside controls that protect the accuracy and trustworthiness of data flowing through your environment.
The requirement extends beyond web forms. Structured messages between software modules, application programming interface (API) payloads, database queries, and file uploads all qualify as information inputs. Wherever attacker-supplied data can be interpreted as commands or metadata, validation must occur before the input reaches an interpreter or processing engine.
Why it matters
Most organizations treat input validation as a developer responsibility and leave it out of their compliance and risk management conversations entirely. That gap is where breaches happen. SQL injection, cross-site scripting (XSS), and command injection remain among the most exploited vulnerability classes year after year, and every one of them traces back to the same root cause. The system trusted user-supplied data without checking it first.
The consequences extend well beyond technical compromise. Regulators treat missing input validation as a failure of basic due diligence, and enforcement actions have made that position clear. When an attacker can extract hundreds of thousands of customer records using freely available automated tools, the resulting investigation rarely focuses on the sophistication of the attack. It focuses on why the organization didn’t implement controls that have been standard practice for over a decade.
TalkTalk website SQL injection
In October 2015, a group of attackers used SQLMap, an automated SQL injection tool, against three pages on the TalkTalk website that the company had inherited from its 2009 acquisition of ISP Tiscali. Those pages had never been patched or decommissioned. The underlying database software was affected by a known vulnerability for which a patch had been available for more than three and a half years. The attackers, the youngest of whom were teenagers aged 15 to 20, extracted data on 156,959 TalkTalk customers, including 15,656 sets of bank account and sort code details and partial data from 28,000 credit and debit cards.
The ICO investigation concluded that TalkTalk had “failed to apply the most basic cyber security measures.” The regulator issued a £400,000 fine, a record under the Data Protection Act 1998 at the time. CEO Dido Harding appeared on television the same day as the breach and admitted she could not confirm whether the stolen data was encrypted. The case reached parliamentary hearings not because the attack was technically sophisticated, but because automated tooling in the hands of teenagers was sufficient to extract hundreds of thousands of customer records from a major telecommunications provider. Inherited web pages had not been subjected to input validation review in more than three years of operation.
What attackers exploit
- SQL injection: Malicious SQL statements inserted through unvalidated form fields or URL parameters, allowing attackers to read, modify, or delete database contents
- Cross-site scripting (XSS): Script injection through input fields that aren’t checked for executable content, enabling session hijacking and credential theft
- Command injection: Operating system commands embedded in input data that bypass validation and execute on the host server
- Buffer overflow: Oversized inputs that exceed allocated memory boundaries, potentially allowing arbitrary code execution
- Path traversal: Directory navigation characters in file name inputs that let attackers access files outside the intended scope
How to implement
The most common failure mode for SI-10 isn’t the absence of input validation. It’s inconsistency. Organizations validate inputs on their primary web application but overlook inherited systems, internal APIs, batch processing pipelines, and legacy integrations that were never brought under the same controls.
For your organization
Start by building an inventory of every system component that accepts external input. Include web forms, API endpoints, file upload handlers, database query interfaces, and any integration point that receives data from users, partners, or other systems. This inventory becomes your scope for SI-10 implementation.
Define validation rules for each input field based on its expected data type, length, character set, numerical range, and business logic constraints. A name field should reject special characters used in SQL queries. A date field should accept only valid calendar dates within a defined range. A quantity field should enforce minimum and maximum boundaries. Document these rules so they’re testable and auditable.
Implement validation at multiple layers. Client-side validation improves user experience but provides no security. Server-side validation at the application layer is the minimum requirement. Database-level constraints provide a final safety net. Defense in depth matters here because attackers bypass client-side controls routinely.
Use parameterized queries or prepared statements for all database interactions. This technique separates data from commands structurally, making SQL injection impossible regardless of what an attacker submits. Secure coding practices should mandate parameterized queries as the default for all new development.
Implement output encoding alongside input validation. Even validated inputs should be encoded before rendering in HTML, JavaScript, or other contexts where data could be interpreted as executable content. Review the OWASP Top 10 for current injection attack categories and corresponding mitigations.
Establish a regular review cycle for inherited and legacy systems. The TalkTalk breach demonstrated that acquired systems often fall outside an organization’s standard security controls. Every acquisition, merger, or system migration should trigger an input validation review of all inherited components. Address the most common OWASP vulnerabilities as a remediation priority.
For your vendors
Assess whether your vendors validate information inputs across their customer-facing and internal systems. Request evidence that input validation is implemented at the application layer, not just the client side, and that validation rules are defined for each input type the system processes.
Ask vendors to provide documentation of their input validation standards, including which frameworks or coding standards they follow (for example, OWASP Application Security Verification Standard). Request results from recent application security testing, specifically static analysis (SAST) and dynamic analysis (DAST) scans that cover injection vulnerabilities.
Evaluate whether the vendor maintains an inventory of all input points across their application stack. Vendors who can’t enumerate their input surfaces are unlikely to validate them consistently. This gap is a red flag for SI-10 compliance.
Request evidence of secure development lifecycle (SDL) practices that include input validation requirements at the design phase, not just code review. Vendors should demonstrate that developers receive training on injection prevention techniques and that code reviews specifically check for missing validation.
Review the vendor’s patch management process for third-party components and inherited code. Ask how quickly they apply security patches to frameworks, libraries, and database engines. A vendor that takes months to patch known vulnerabilities in their input processing stack presents the same risk profile that led to the TalkTalk breach.
Evidence examples
| Evidence type | Example artifact |
|---|---|
| Input validation policy and procedures | System and information integrity policy defining input validation requirements, approved validation methods, and review cadence for all system input points |
| Input validation specifications | Documentation listing each information input field, its expected format, character set, length constraints, numerical range, and acceptable values |
| Automated validation tooling | Configuration records for web application firewalls (WAFs), SAST/DAST tools, and runtime application self-protection (RASP) systems that verify input validity |
| Secure coding standards | Development guidelines requiring parameterized queries, output encoding, and input validation at the application layer for all system components |
| Application security test results | SAST and DAST scan reports showing injection vulnerability coverage, findings, and remediation status across the application inventory |
| System audit records | Log entries capturing rejected or sanitized inputs, validation failures, and alerts triggered by malformed data submissions |
Cross-framework mapping
No cross-framework mappings are currently configured for SI-10.
Related controls
No related controls are referenced in the NIST SP 800-53 catalog for SI-10.
Frequently asked questions
What is NIST SP 800-53 SI-10?
SI-10 is the NIST SP 800-53 control that requires organizations to check the validity of all information inputs to their systems before processing. It applies to MODERATE and HIGH baselines and mandates that every input field is verified against defined rules for format, character set, length, numerical range, and acceptable values. Organizations must maintain documentation listing which inputs require validity checks and the specific validation criteria applied to each.
What happens if SI-10 is not implemented?
Failing to implement SI-10 exposes systems to injection attacks, including SQL injection, cross-site scripting, and command injection, where attackers embed malicious code in unvalidated input fields. Regulators treat missing input validation as a failure of basic due diligence, as demonstrated by enforcement actions like the ICO’s record fine against TalkTalk. Organizations also face data exfiltration risks when automated tools can exploit unvalidated database query inputs to extract customer records at scale.
How do you audit SI-10?
Auditing SI-10 starts with verifying that the organization maintains a current list of information inputs requiring validity checks, mapped to specific validation criteria for each field. Assessors review automated tools and applications configured to verify input validity, along with system audit records showing how the system handles rejected or malformed inputs. Dynamic application security testing against production systems confirms that validation rules are enforced in practice, not just documented in policy.
What is the difference between input validation and input sanitization?
Input validation checks whether submitted data conforms to a predefined specification for format, length, type, and acceptable values, rejecting inputs that don’t match. Input sanitization modifies or encodes data to neutralize potentially dangerous characters before the input reaches an interpreter. Effective SI-10 implementation uses both techniques together, with validation as the primary defense and sanitization as an additional layer for output encoding and context-specific escaping.