Overview
CASA consists of 134 requirements that span across all assurance levels of the OWASP's Application Security Verification Standard (ASVS). All requirements must be satisfied for every tier, the only difference between each tier is the assessment method that applies.
Definition of Terms
-
Identifier: Each requirement has an identifier in the format <chapter>.<section>.<requirement> where each element is a number, for example: 1.11.3.
-
Chapter: The chapter the requirement belongs to, there are 14 chapters.
-
Section: Each chapter is divided into sections. There are 43 total sections.
-
Req Description: The description of the requirement, this explains what check to be conducted for the specific requirement.
-
Web: Whether the requirement is relevant to a web application, cloud application, server application or hybrid.
-
Local: Whether the requirement is relevant to an application that does not store any data outside of the client (mobile, PC..etc)
-
Infrastructure: Whether this requirement is relevant to the application or the application backend communication.
-
CWE: The common weakness enumeration unique identifier
-
CWE Ranking: The common weakness enumeration vulnerability rank (high, medium, low)
Requirements List
Identifier | Chapter | Section | Req Description | Web | Local | Infrastructure | CWE | CWE Ranking |
---|---|---|---|---|---|---|---|---|
V1.2.2 | Architecture, Design and Threat Modeling | Authentication Architecture | Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 306 | High |
V1.2.3 | Architecture, Design and Threat Modeling | Authentication Architecture | Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches. | Yes | Yes | No | 306 | High |
V1.4.1 | Architecture, Design and Threat Modeling | Access Control Architecture | Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client. | No | No | Yes | 602 | Medium |
V1.4.4 | Architecture, Design and Threat Modeling | Access Control Architecture | Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 284 | High |
V1.5.2 | Architecture, Design and Threat Modeling | Input and Output Architecture | Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection. | No | No | Yes | 502 | Medium |
V1.5.3 | Architecture, Design and Threat Modeling | Input and Output Architecture | Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 602 | Medium |
V1.5.4 | Architecture, Design and Threat Modeling | Input and Output Architecture | Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 116 | High |
V1.8.1 | Architecture, Design and Threat Modeling | Data Protection and Privacy Architecture | Verify that all sensitive data is identified and classified into protection levels. | No | No | Yes | ||
V1.8.2 | Architecture, Design and Threat Modeling | Data Protection and Privacy Architecture | Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture. | No | No | Yes | ||
V1.9.1 | Architecture, Design and Threat Modeling | Communications Architecture | Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 319 | High |
V1.11.3 | Architecture, Design and Threat Modeling | Business Logic Architecture | Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions. | No | No | Yes | 367 | Medium |
V1.14.1 | Architecture, Design and Threat Modeling | Configuration Architecture | Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms. | No | No | Yes | 923 | Medium |
V1.14.2 | Architecture, Design and Threat Modeling | Configuration Architecture | Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices. | No | No | Yes | 494 | Medium |
V1.14.3 | Architecture, Design and Threat Modeling | Configuration Architecture | Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions. | No | No | Yes | 1104 | Low |
V1.14.4 | Architecture, Design and Threat Modeling | Configuration Architecture | Verify that the build pipeline contains a build step to automatically build and verify the secure deployment of the application, particularly if the application infrastructure is software defined, such as cloud environment build scripts. | No | No | Yes | ||
V1.14.5 | Architecture, Design and Threat Modeling | Configuration Architecture | Verify that application deployments adequately sandbox, containerize and/or isolate at the network level to delay and deter attackers from attacking other applications, especially when they are performing sensitive or dangerous actions such as deserialization. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 265 | Low |
V1.14.6 | Architecture, Design and Threat Modeling | Configuration Architecture | Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. | Yes | Yes | No | 477 | Medium |
V2.2.1 | Authentication | General Authenticator Security | Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account. | No | No | Yes | 307 | Medium |
V2.2.4 | Authentication | General Authenticator Security | Verify impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as connected keys with a push to authenticate), or at higher AAL levels, client-side certificates. | No | No | Yes | 308 | High |
V2.2.5 | Authentication | General Authenticator Security | Verify that where a Credential Service Provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints. | No | No | Yes | 319 | High |
V2.3.1 | Authentication | Authenticator Lifecycle | Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long term password. | No | No | Yes | 330 | High |
V2.4.1 | Authentication | Credential Storage | Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 916 | Low |
V2.4.3 | Authentication | Credential Storage | Verify that if PBKDF2 is used, the iteration count SHOULD be as large as verification server performance will allow, typically at least 100,000 iterations. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 916 | Low |
V2.4.5 | Authentication | Credential Storage | Verify that an additional iteration of a key derivation function is performed, using a salt value that is secret and known only to the verifier. Generate the salt value using an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A. The secret salt value SHALL be stored separately from the hashed passwords (e.g., in a specialized device like a hardware security module). | No | No | Yes | 916 | Low |
V2.6.1 | Authentication | Look-up Secret Verifier | Verify that lookup secrets can be used only once. | No | No | Yes | 308 | High |
V2.7.2 | Authentication | Out of Band Verifier | Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes. | No | No | Yes | 287 | High |
V2.7.3 | Authentication | Out of Band Verifier | Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request. | No | No | Yes | 287 | High |
V2.7.4 | Authentication | Out of Band Verifier | Verify that the out of band authenticator and verifier communicates over a secure independent channel. | No | No | Yes | 523 | Medium |
V2.7.5 | Authentication | Out of Band Verifier | Verify that the out of band verifier retains only a hashed version of the authentication code. | No | No | Yes | 256 | High |
V2.7.6 | Authentication | Out of Band Verifier | Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient). | No | No | Yes | 310 | High |
V2.8.2 | Authentication | One Time Verifier | Verify that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure operating system based key storage. | No | No | Yes | 320 | High |
V2.8.5 | Authentication | One Time Verifier | Verify that if a time-based multi-factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device. | No | No | Yes | 287 | High |
V2.8.6 | Authentication | One Time Verifier | Verify physical single-factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location. | No | No | Yes | 613 | Medium |
V2.9.1 | Authentication | Cryptographic Verifier | Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a Trusted Platform Module (TPM) or Hardware Security Module (HSM), or an OS service that can use this secure storage. | No | No | Yes | 320 | High |
V2.9.3 | Authentication | Cryptographic Verifier | Verify that approved cryptographic algorithms are used in the generation, seeding, and verification. | No | No | Yes | 327 | High |
V2.10.1 | Authentication | Service Authentication | Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access. | No | No | Yes | 287 | High |
V2.10.2 | Authentication | Service Authentication | Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation). | No | No | Yes | 255 | Low |
V2.10.3 | Authentication | Service Authentication | Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access. | No | No | Yes | 522 | Medium |
V2.10.4 | Authentication | Service Authentication | Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage. | No | No | Yes | 798 | High |
V3.2.3 | Session Management | Session Binding | Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage. | Yes | Yes | No | 539 | Medium |
V3.3.1 | Session Management | Session Termination | Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 613 | Medium |
V3.3.3 | Session Management | Session Termination | Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties. | Yes | Yes | No | 613 | Medium |
V3.3.4 | Session Management | Session Termination | Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices. | No | No | Yes | 613 | Medium |
V3.4.1 | Session Management | Cookie-based Session Management | Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 614 | Medium |
V3.4.2 | Session Management | Cookie-based Session Management | Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 1004 | Medium |
V3.4.3 | Session Management | Cookie-based Session Management | Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 1275 | Medium |
V3.5.1 | Session Management | Token-based Session Management | Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications. | Yes | Yes | No | 290 | Medium |
V3.5.2 | Session Management | Token-based Session Management | Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations. | No | No | Yes | 798 | High |
V3.5.3 | Session Management | Token-based Session Management | Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks. | Yes | Yes | No | 345 | Medium |
V3.7.1 | Session Management | Defenses Against Session Management Exploits | Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications. | Yes | Yes | No | 306 | High |
V4.1.1 | Access Control | General Access Control Design | Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed. | No | No | Yes | 602 | Medium |
V4.1.2 | Access Control | General Access Control Design | Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized. | No | No | Yes | 639 | High |
V4.1.3 | Access Control | General Access Control Design | Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 285 | High |
V4.1.5 | Access Control | General Access Control Design | Verify that access controls fail securely including when an exception occurs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 285 | High |
V4.2.2 | Access Control | Operation Level Access Control | Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality. | Yes | Yes | No | 352 | High |
V4.3.1 | Access Control | Other Access Control Considerations | Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use. | Yes | Yes | No | 419 | Medium |
V4.3.2 | Access Control | Other Access Control Considerations | Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders. | No | No | Yes | 548 | Medium |
V4.3.3 | Access Control | Other Access Control Considerations | Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud. | Yes | Yes | No | 732 | High |
V5.1.1 | Validation, Sanitization and Encoding | Input Validation | 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, or environment variables). | Yes | Yes | No | 235 | Medium |
V5.1.2 | Validation, Sanitization and Encoding | Input Validation | Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 915 | Medium |
V5.1.3 | Validation, Sanitization and Encoding | Input Validation | Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 20 | High |
V5.1.4 | Validation, Sanitization and Encoding | Input Validation | Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 20 | High |
V5.1.5 | Validation, Sanitization and Encoding | Input Validation | Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content. | No | No | Yes | 601 | Low |
V5.2.3 | Validation, Sanitization and Encoding | Sanitization and Sandboxing | Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | Yes | Yes | No | 147 | Medium |
V5.2.4 | Validation, Sanitization and Encoding | Sanitization and Sandboxing | Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. | Yes | Yes | No | 95 | Medium |
V5.2.5 | Validation, Sanitization and Encoding | Sanitization and Sandboxing | Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed. | Yes | Yes | No | 94 | Medium |
V5.2.6 | Validation, Sanitization and Encoding | Sanitization and Sandboxing | Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports. | Yes | Yes | No | 918 | Medium |
V5.2.7 | Validation, Sanitization and Encoding | Sanitization and Sandboxing | Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject. | Yes | Yes | No | 159 | Medium |
V5.3.1 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 116 | High |
V5.3.2 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 176 | Medium |
V5.3.3 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 79 | High |
V5.3.4 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 89 | High |
V5.3.6 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 830 | Medium |
V5.3.7 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 90 | Medium |
V5.3.8 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 78 | High |
V5.3.9 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks. | Yes | Yes | No | 829 | Medium |
V5.3.10 | Validation, Sanitization and Encoding | Output Encoding and Injection Prevention | Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 643 | High |
V5.5.1 | Validation, Sanitization and Encoding | Deserialization Prevention | Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 502 | Medium |
V5.5.2 | Validation, Sanitization and Encoding | Deserialization Prevention | Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. | Yes | Yes | No | 611 | Medium |
V6.1.1 | Stored Cryptography | Data Classification | Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR. | No | No | Yes | 311 | High |
V6.1.2 | Stored Cryptography | Data Classification | Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records. | No | No | Yes | 311 | High |
V6.1.3 | Stored Cryptography | Data Classification | Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records. | No | No | Yes | 311 | High |
V6.2.1 | Stored Cryptography | Algorithms | Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks. | No | No | Yes | 310 | High |
V6.2.2 | Stored Cryptography | Algorithms | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 327 | High |
V6.2.3 | Stored Cryptography | Algorithms | Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice. | No | No | Yes | 326 | Medium |
V6.2.4 | Stored Cryptography | Algorithms | Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 326 | Medium |
V6.2.5 | Stored Cryptography | Algorithms | Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility. | No | No | Yes | 326 | Medium |
V6.2.6 | Stored Cryptography | Algorithms | Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used. | No | No | Yes | 326 | Medium |
V6.2.7 | Stored Cryptography | Algorithms | Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party. | No | No | Yes | 326 | Medium |
V6.2.8 | Stored Cryptography | Algorithms | Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. | No | No | Yes | 385 | Medium |
V6.3.1 | Stored Cryptography | Random Values | Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker. | No | No | Yes | 338 | Medium |
V6.3.2 | Stored Cryptography | Random Values | Verify that random GUIDs are created using the GUID v4 algorithm, and a Cryptographically-secure Pseudo-random Number Generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable. | No | No | Yes | 338 | Medium |
V6.3.3 | Stored Cryptography | Random Values | Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances. | Yes | Yes | No | 338 | Medium |
V6.4.2 | Stored Cryptography | Secret Management | Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 320 | High |
V7.1.1 | Error Handling and Logging | Log Content | Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 532 | Medium |
V7.1.2 | Error Handling and Logging | Log Content | Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 532 | Medium |
V7.1.3 | Error Handling and Logging | Log Content | Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 778 | Medium |
V7.3.1 | Error Handling and Logging | Log Protection | Verify that all logging components appropriately encode data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | Yes | Yes | No | 117 | Medium |
V7.3.3 | Error Handling and Logging | Log Protection | Verify that security logs are protected from unauthorized access and modification. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 200 | High |
V8.1.1 | Data Protection | General Data Protection | Verify the application protects sensitive data from being cached in server components such as load balancers and application caches. | Yes | Yes | No | 524 | Medium |
V8.1.3 | Data Protection | General Data Protection | Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values. | Yes | Yes | No | 233 | Medium |
V8.1.6 | Data Protection | General Data Protection | Verify that backups are stored securely to prevent data from being stolen or corrupted. | No | No | Yes | 19 | High |
V8.2.1 | Data Protection | Client-side Data Protection | Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers. | Yes | Yes | No | 525 | Medium |
V8.2.2 | Data Protection | Client-side Data Protection | Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data. | Yes | Yes | No | 922 | Medium |
V8.3.1 | Data Protection | Sensitive Private Data | Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data. | No | No | Yes | 319 | High |
V8.3.2 | Data Protection | Sensitive Private Data | Verify that users have a method to remove or export their data on demand. | No | No | Yes | 212 | Medium |
V8.3.3 | Data Protection | Sensitive Private Data | Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way. | No | No | Yes | 285 | High |
V8.3.5 | Data Protection | Sensitive Private Data | Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required. | Yes | Yes | Yes | 532 | Medium |
V8.3.6 | Data Protection | Sensitive Private Data | Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data. | No | No | Yes | 226 | Medium |
V8.3.8 | Data Protection | Sensitive Private Data | Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires. | No | No | Yes | 285 | High |
V9.1.2 | Communication | Client Communication Security | Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred. | No | No | Yes | 326 | Medium |
V9.1.3 | Communication | Client Communication Security | Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option. | No | No | Yes | 326 | Medium |
V9.2.1 | Communication | Server Communication Security | Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected. | No | No | Yes | 295 | Medium |
V9.2.4 | Communication | Server Communication Security | Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | No | No | Yes | 299 | Medium |
V9.2.5 | Communication | Server Communication Security | Verify that backend TLS connection failures are logged. | No | No | Yes | 544 | Medium |
V10.1.1 | Malicious Code | Code Integrity | Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections. | No | No | Yes | 749 | Low |
V10.2.3 | Malicious Code | Malicious Code Search | Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered. | Yes | Yes | No | 507 | Medium |
V10.2.4 | Malicious Code | Malicious Code Search | Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions. | Yes | Yes | No | 511 | Medium |
V10.2.5 | Malicious Code | Malicious Code Search | Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs. | Yes | Yes | No | 511 | Medium |
V10.3.2 | Malicious Code | Application Integrity | Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet. | Yes | Yes | No | 353 | Medium |
V10.3.3 | Malicious Code | Application Integrity | Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (*autogen-bucket-id*.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change. | Yes | Yes | No | 350 | Medium |
V11.1.4 | Business Logic | Business Logic Security | Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks. | Yes | Yes | No | 770 | High |
V12.4.1 | Files and Resources | File Storage | Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions. | Yes | No | No | 552 | Medium |
V12.4.2 | Files and Resources | File Storage | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content. | Yes | No | No | 509 | Medium |
V13.1.1 | API and Web Service | Generic Web Service Security | Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks. | Yes | Yes | No | 116 | High |
V13.1.3 | API and Web Service | Generic Web Service Security | Verify API URLs do not expose sensitive information, such as the API key, session tokens etc. | Yes | No | No | 598 | Medium |
V13.1.4 | API and Web Service | Generic Web Service Security | Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions. | No | No | Yes | 285 | High |
V13.2.1 | API and Web Service | RESTful Web Service | Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources. | Yes | No | No | 650 | High |
V14.1.1 | Configuration | Build and Deploy | Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts. | Yes | Yes | No | ||
V14.1.4 | Configuration | Build and Deploy | Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion. | Yes | Yes | No | ||
V14.1.5 | Configuration | Build and Deploy | Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering. | No | No | Yes | ||
V14.2.1 | Configuration | Dependency | Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | No | No | Yes | 1026 | Medium |
V14.3.2 | Configuration | Unintended Security Disclosure | Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures. | Yes | Yes | Yes | 497 | Medium |
V14.5.2 | Configuration | HTTP Request Header Validation | Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker. | No | No | Yes | 346 | Medium |