Fluid Attacks logo
Contact Us
Young hacker smiling
Zero false positives

Expert intelligence + effective automation

Contact logo Contact Us

REQ.173 Discard unsafe inputs

This document contains the details of the security requirements related to the definition and management of source code in the organization. This requirement establishes the importance of validating the application inputs and discarding harmful information to avoid common injection attacks.


System must discard all potentially harmful information obtained via data inputs.


Technological devices and in particular applications must be able to identify the received information that does not correspond to its operational purposes, in order to treat it properly (for example, rejecting and/or generating timely alerts) and that does not impact negatively the operation. Typical examples of this are: SQL queries, JavaScript code, OS commands or LDAP queries in fields and application parameters; text with undesired special characters and their possible combinations in fields and parameters; files manipulated in structure and extension to be loaded in an application or technology artifact, and in general any type of information that does not correspond to the requested format. A large amount of incoming traffic to a technological artifact must also be considered (which does not correspond to operational purposes) and controls and proper treatment must be performed.


  1. Perform whitelisting instead of blacklisting: By using this principle, the control implementation will be configured to reject all inputs that are not explicitly approved discarding all possible scenarios and forcing enumeration of strictly allowed inputs. e.g. allow only a-z, A-Z y 0-9.

  2. Use variable highlight: If supported, language and compiler can detect foreign variables that are not validated by a filter. To this end, you may use techniques to highlight those variables and compilers or pre-processors to detect that they are not validated.

  3. No only user validation but also input validation: Any input from outside the application must be considered as malicious, meaning, user can enter incorrect information as well as potentially harmful that may also compromise external systems, therefore this information must be validated.


  1. Inject malicious software or code.

  2. Denial of service caused by register overload.

  3. Cross-Site Scripting (XSS).

  4. OS command injection.

  5. SQL injection.

  6. LDAP injection.

  7. Redirect to untrusted pages.


  • Layer: Application Layer

  • Asset: Source code

  • Scope: Matureness

  • Phase: Building

  • Type of Control: Recommendation


  1. A1 Injection OWASP - Top 10 2013

  2. A3 Cross-site Scripting (XSS) OWASP - TOP 10 2013.

  3. A10 Unvalidated Redirects and Forwards OWASP - TOP 10 2013.

  4. CWE-20: Improper Input Validation.

  5. CWE-74: Injection.

  6. CWE-78: OS Command Injection.

  7. CWE-79: Cross-site Scripting.

  8. CWE-80: Basic XSS.

  9. CWE-89: SQL Injection.

  10. Taint checking - Wikipedia.

  11. OWASP-ASVS v3.1-5.10 Verify that all database queries are protected by the use of parameterized queries or proper ORM usage to avoid SQL injection.

  12. OWASP-ASVS v3.1-5.11 Verify that the application is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection.

  13. OWASP-ASVS v3.1-5.12 Verify that the application is not susceptible to OS Command Injection, or that security controls prevent OS Command Injection.

  14. OWASP-ASVS v3.1-5.13 Verify that the application is not susceptible to Remote File Inclusion (RFI) or Local File Inclusion (LFI) when content is used that is a path to a file.

  15. OWASP-ASVS v3.1-5.14 Verify that the application is not susceptible to XPath injection or XML injection attacks.

  16. OWASP-ASVS v3.1-5.15 Verify that all string variables placed into HTML or other web client code are either properly contextually encoded manually, or utilize templates that automatically contextually encode to ensure the application is not susceptible to reflected, stored or DOM Cross-Site Scripting (XSS) attacks.

  17. OWASP-ASVS v3.1-5.17 Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, environment, etc.)

  18. OWASP-ASVS v3.1-5.19 Verify that all input data is validated, not only HTML form fields but all sources of input such as REST calls, query parameters, HTTP headers, cookies, batch files, RSS feeds, etc; using positive validation (whitelisting), then lesser forms of validation such as grey listing (eliminating known bad strings), or rejecting bad inputs (blacklisting).

  19. OWASP-ASVS v3.1-5.20 Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as validating suburbs and zip or post codes match).

  20. OWASP-ASVS v3.1-5.21 Verify that unstructured data is sanitized to enforce generic safety measures such as allowed characters and length, and characters potentially harmful in given context should be escaped (e.g. natural names with Unicode or apostrophes, such as ねこ or O’Hara).

  21. OWASP-ASVS v3.1-5.22 Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature.

Service status - Terms of Use