#

1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
1.1.7
1.2.1
1.2.2
1.2.3
1.2.4
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.5.1

1.5.2

1.5.3
1.5.4
1.6.1
1.6.2
1.6.3

1.6.4

1.7.1
1.7.2
1.8.1
1.8.2
1.9.1
1.9.2

1.10.1

1.11.1
1.11.2
1.11.3
1.12.1

1.12.2

1.14.1
1.14.2
1.14.3
1.14.4

1.14.5
1.14.6

2.2.1

2.2.2

2.2.3

2.2.4
2.2.5
2.2.6
2.2.7

2.3.1

2.3.2
2.3.3

2.4.1

2.4.2
2.4.3
2.4.4

2.4.5

2.5.1
2.5.2
2.5.3
2.5.4
2.5.5
2.5.6
2.5.7
2.6.1
2.6.2
2.6.3
2.7.1
2.7.2
2.7.3
2.7.4
2.7.5
2.7.6
2.8.1
2.8.2
2.8.3
2.8.4
2.8.5
2.8.6
2.8.7
2.9.1
2.9.2
2.9.3
2.10.1
2.10.2
2.10.3

2.10.4

3.1.1
3.2.1
3.2.2
3.2.3
3.2.4
3.3.1

3.3.2

3.3.3
3.3.4
3.4.1
3.4.2
3.4.3
3.4.4

3.4.5

3.5.1
3.5.2
3.5.3
3.6.1
3.6.2
3.7.1
4.1.1
4.1.2

4.1.3

4.1.4
4.1.5
4.2.1
4.2.2
4.3.1
4.3.2

4.3.3

5.1.1
5.1.2
5.1.3

5.1.4

5.1.5
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8

5.3.1

5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
5.3.8
5.3.9
5.3.10
5.4.1
5.4.2
5.4.3
5.5.1
5.5.2
5.5.3
5.5.4
6.1.1
6.1.2
6.1.3
6.2.1
6.2.2
6.2.3
6.2.4

6.2.5

6.2.6
6.2.7
6.2.8

6.3.1

6.3.2
6.3.3
6.4.1
6.4.2
7.1.1
7.1.2
7.1.3
7.1.4
7.2.1
7.2.2
7.3.1
7.3.2
7.3.3
7.3.4
7.4.1
7.4.2
7.4.3
8.1.1
8.1.2
8.1.3
8.1.4
8.1.5
8.1.6
8.2.1
8.2.2
8.2.3
8.3.1
8.3.2
8.3.3
8.3.4
8.3.5
8.3.6
8.3.7
8.3.8
9.1.1
9.1.2
9.1.3

9.2.1

9.2.2

9.2.3
9.2.4
9.2.5
10.1.1
10.2.1
10.2.2

10.2.3

10.2.4
10.2.5
10.2.6
10.3.1

10.3.2

10.3.3

11.1.1
11.1.2
11.1.3
11.1.4
11.1.5
11.1.6
11.1.7
11.1.8
12.1.1
12.1.2
12.1.3
12.2.1
12.3.1
12.3.2
12.3.3

12.3.4

12.3.5
12.3.6
12.4.1
12.4.2

12.5.1

12.5.2
12.6.1
13.1.1
13.1.2
13.1.3
13.1.4
13.1.5
13.2.1
13.2.2

13.2.3

13.2.4
13.2.5

13.2.6

13.3.1
13.3.2

13.4.1
13.4.2
14.1.1

14.1.2

14.1.3
14.1.4
14.1.5
14.2.1
14.2.2
14.2.3
14.2.4
14.2.5
14.2.6
14.3.1
14.3.2
14.3.3
14.4.1
14.4.2
14.4.3
14.4.4
14.4.5
14.4.6
14.4.7
14.5.1
14.5.2
14.5.3
14.5.4
Description
Verify the use of a secure software development lifecycle that addresses security in all stages of development. (C1)
Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appro
Verify that all user stories and features contain functional security constraints, such as "As a user, I should be able to view and edit my pro
Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.
Verify definition and security analysis of the application's high-level architecture and all connected remote services. (C1)
Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missin
Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.
Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. (C3)
Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Component
Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong au
Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such
Verify that trusted enforcement points such as at access control gateways, servers, and serverless functions enforce access controls. Never
Verify that the chosen access control solution is flexible enough to meet the application's needs.
Verify enforcement of the principle of least privilege in functions, data files, URLs, controllers, services, and other resources. This implies p
Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests mu
Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rath
Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regu

Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity contr

Verify that input validation is enforced on a trusted service layer. (C5)

Verify that output encoding occurs close to or by the interpreter for which it is intended. (C4)
Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key manageme
Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.
Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.
Verify that symmetric keys, passwords, or API secrets generated by or shared with clients are used only in protecting low risk secrets, such
equivalent and architecturally should be treated as such.
Verify that a common logging format and approach is used across the system. (C9)
Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. (C9)
Verify that all sensitive data is identified and classified into protection levels.
Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirement
Verify the application encrypts communications between components, particularly when these components are in different containers, sy
Verify that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. F

Verify that a source code control system is in use, with procedures to ensure that check-ins are accompanied by issues or change tickets. T

Verify the definition and documentation of all application components in terms of the business or security functions they provide.
Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchroni
Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resista
Verify that user-uploaded files are stored outside of the web root.
Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downlo
risk from XSS vectors or other attacks from the uploaded file.
Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse p
Verify that if deploying binaries to untrusted devices makes use of binary signatures, trusted connections, and verified endpoints.
Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.
Verify that the build pipeline contains a build step to automatically build and verify the secure deployment of the application, particularly i

Verify that application deployments adequately sandbox, containerize and/or isolate at the network level to delay and deter attackers from
Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave

Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such
between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the

Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as
aware of the risks, or that proper measures are in place to limit the risks of account compromise.
Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address change
absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification.
Verify impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as
Verify that where a credential service provider (CSP) and the application verifying authentication are separated, mutually authenticated TL
Verify replay resistance through the mandated use of OTP devices, cryptographic authenticators, or lookup codes.
Verify intent to authenticate by requiring the entry of an OTP token or user-initiated action such as a button press on a FIDO hardware key
Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters lo
become the long term password.
Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens.
Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.

Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved on

Verify that the salt is at least 32 bits in length and be chosen arbitrarily to minimize salt value collisions among stored hashes. For each cre
Verify that if PBKDF2 is used, the iteration count SHOULD be as large as verification server performance will allow, typically at least 100,00
Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, typically at least 13. (C6)
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.
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 spec
Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. (C6)
Verify password hints or knowledge-based authentication (so-called "secret questions") are not present.
Verify password credential recovery does not reveal the current password in any way. (C6)
Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").
Verify that if an authentication factor is changed or replaced, that the user is notified of this event.
Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as TOTP or other soft token, mobile push, or
Verify that if OTP or multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during
Verify that lookup secrets can be used only once.
Verify that lookup secrets have sufficient randomness (112 bits of entropy), or if less than 112 bits of entropy, salted with a unique and ran
Verify that lookup secrets are resistant to offline attacks, such as predictable values.
Verify that clear text out of band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternati
Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.
Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication
Verify that the out of band authenticator and verifier communicates over a secure independent channel.
Verify that the out of band verifier retains only a hashed version of the authentication code.
Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typica
Verify that time-based OTPs have a defined lifetime before expiring.
Verify that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure ope
Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
Verify that time-based OTP can be used only once within the validity period.
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 be
Verify physical single factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective ac
Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and somet
Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a TPM or HSM, or an
Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.
Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts.
Verify that if passwords are required, the credentials are not a default account.
Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.
Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and
secure software key store (L1), hardware trusted platform module (TPM), or a hardware security module (L3) is recommended for passwo
Verify the application never reveals session tokens in URL parameters or error messages.
Verify the application generates a new session token on user authentication. (C6)
Verify that session tokens possess at least 64 bits of entropy. (C6)
Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3
Verify that session token are generated using approved cryptographic algorithms. (C6)
Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume a

If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle

Verify that the application terminates all other active sessions after a successful password change, and that this is effective across the appl
Verify that users are able to view and log out of any or all currently active sessions and devices.
Verify that cookie-based session tokens have the 'Secure' attribute set. (C6)
Verify that cookie-based session tokens have the 'HttpOnly' attribute set. (C6)
Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. (C6)
Verify that cookie-based session tokens use "__Host-" prefix (see references) to provide session cookie confidentiality.

Verify that if the application is published under a domain name with other applications that set or use session cookies that might override

Verify the application does not treat OAuth and refresh tokens — on their own — as the presence of the subscriber and allows users to ter
Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.
Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, envelopin
Verify that relying parties specify the maximum authentication time to CSPs and that CSPs re-authenticate the subscriber if they haven't us
Verify that CSPs inform relying parties of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.
Verify the application ensures a valid login session or requires re-authentication or secondary verification before allowing any sensitive tra
Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and cou
Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifica

Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and o

Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not rec
Verify that access controls fail securely including when an exception occurs. (C10)
Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records
Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-
Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.
Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of

Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregati

Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no disti
Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect agains
Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using

Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g.

Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted co
Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework fea
Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.
Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input
Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandbo
Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames
Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content, especially as they relate to XSS resulting
Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Mar

Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically
Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely
Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM base
Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are o
Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injectio
Verify that the application projects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, CSP b
Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have b
Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use co
Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.
Verify that the application protects against XPath injection or XML injection attacks. (C4)
Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap
Verify that format strings do not take potentially hostile input, and are constant.
Verify that sign, range, and input validation techniques are used to prevent integer overflows.
Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. (C5)
Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe
Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML an
Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval
Verify that regulated private data is stored encrypted while at rest, such as personally identifiable information (PII), sensitive personal info
Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized rese
Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay
Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.
Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cry
Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.
Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or s

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-DE

Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The
Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered b
Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avo
Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's a
attacker.
Verify that random GUIDs are created using the GUID v4 algorithm, and a cryptographically-secure pseudo-random number generator (CS
Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degra
Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. (C8)
Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operati
Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hash
Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. (C9)
Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deser
Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happ
Verify that all authentication decisions are logged, without storing sensitive session identifiers or passwords. This should include requests
Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metada
Verify that the application appropriately encodes user-supplied data to prevent log injection. (C9)
Verify that all events are protected from injection when viewed in log viewing software. (C9)
Verify that security logs are protected from unauthorized access and modification. (C9)
Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to
Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support p
Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error cond
Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. (C10)
Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.
Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalid
Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.
Verify the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes
Verify that regular backups of important data are performed and that test restoration of data is performed.
Verify that backups are stored securely to prevent data from being stolen or corrupted.
Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.
Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) do
Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.
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
Verify that users have a method to remove or export their data on demand.
Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided o
Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to de
Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection d
Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attac
Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both con
Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatica
Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. (C8)
Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algori
Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and T

Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used,

Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, mo
server must not fall back to insecure or unencrypted protocols.
Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.
Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.
Verify that backend TLS connection failures are logged.
Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and netw
Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. W
Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, c
Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumente
otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered.
Verify that the application source code and third party libraries does not contain time bombs by searching for date and time related functi
Verify that the application source code and third party libraries does not contain malicious code, such as salami attacks, logic bypasses, or
Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality
Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally sign

Verify that the application employs integrity protections, such as code signing or sub-resource integrity. The application must not load or e
Internet.
Verify that the application has protection from sub-domain takeovers if the application relies upon DNS entries or DNS sub-domains, such
APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS
Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.
Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not
Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.
Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic reque
Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modell
Verify the application does not suffer from "time of check to time of use" (TOCTOU) issues or other race conditions for sensitive operation
Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions
Verify the application has configurable alerting when automated attacks or unusual activity is detected.
Verify that the application will not accept large files that could fill up storage or cause a denial of service attack.
Verify that compressed files are checked for "zip bombs" - small input files that will decompress into huge files thus exhausting file storage
Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with to
Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.
Verify that user-submitted filename metadata is not used directly with system or framework file and URL API to protect against path trave
Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files
Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files (RFI), which ma
Verify that the application protects against reflective file download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSO
have a fixed filename.
Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.
Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution netw
Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validati
Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content.
Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code
extensions commonly used by editors should be blocked unless required.
Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.
Verify that the web or application server is configured with a whitelist of resources or systems to which the server can send requests or loa
Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing
Verify that access to administration and management functions is limited to authorized administrators.
Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.
Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router,
Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Una
Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT o
Verify that JSON schema validation is in place and verified before accepting input.

Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of th

Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated.
Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/JSON.
Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS on
provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity a
Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field befor
Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.
Verify that query whitelisting or a combination of depth limiting and amount limiting should be used to prevent GraphQL or data layer exp
used.
Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer
Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, au
Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, d
found.
Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.
Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a docu
Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.
Verify that all components are up to date, preferably using a dependency checker during build or compile time. (C2)
Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documenta
Verify that if application assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted externally on a content delivery netw
Verify that third party components come from pre-defined, trusted and continually maintained repositories. (C2)
Verify that an inventory catalog is maintained of all third party libraries in use. (C2)
Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into th
Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to el
Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, dev
Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).
Verify that all API responses contain Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content
Verify that a content security policy (CSPv2) is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript inje
Verify that all responses contain X-Content-Type-Options: nosniff.
Verify that HTTP Strict Transport Security headers are included on all responses and for all subdomains, such as Strict-Transport-Security: m
Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin".
Verify that a suitable X-Frame-Options or Content-Security-Policy: frame-ancestors header is in use for sites where content should not be e
Verify that the application server only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS.
Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed
Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header uses a strict white-list of trusted domains to mat
Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.

All information in this file was taken directly from the OWASP ASVS 4.0 document in the link below and is not original content attributed to
SOURCE: https://www.owasp.org/images/8/88/OWASP_Application_Security_Verification_Standard_4.0-en.docx
License information can be found here: https://creativecommons.org/licenses/by-sa/3.0/
L1 L2 L3 CWE
✓ ✓
✓ ✓ 1053
✓ ✓ 1110
✓ ✓ 1059
✓ ✓ 1059
✓ ✓ 637
✓ ✓ 637
✓ ✓ 250
✓ ✓ 306
✓ ✓ 306
✓ ✓ 306
✓ ✓ 602
✓ ✓ 284
✓ ✓ 272
✓ ✓ 284
✓ ✓ 275
✓ ✓ 1029

✓ ✓ 502

✓ ✓ 602
✓ ✓ 116
✓ ✓ 320
✓ ✓ 320
✓ ✓ 320

✓ ✓ 320

✓ ✓ 1009
✓ ✓
✓ ✓
✓ ✓
✓ ✓ 319
✓ ✓ 295

✓ ✓ 284

✓ ✓ 1059
✓ ✓ 362
✓ 367
✓ ✓ 552

✓ ✓ 646

✓ ✓ 923
✓ ✓ 494
✓ ✓ 1104
✓ ✓

✓ ✓ 265
 ✓ ✓ 477

✓ ✓ ✓ 307

✓ ✓ ✓ 304

✓ ✓ ✓ 620

✓ 308
✓ 319
✓ 308
✓ 308

✓ ✓ ✓ 330

✓ ✓ 308
✓ ✓ 287

✓ ✓ 916

✓ ✓ 916
✓ ✓ 916
✓ ✓ 916

✓ ✓ 916

✓ ✓ ✓ 640
✓ ✓ ✓ 640
✓ ✓ ✓ 640
✓ ✓ ✓ 16
✓ ✓ ✓ 304
✓ ✓ ✓ 640
✓ ✓ 308
✓ ✓ 308
✓ ✓ 330
✓ ✓ 310
✓ ✓ ✓ 287
✓ ✓ ✓ 287
✓ ✓ ✓ 287
✓ ✓ ✓ 523
✓ ✓ 256
✓ ✓ 310
✓ ✓ ✓ 613
✓ ✓ 320
✓ ✓ 326
✓ ✓ 287
✓ ✓ 287
✓ ✓ 613
o ✓ 308
✓ ✓ 320
 ✓ ✓ 330
✓ ✓ 327
OS assisted HSM 287
OS assisted HSM 255
OS assisted HSM 522

OS assisted HSM 798

✓ ✓ ✓ 598
✓ ✓ ✓ 384
✓ ✓ ✓ 331
✓ ✓ ✓ 539
✓ ✓ 331
✓ ✓ ✓ 613
12 hours or 30 minutes of inactivity, 2FA 12 hours or 15 minutes of inactivity,
30 days optional with 2FA 613

✓ ✓ 613
✓ ✓ 613
✓ ✓ ✓ 614
✓ ✓ ✓ 1004
✓ ✓ ✓ 16
✓ ✓ ✓ 16

✓ ✓ ✓ 16

✓ ✓ 290
✓ ✓ 798
✓ ✓ 345
✓ 613
✓ 613
✓ ✓ ✓ 778
✓ ✓ ✓ 602
✓ ✓ ✓ 639

✓ ✓ ✓ 285

✓ ✓ ✓ 276
✓ ✓ ✓ 285
✓ ✓ ✓ 639
✓ ✓ ✓ 352
✓ ✓ ✓ 419
✓ ✓ ✓ 548

✓ ✓ 732

✓ ✓ ✓ 235
✓ ✓ ✓ 915
✓ ✓ ✓ 20

✓ ✓ ✓ 20

✓ ✓ ✓ 601
✓ ✓ ✓ 116
✓ ✓ ✓ 138
✓ ✓ ✓ 147
✓ ✓ ✓ 95
✓ ✓ ✓ 94
✓ ✓ ✓ 918
✓ ✓ ✓ 159
✓ ✓ ✓ 94

✓ ✓ ✓ 116

✓ ✓ ✓ 176
✓ ✓ ✓ 79
✓ ✓ ✓ 89
✓ ✓ ✓ 89
✓ ✓ ✓ 830
✓ ✓ ✓ 943
✓ ✓ ✓ 78
✓ ✓ ✓ 829
✓ ✓ ✓ 643
✓ ✓ 120
✓ ✓ 134
✓ ✓ 190
✓ ✓ ✓ 502
✓ ✓ ✓ 611
✓ ✓ ✓ 502
✓ ✓ ✓ 95
✓ ✓ 311
✓ ✓ 311
✓ ✓ 311
✓ ✓ ✓ 310
✓ ✓ 327
✓ ✓ 326
✓ ✓ 326

✓ ✓ 326

✓ ✓ 326
✓ 326
✓ 385

✓ ✓ 338

✓ ✓ 338
✓ 338
✓ ✓ 798
✓ ✓ 320
✓ ✓ ✓ 532
✓ ✓ ✓ 532
 ✓ ✓ 778
✓ ✓ 778
✓ ✓ 778
✓ ✓ 285
✓ ✓ 117
✓ ✓ 117
✓ ✓ 200
✓ ✓
✓ ✓ ✓ 210
✓ ✓ 544
✓ ✓ 460
✓ ✓ 524
✓ ✓ 524
✓ ✓ 233
✓ ✓ 770
✓ 19
✓ 19
✓ ✓ ✓ 525
✓ ✓ ✓ 922
✓ ✓ ✓ 922
✓ ✓ ✓ 319
✓ ✓ ✓ 212
✓ ✓ ✓ 285
✓ ✓ ✓ 200
✓ ✓ 532
✓ ✓ 226
✓ ✓ 327
✓ ✓ 285
✓ ✓ ✓ 319
✓ ✓ ✓ 326
✓ ✓ ✓ 326

✓ ✓ 295

✓ ✓ 319

✓ ✓ 287
✓ ✓ 299
✓ 544
✓ 749
✓ ✓ 359
✓ ✓ 272

✓ 507

✓ 511
✓ 511
✓ 507
✓ ✓ ✓ 16

✓ ✓ ✓ 353

✓ ✓ ✓ 350

✓ ✓ ✓ 841
✓ ✓ ✓ 779
✓ ✓ ✓ 770
✓ ✓ ✓ 770
✓ ✓ ✓ 841
✓ ✓ 367
✓ ✓ 754
✓ ✓ 390
✓ ✓ ✓ 400
✓ ✓ 409
✓ ✓ 770
✓ ✓ 434
✓ ✓ ✓ 22
✓ ✓ ✓ 73
✓ ✓ ✓ 98

✓ ✓ ✓ 641

✓ ✓ ✓ 78
✓ ✓ 829
✓ ✓ ✓ 922
✓ ✓ ✓ 509

✓ ✓ ✓ 552

✓ ✓ ✓ 434
✓ ✓ ✓ 918
✓ ✓ ✓ 116
✓ ✓ ✓ 419
✓ ✓ ✓ 598
✓ ✓ 285
✓ ✓ 434
✓ ✓ ✓ 650
✓ ✓ ✓ 20

✓ ✓ ✓ 352

✓ ✓ 779
✓ ✓ 436

✓ ✓ 345

✓ ✓ ✓ 20
✓ ✓ 345

✓ ✓ 770
 ✓ ✓ 285
✓ ✓

✓ ✓ 120

✓ ✓ 16
✓ ✓
✓
✓ ✓ ✓ 1026
✓ ✓ ✓ 1002
✓ ✓ ✓ 714
✓ ✓ 829
✓ ✓
✓ ✓ 265
✓ ✓ ✓ 209
✓ ✓ ✓ 497
✓ ✓ ✓ 200
✓ ✓ ✓ 173
✓ ✓ ✓ 116
✓ ✓ ✓ 1021
✓ ✓ ✓ 116
✓ ✓ ✓ 523
✓ ✓ ✓ 116
✓ ✓ ✓ 346
✓ ✓ ✓ 749
✓ ✓ ✓ 346
✓ ✓ ✓ 346
✓ ✓ 306
119 255 274
NIST §
5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2

5.2.10

5.2.5
5.2.6
5.2.8
5.2.9

5.1.1.2 / A.3

6.1.3
6.1.4

5.1.1.2

5.1.1.2
5.1.1.2
5.1.1.2

5.1.1.2

5.1.1.2
5.1.1.2
5.1.1.2
5.1.1.2 / A.3
6.1.2.3
5.1.1.2
6.1.2.3
5.1.2.2
5.1.2.2
5.1.2.2
5.1.3.2
5.1.3.2
5.1.3.2
5.1.3.2
5.1.3.2
5.1.3.2
5.1.4.2 / 5.1.5.2
5.1.4.2 / 5.1.5.2
5.1.4.2 / 5.1.5.2
5.1.4.2 / 5.1.5.2
5.1.5.2
5.2.1
5.2.3
5.1.7.2
5.1.7.2
5.1.7.2
5.1.1.1
5.1.1.1
5.1.1.1

7.1
7.1
7.1
7.1
7.1

7.2

7.1
7.1.1
7.1.1
7.1.1
7.1.1

7.1.1

7.1.2

7.2.1
7.2.1