Breaking: RIPS is acquired by SonarSource
Joining forces in building best-in-class SAST products


Security Verification Standard

The Open Web Application Security Project (OWASP) is an international non-profit community focused on practical information about web application security. The Application Security Verifcation Standard (ASVS) provides a checklist of application security requirements that helps developing, maintaining, and testing application security. The ASVS requirements are categorized into three application security verification levels that depend on the sensitivity and trust level of the application. The more sensitive data an application processes, the more requirements of an higher ASVS level are mandatory.

RIPS is able to support the detection of all OWASP Top 10 risks that can be detected by static analysis software, helps you quickly locate them in your application, and provides detailed information on how to fix the risks.

Number ASVS Requirement RIPS
V3. Session management
3.1 Verify the resistance against common session management attacks.
3.4 Verify that sessions timeout after an absolute timeout.
3.6 Verify that the session id is never disclosed in URLs.
3.12 Verify that session ids stored in cookies have their path set to an restrictive value.
Verify that authentication session tokens set the "HttpOnly" and "secure" attributes.
V4. Access control
4.1 Verify access to functions, data files, and other resources.
4.4 Verify that access to sensitive records is protected.
4.5 Verify that directory browsing is disabled.
4.13 Verify that the application or framework uses strong random anti-CSRF token.
V5. Malicious input handling
5.1 Verify that the runtime environment is not susceptible to buffer overflows.
5.10 Verify that all SQL queries are protected against SQL injection.
5.11 Verify that the application is not susceptible to LDAP injection.
5.12 Verify that the application is not susceptible to OS command injection.
5.13 Verify that the application is not susceptible to remote or local file inclusion.
5.14 Verify that the application is not susceptible to XML, Xpath, or XXE injection.
5.15 Ensure that the application is not susceptible to XSS attacks.
5.16 Verify that automatic mass parameter assignment is protected.
5.17 Verify that the application has defenses against HTTP parameter pollution attacks.
V7. Cryptography at rest
7.7 Verify that cryptographic algorithms used have been validated against FIPS 140.
7.8 Verify that cryptographic modules operate in their approved mode.
7.15 Verify that random numbers are created with proper entropy.
V8. Error handling and logging
8.1 Verify that the application does not output error messages or stack traces.
8.6 Verify that security logs are protected from unauthorized modification.
8.8 Verify that log entries are not susceptible to log injection.
V9. Data protection
9.5 Verify that all copies of sensitive data are protected from unauthorized access.
V10. Communications
10.3 Verify that TLS is used for all connections.
10.5 Verify that certificate paths are built and verified for all client certificates.
10.11 Verify that HTTP Strict Transport Security headers are included for all subdomains.
V11. HTTP security configuration
11.4 Verify that a suitable X-FRAME-OPTIONS header is in use.
11.7 Verify that a secure Content Security Policy (CSP) is in place.
11.8 Verify that the X-XSS-Protection: 1; mode=block header is in place.
V13. Malicious controls
13.2 Verify that the application source code does not contain back doors.
V16. File and resources
16.1 Verify that URL redirects and forwards only allow whitelisted destinations.
16.2 Verify that untrusted file data is not used directly with file I/O commands.
16.4 Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities.
16.5 Verify that untrusted data is not used within cross-domain resource sharing (CORS).
V19. Configuration
19.1 All components should be up to date with proper security configuration(s).
19.2 Communications between components should be encrypted.