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 helps to assess the following ASVS requirements that can be tested with static analysis software, helps you quickly locate related issues in your application, and provides detailed information on how to fix the risks.

Supported OWASP ASVS 3.0 Requirements

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

Stay current
about our latest features