About the Standard

The Application Security Verification Standard is a list of application secu

developers, testers, security professionals, tool vendors, and consumers

Copyright and License

Copyright © 2008-2019 The OWASP Foundation. This document is releas
license](https://creativecommons.org/licenses/by-sa/3.0/). For any reuse
terms of this work. Version 4.0.1, March 2019

Project Leads
Andrew van der Stock - Daniel Cuthbert - Jim Manico - Josh C Grossman -

Contributors and Reviewers

Osama Elnaggar - Erlend Oftedal - Serg Belkommen - David Johansson - T
Benedikt Bauer - Elar Lang - ScriptingXSS - Philippe De Ryck - Grog's Axle
Anthony Weems - bschach - javixeneize - Dan Cornell - hello7s - Lewis Ard
Talargoni - Ståle Pettersen - Kelby Ludwig - Jason Morrow - Rogan Dawes

The Application Security Verification Standard is built upon the shoulders

Much of the structure and verification items that are still in the ASVS tod
and Dave Wichers, but there are many more contributors. Thank you to a
those who have contributed to earlier versions, please consult each prior
please contact vanderaj@owasp.org or log a ticket at GitHub to be recog
 Application Security Verification

Standard
tion Security Verification Standard is a list of application security requirements or tes
testers, security professionals, tool vendors, and consumers to define, build, test and

nd License
© 2008-2019 The OWASP Foundation. This document is released under the [Creative C
ps://creativecommons.org/licenses/by-sa/3.0/). For any reuse or distribution, you mu
s work. Version 4.0.1, March 2019

ds
n der Stock - Daniel Cuthbert - Jim Manico - Josh C Grossman - Mark Burnett

rs and Reviewers
ggar - Erlend Oftedal - Serg Belkommen - David Johansson - Tonimir Kisasondi - Ron P
auer - Elar Lang - ScriptingXSS - Philippe De Ryck - Grog's Axle - Marco Schnüriger - Jac
eems - bschach - javixeneize - Dan Cornell - hello7s - Lewis Ardern - Jim Newman - Stu
Ståle Pettersen - Kelby Ludwig - Jason Morrow - Rogan Dawes - Daniël Geerts

tion Security Verification Standard is built upon the shoulders of those involved from
e structure and verification items that are still in the ASVS today were originally writte
Wichers, but there are many more contributors. Thank you to all those previously invo
have contributed to earlier versions, please consult each prior version. If a credit is m
act vanderaj@owasp.org or log a ticket at GitHub to be recognized in future 4.x upda
erification Standard 4.0.1

quirements or tests that can be used by architects,

ne, build, test and verify secure applications.

der the [Creative Commons Attribution ShareAlike 3.0

stribution, you must make clear to others the license

Burnett

Kisasondi - Ron Perris - Jason Axley - Abhay Bhargav -

o Schnüriger - Jacob Salassi - Glenn ten Cate -
Jim Newman - Stuart Gunter - Geoff Baskwill -
ël Geerts

ose involved from ASVS 1.0 in 2008 to 3.0 in 2016.

e originally written by Mike Boberski, Jeff Williams
e previously involved. For a comprehensive list of all
on. If a credit is missing from the 4.0 credit list above,
n future 4.x updates.
Section Name Item

V1 Architecture 1.1.1

V1 Architecture 1.1.2

V1 Architecture 1.1.3

V1 Architecture 1.1.4

V1 Architecture 1.1.5

V1 Architecture 1.1.6

V1 Architecture 1.1.7

V1 Architecture 1.10.1

V1 Architecture 1.11.1

V1 Architecture 1.11.2

V1 Architecture 1.11.3
V1 Architecture 1.12.1

V1 Architecture 1.12.2

V1 Architecture 1.14.1

V1 Architecture 1.14.2

V1 Architecture 1.14.3

V1 Architecture 1.14.4
V1 Architecture 1.14.5

V1 Architecture 1.14.6

V1 Architecture 1.2.1

V1 Architecture 1.2.2

V1 Architecture 1.2.3

V1 Architecture 1.5.1

V1 Architecture 1.5.2
V1 Architecture 1.5.3
V1 Architecture 1.5.4

V1 Architecture 1.6.1

V1 Architecture 1.6.2

V1 Architecture 1.6.3

V1 Architecture 1.6.4
V1 Architecture 1.7.1

V1 Architecture 1.7.2
V1 Architecture 1.8.1

V1 Architecture 1.8.2
V1 Architecture 1.9.1

V1 Architecture 1.9.2
Description
Verify the use of a secure software development lifecycle that addresses security in all stages of
development. )
Verify the use of threat modeling for every design change or sprint planning to identify threats, plan
for countermeasures, facilitate appropriate risk responses, and guide security testing.

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 profile. I should not be able to view or edit anyone else's profile"
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. )
Verify implementation of centralized, simple , vetted, secure, and reusable security controls to avoid
duplicate, missing, ineffective, or insecure controls. )
Verify availability of a secure coding checklist, security requirements, guideline, or policy to all
developers and testers.

Verify that a source code control system is in use, with procedures to ensure that check-ins are
accompanied by issues or change tickets. The source code control system should have access
control and identifiable users to allow traceability of any changes.
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 unsynchronized state.
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.
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 downloads, or from an unrelated domain, such as a cloud file storage
bucket. Implement a suitable content security policy to reduce the 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 proxies, cloud-based security groups, or similar mechanisms.
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 if the application infrastructure is software defined, such
as cloud environment build scripts.
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. )
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.
Verify the use of unique or special low-privilege operating system accounts for all application
components, services, and servers. )
Verify that communications between application components, including APIs, middleware and data
layers, are authenticated. Components should have the least necessary privileges needed. )

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.

Verify that input and output requirements clearly define how to handle and process data based on
type, content, and applicable laws, regulations, and other policy compliance.
Verify that serialization is not used when communicating with untrusted clients. If this is not
possible, ensure that adequate integrity controls are enforced to prevent deserialization attacks
including object injection.
Verify that input validation is enforced on a trusted service layer. )
Verify that output encoding occurs close to or by the interpreter for which it is intended. )
Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic
key lifecycle follows a key management standard such as NIST SP 800-57.
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 as encrypting local storage, or temporary ephemeral uses
such as parameter obfuscation. Sharing secrets with clients is clear-text equivalent and
architecturally should be treated as such.
Verify that a common logging format and approach is used across the system. )
Verify that logs are securely transmitted to a preferably remote system for analysis, detection,
alerting, and escalation. )
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 requirements, retention, privacy and other confidentiality
requirements, and that these are applied in the architecture.
Verify the application encrypts communications between components, particularly when these
components are in different containers, systems, sites, or cloud providers. )

Verify that application components verify the authenticity of each side in a communication link to
prevent person-in-the-middle attacks. For example, application components should validate TLS
certificates and chains.
L1 L2 L3 CWE NIST Tested Verdict

X X

X X 1053

X X 1110

X X 1059

X X 1059

X X 637

X X 637

X X 284

X X 1059

X X 362

X 367
X X 552

X X 646

X X 923

X X 494

X X 1104

X X
X X 265

X X 477

X X 250

X X 306

X X 306

X X 1029

X X 502
X X 602
X X 116

X X 320

X X 320

X X 320

X X 320
X X 1009

X X
X X

X X
X X 319

X X 295
Comment
Section Name Item
V2 Authentication 2.1.1
V2 Authentication 2.1.10

V2 Authentication 2.1.11

V2 Authentication 2.1.12
V2 Authentication 2.1.2

V2 Authentication 2.1.3

V2 Authentication 2.1.4
V2 Authentication 2.1.5
V2 Authentication 2.1.6

V2 Authentication 2.1.7
V2 Authentication 2.1.8

V2 Authentication 2.1.9

V2 Authentication 2.10.1
V2 Authentication 2.10.2

V2 Authentication 2.10.3

V2 Authentication 2.10.4

V2 Authentication 2.2.1
V2 Authentication 2.2.2

V2 Authentication 2.2.3

V2 Authentication 2.2.4

V2 Authentication 2.2.5

V2 Authentication 2.2.6

V2 Authentication 2.2.7

V2 Authentication 2.3.1

V2 Authentication 2.3.2

V2 Authentication 2.3.3

V2 Authentication 2.4.1

V2 Authentication 2.4.2

V2 Authentication 2.4.3

V2 Authentication 2.4.4
V2 Authentication 2.4.5

V2 Authentication 2.5.1

V2 Authentication 2.5.2
V2 Authentication 2.5.3
V2 Authentication 2.5.4

V2 Authentication 2.5.5

V2 Authentication 2.5.6

V2 Authentication 2.5.7
V2 Authentication 2.6.1

V2 Authentication 2.6.2
V2 Authentication 2.6.3

V2 Authentication 2.7.1

V2 Authentication 2.7.2

V2 Authentication 2.7.3

V2 Authentication 2.7.4
V2 Authentication 2.7.5

V2 Authentication 2.7.6
V2 Authentication 2.8.1

V2 Authentication 2.8.2

V2 Authentication 2.8.3
V2 Authentication 2.8.4
V2 Authentication 2.8.5

V2 Authentication 2.8.6

V2 Authentication 2.8.7

V2 Authentication 2.9.1

V2 Authentication 2.9.2

V2 Authentication 2.9.3
Description
Verify that user set passwords are at least 12 characters in length.
Verify that there are no periodic credential rotation or password history requirements.
Verify that "paste" functionality, browser password helpers, and external password managers are
permitted.
Verify that the user can choose to either temporarily view the entire masked password, or
temporarily view the last typed character of the password on platforms that do not have this as
native functionality.
Verify that passwords 64 characters or longer are permitted.
Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple
spaces MAY optionally be coalesced.
Verify that Unicode characters are permitted in passwords. A single Unicode code point is
considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.
Verify users can change their password.
Verify that password change functionality requires the user's current and new password.

Verify that passwords submitted during account registration, login, and password change are
checked against a set of breached passwords either locally or using an external API. If using an API a
zero knowledge proof or other mechanism should be used to ensure that the plain text password is
not sent or used in verifying the breach status of the password. If the password is breached, the
application must require the user to set a new non-breached password.
Verify that a password strength meter is provided to help users set a stronger password.
Verify that there are no password composition rules limiting the type of characters permitted. There
should be no requirement for upper or lower case or numbers or special characters.
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 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 trusted platform module (TPM, or a hardware security module (L3 is recommended
for password storage.

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.
Verify that the use of weak authenticators (such as SMS and email is limited to secondary
verification and transaction approval and not as a replacement for more secure authentication
methods. Verify that stronger methods are offered before weak methods, users are 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 changes, logging in from unknown or risky locations. The use of
push notifications - rather than SMS or email - is preferred, but in the 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 connected keys with a push to authenticate, or at higher
AAL levels, client-side certificates.

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

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 credential, a unique salt value and the resulting hash
SHALL be stored.
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.
Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance
will allow, typically at least 13.
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.
Verify that a system generated initial activation or recovery secret is not sent in clear text to the
user.
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.
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 another offline recovery mechanism.
Verify that if OTP or multi-factor authentication factors are lost, that evidence of identity proofing is
performed at the same level as during enrollment.
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 random 32-bit salt and hashed with an approved one-way hash.
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 alternatives such as push notifications are offered first.
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 request.
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 (typically a six digital random number is sufficient.
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 operating system based key storage.

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 being sent to the holder of the device.

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.
Verify that biometric authenticators are limited to use only as secondary factors in conjunction with
either something you have and something you know.
Verify that cryptographic keys used in verification are stored securely and protected against
disclosure, such as using a TPM or HSM, or an OS service that can use this secure storage.
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.
L1 L2 L3 CWE NIST Tested Verdict
X X X 521 5.1.1.2
X X X 263 5.1.1.2

X X X 521 5.1.1.2

X X X 521 5.1.1.2
X X X 521 5.1.1.2

X X X 521 5.1.1.2

X X X 521 5.1.1.2
X X X 620 5.1.1.2
X X X 620 5.1.1.2

X X X 521 5.1.1.2
X X X 521 5.1.1.2

X X X 521 5.1.1.2

OS assiste HSM 287 5.1.1.1

OS assiste HSM 255 5.1.1.1

OS assiste HSM 522 5.1.1.1

OS assiste HSM 798

X X X 307 5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2

X X X 304 5.2.10

X X X 620

X 308 5.2.5

X 319 5.2.6

X 308 5.2.8

X 308 5.2.9

X X X 330 5.1.1.2 / A.3

X X 308 6.1.3

X X 287 6.1.4

X X 916 5.1.1.2

X X 916 5.1.1.2

X X 916 5.1.1.2

X X 916 5.1.1.2
 X X 916 5.1.1.2

X X X 640 5.1.1.2

X X X 640 5.1.1.2
X X X 640 5.1.1.2
X X X 16 5.1.1.2 / A.3

X X X 304 6.1.2.3

X X X 640 5.1.1.2

X X 308 6.1.2.3
X X 308 5.1.2.2

X X 330 5.1.2.2
X X 310 5.1.2.2

X X X 287 5.1.3.2

X X X 287 5.1.3.2

X X X 287 5.1.3.2

X X X 523 5.1.3.2
X X 256 5.1.3.2

X X 310 5.1.3.2
X X X 613 5.1.4.2 / 5.1.5.2

X X 320 5.1.4.2 / 5.1.5.2

X X 326 5.1.4.2 / 5.1.5.2

X X 287 5.1.4.2 / 5.1.5.2
X X 287 5.1.5.2

X X 613 5.2.1

o X 308 5.2.3

X X 320 5.1.7.2

X X 330 5.1.7.2

X X 327 5.1.7.2
Comment
Section Name Item
V3 Session 3.1.1
V3 Session 3.2.1
V3 Session 3.2.2

V3 Session 3.2.3
V3 Session 3.2.4

V3 Session 3.3.1

V3 Session 3.3.2

V3 Session 3.3.3
V3 Session 3.3.4
V3 Session 3.4.1
V3 Session 3.4.2

V3 Session 3.4.3

V3 Session 3.4.4

V3 Session 3.4.5

V3 Session 3.5.1

V3 Session 3.5.2

V3 Session 3.5.3

V3 Session 3.6.1

V3 Session 3.6.2

V3 Session 3.7.1
Description
Verify the application never reveals session tokens in URL parameters or error messages.
Verify the application generates a new session token on user authentication.
Verify that session tokens possess at least 64 bits of entropy.
Verify the application only stores session tokens in the browser using secure methods such as
appropriately secured cookies or HTML 5 session storage.
Verify that session token are generated using approved cryptographic algorithms.

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.
If authenticators permit users to remain logged in, verify that re-authentication occurs periodically
both when actively used or after an idle period.
Verify that the application terminates all other active sessions after a successful password change,
and that this is effective across the application, federated login , and any relying parties.
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.
Verify that cookie-based session tokens have the 'HttpOnly' attribute set.
Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-
site request forgery attacks.
Verify that cookie-based session tokens use "__Host-" prefix 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 or disclose the session cookies, set the path attribute in
cookie-based session tokens using the most precise path possible.
Verify the application does not treat OAuth and refresh tokens — on their own — as
the presence of the subscriber and allows users to terminate trust relationships with linked
applications.
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, enveloping, replay, null cipher, and key substitution attacks.
Verify that relying parties specify the maximum authentication time to CSPs and that CSPs re-
authenticate the subscriber if they haven't used a session within that period.
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 transactions or account modifications.
L1 L2 L3 CWE NIST Tested Verdict
X X X 598
X X X 384 7.1
X X X 331 7.1

X X X 539 7.1
X X 331 7.1

X X X 613 7.1

30 days 12 hours o12 hours o 613 7.2

X X 613
X X 613 7.1
X X X 614 7.1.1
X X X 1004 7.1.1

X X X 16 7.1.1

X X X 16 7.1.1

X X X 16 7.1.1

X X 290 7.1.2

X X 798

X X 345

X 613 7.2.1

X 613 7.2.1

X X X 778
Comment
Section Name Item

V4 Access 4.1.1

V4 Access 4.1.2

V4 Access 4.1.3

V4 Access 4.1.4
V4 Access 4.1.5

V4 Access 4.2.1

V4 Access 4.2.2

V4 Access 4.3.1

V4 Access 4.3.2

V4 Access 4.3.3
Description
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.
Verify that all user and data attributes and policy information used by access controls cannot be
manipulated by end users unless specifically authorized.
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.

Verify that the principle of deny by default exists whereby new users/roles start with minimal or no
permissions and users/roles do not receive access to new features until access is explicitly assigned.
Verify that access controls fail securely including when an exception occurs.
Verify that sensitive data and APIs are protected against direct object attacks targeting creation,
reading, updating and deletion of records, such as creating or updating someone else's record,
viewing everyone's records, or deleting all records.

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.
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 file or directory metadata, such as Thumbs.db,
.DS_Store, .git or .svn folders.
Verify the application has additional authorization 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.
L1 L2 L3 CWE NIST Tested Verdict

X X X 602

X X X 639

X X X 285

X X X 276
X X X 285

X X X 639

X X X 352

X X X 419

X X X 548

X X 732
Comment
Section Name Item

V5 Validation 5.1.1

V5 Validation 5.1.2
V5 Validation 5.1.3

V5 Validation 5.1.4

V5 Validation 5.1.5

V5 Validation 5.2.1

V5 Validation 5.2.2

V5 Validation 5.2.3

V5 Validation 5.2.4

V5 Validation 5.2.5

V5 Validation 5.2.6

V5 Validation 5.2.7

V5 Validation 5.2.8

V5 Validation 5.3.1
V5 Validation 5.3.10

V5 Validation 5.3.2

V5 Validation 5.3.3

V5 Validation 5.3.4

V5 Validation 5.3.5
V5 Validation 5.3.6

V5 Validation 5.3.7

V5 Validation 5.3.8

V5 Validation 5.3.9

V5 Validation 5.4.1
V5 Validation 5.4.2
V5 Validation 5.4.3

V5 Validation 5.5.1

V5 Validation 5.5.2

V5 Validation 5.5.3

V5 Validation 5.5.4
Description
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 .
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.
Verify that all input is validated using positive validation .
Verify that structured data is strongly typed and validated against a defined schema including
allowed characters, length and pattern .
Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when
redirecting to potentially untrusted content.
Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an
HTML sanitizer library or framework feature.
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 being included must be sanitized or sandboxed before being
executed.
Verify that the application protects against template injection attacks by ensuring that any user
input being included is sanitized or sandboxed.
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, use whitelisting of protocols, domains,
paths and ports.
Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content,
especially as they relate to XSS resulting from inline scripts, and foreignObject.
Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression
template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.

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 .
Verify that the application protects against XPath injection or XML injection attacks.
Verify that output encoding preserves the user's chosen character set and locale, such that any
Unicode character point is valid and safely handled.
Verify that context-aware, preferably automated - or at worst, manual - output escaping protects
against reflected, stored, and DOM based XSS.
Verify that data selection or database queries use parameterized queries, ORMs, entity
frameworks, or are otherwise protected from database injection attacks.

Verify that where parameterized or safer mechanisms are not present, context-specific output
encoding is used to protect against injection attacks, such as the use of SQL escaping to protect
against SQL injection.
Verify that the application projects against JavaScript or JSON injection attacks, including for eval
attacks, remote JavaScript includes, CSP bypasses, DOM XSS, and JavaScript expression evaluation.
Verify that the application protects against LDAP Injection vulnerabilities, or that specific security
controls to prevent LDAP Injection have been implemented.
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.

Verify that the application protects against Local File Inclusion or Remote File Inclusion attacks.
Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to
detect or prevent stack, buffer, or heap overflows.
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.

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 XXE.
Verify that deserialization of untrusted data is avoided or is protected in both custom code and
third-party libraries .
Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to
parse the JSON document. Do not use eval to parse JSON.
L1 L2 L3 CWE NIST Tested Verdict

X X X 235

X X X 915
X X X 20

X X X 20

X X X 601

X X X 116

X X X 138

X X X 147

X X X 95

X X X 94

X X X 918

X X X 159

X X X 94

X X X 116
X X X 643

X X X 176

X X X 79

X X X 89

X X X 89
X X X 830

X X X 943

X X X 78

X X X 829

X X 120
X X 134
X X 190

X X X 502

X X X 611

X X X 502

X X X 95
Comment
Section Name Item

V6 Cryptography 6.1.1

V6 Cryptography 6.1.2

V6 Cryptography 6.1.3

V6 Cryptography 6.2.1

V6 Cryptography 6.2.2

V6 Cryptography 6.2.3

V6 Cryptography 6.2.4

V6 Cryptography 6.2.5

V6 Cryptography 6.2.6

V6 Cryptography 6.2.7

V6 Cryptography 6.2.8

V6 Cryptography 6.3.1

V6 Cryptography 6.3.2

V6 Cryptography 6.3.3

V6 Cryptography 6.4.1

V6 Cryptography 6.4.2
Description
Verify that regulated private data is stored encrypted while at rest, such as personally identifiable
information , sensitive personal information, or data assessed likely to be subject to EU's GDPR.
Verify that regulated health data is stored encrypted while at rest, such as medical records, medical
device details, or de-anonymized research records.
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.
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 cryptography.
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 swapped at any time, to protect against cryptographic
breaks.
Verify that known insecure block modes , padding modes , ciphers with small block sizes , and weak
hashing algorithms are not used unless required for backwards compatibility.

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.
Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to
ensure that ciphertext is not altered by an unauthorized party.
Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in
comparisons, calculations, or returns, to avoid leaking information.
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.
Verify that random GUIDs are created using the GUID v4 algorithm, and a cryptographically-secure
pseudo-random number generator . GUIDs created using other pseudo-random number generators
may be predictable.
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.
Verify that a secrets management solution such as a key vault is used to securely create, store,
control access to and destroy secrets.
Verify that key material is not exposed to the application but instead uses an isolated security
module like a vault for cryptographic operations.
L1 L2 L3 CWE NIST Tested Verdict

X X 311

X X 311

X X 311

X X X 310

X X 327

X X 326

X X 326

X X 326

X X 326

X 326

X 385

X X 338

X X 338

X 338

X X 798

X X 320
Comment
Section Name Item

V7 Error 7.1.1

V7 Error 7.1.2

V7 Error 7.1.3

V7 Error 7.1.4

V7 Error 7.2.1

V7 Error 7.2.2
V7 Error 7.3.1
V7 Error 7.3.2
V7 Error 7.3.3

V7 Error 7.3.4

V7 Error 7.4.1

V7 Error 7.4.2
V7 Error 7.4.3
Description
Verify that the application does not log credentials or payment details. Session tokens should only
be stored in logs in an irreversible, hashed form.
Verify that the application does not log other sensitive data as defined under local privacy laws or
relevant security policy.
Verify that the application logs security relevant events including successful and failed
authentication events, access control failures, deserialization failures and input validation failures.
Verify that each log event includes necessary information that would allow for a detailed
investigation of the timeline when an event happens.

Verify that all authentication decisions are logged, without storing sensitive session identifiers or
passwords. This should include requests with relevant metadata needed for security investigations.
Verify that all access control decisions can be logged and all failed decisions are logged. This should
include requests with relevant metadata needed for security investigations.
Verify that the application appropriately encodes user-supplied data to prevent log injection.
Verify that all events are protected from injection when viewed in log viewing software.
Verify that security logs are protected from unauthorized access and modification.
Verify that time sources are synchronized to the correct time and time zone. Strongly consider
logging only in UTC if systems are global to assist with post-incident forensic analysis.
Verify that a generic message is shown when an unexpected or security sensitive error occurs,
potentially with a unique ID which support personnel can use to investigate.
Verify that exception handling is used across the codebase to account for expected and unexpected
error conditions.
Verify that a "last resort" error handler is defined which will catch all unhandled exceptions.
L1 L2 L3 CWE NIST Tested Verdict

X X X 532

X X X 532

X X 778

X X 778

X X 778

X X 285
X X 117
X X 117
X X 200

X X

X X X 210

X X 544
X X 460
Comment
Section Name Item

V8 Data 8.1.1

V8 Data 8.1.2

V8 Data 8.1.3

V8 Data 8.1.4

V8 Data 8.1.5
V8 Data 8.1.6

V8 Data 8.2.1
V8 Data 8.2.2

V8 Data 8.2.3

V8 Data 8.3.1
V8 Data 8.3.2

V8 Data 8.3.3

V8 Data 8.3.4

V8 Data 8.3.5

V8 Data 8.3.6

V8 Data 8.3.7

V8 Data 8.3.8
Description
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/invalidated after the authorized user accesses the sensitive data.
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 sense for the application.
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 does not contain sensitive data or PII.
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 do not contain sensitive data.
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 opt-in consent for the use of that data before it is used in
any way.
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 deal with sensitive data.
Verify accessing sensitive data is audited , if the data is collected under relevant data protection
directives or where logging of access is required.
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.
Verify that sensitive or private information that is required to be encrypted, is encrypted using
approved algorithms that provide both confidentiality and integrity.
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.
L1 L2 L3 CWE NIST Tested Verdict

X X 524

X X 524

X X 233

X X 770

X 19
X 19

X X X 525
X X X 922

X X X 922

X X X 319
X X X 212

X X X 285

X X X 200

X X 532

X X 226

X X 327

X X 285
Comment
Section Name Item

V9 Communications 9.1.1

V9 Communications 9.1.2

V9 Communications 9.1.3

V9 Communications 9.2.1

V9 Communications 9.2.2

V9 Communications 9.2.3

V9 Communications 9.2.4
V9 Communications 9.2.5
Description
Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or
unencrypted protocols.
Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols
are enabled, with the strongest algorithms and ciphers set as preferred.
Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled,
such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher
suite.

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.

Verify that encrypted communications such as TLS is used for all inbound and outbound
connections, including for management ports, monitoring, authentication, API, or web service calls,
database, cloud, serverless, mainframe, external, and partner connections. The 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 Stapling, is
enabled and configured.
Verify that backend TLS connection failures are logged.
L1 L2 L3 CWE NIST Tested Verdict

X X X 319

X X X 326

X X X 326

X X 295

X X 319

X X 287

X X 299
X 544
Comment
Section Name Item

V10 Malicious 10.1.1

V10 Malicious 10.2.1

V10 Malicious 10.2.2

V10 Malicious 10.2.3

V10 Malicious 10.2.4

V10 Malicious 10.2.5

V10 Malicious 10.2.6

V10 Malicious 10.3.1

V10 Malicious 10.3.2

V10 Malicious 10.3.3

Description
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.
Verify that the application source code and third party libraries do not contain unauthorized phone
home or data collection capabilities. Where such functionality exists, obtain the user's permission
for it to operate before collecting any data.
Verify that the application does not ask for unnecessary or excessive permissions to privacy related
features or sensors, such as contacts, cameras, microphones, or location.

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.
Verify that the application source code and third party libraries does not contain time bombs by
searching for date and time related functions.
Verify that the application source code and third party libraries does not contain malicious code,
such as salami attacks, logic bypasses, or logic bombs.
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 signed. The update code must validate the digital signature of the
update before installing or executing the update.

Verify that the application employs integrity protections, such as code signing or sub-resource
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.

Verify that the application has protection from sub-domain takeovers if the application relies upon
DNS entries or DNS sub-domains, 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.
L1 L2 L3 CWE NIST Tested Verdict

X 749

X X 359

X X 272

X 507

X 511

X 511

X 507

X X X 16

X X X 353

X X X 350
Comment
Section Name Item

V11 BusLogic 11.1.1

V11 BusLogic 11.1.2

V11 BusLogic 11.1.3

V11 BusLogic 11.1.4

V11 BusLogic 11.1.5

V11 BusLogic 11.1.6

V11 BusLogic 11.1.7

V11 BusLogic 11.1.8

Description
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 submitted too quickly.
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 requests, excessive file uploads or denial of service attacks.
Verify the application has business logic limits or validation to protect against likely business risks or
threats, identified using threat modelling or similar methodologies.
Verify the application does not suffer from "time of check to time of use" issues or other race
conditions for sensitive operations.
Verify the application monitors for unusual events or activity from a business logic perspective. For
example, attempts to perform actions out of order or actions which a normal user would never
attempt.
Verify the application has configurable alerting when automated attacks or unusual activity is
detected.
L1 L2 L3 CWE NIST Tested Verdict

X X X 841

X X X 779

X X X 770

X X X 770

X X X 841

X X 367

X X 754

X X 390
Comment
Section Name Item

V12 Files 12.1.1

V12 Files 12.1.2

V12 Files 12.1.3

V12 Files 12.2.1

V12 Files 12.3.1

V12 Files 12.3.2

V12 Files 12.3.3

V12 Files 12.3.4

V12 Files 12.3.5

V12 Files 12.3.6

V12 Files 12.4.1

V12 Files 12.4.2

V12 Files 12.5.1

V12 Files 12.5.2

V12 Files 12.6.1

Description
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 limits.
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 too many files, or excessively large files.
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 traversal.
Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure,
creation, updating or removal of local files (LFI).
Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or
execution of remote files (RFI), which may also lead to SSRF.

Verify that the application protects against reflective file download (RFD) by validating or ignoring
user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header
should be set to text/plain, and the Content-Disposition header should 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 networks, JavaScript libraries, node npm libraries, or server-side
DLLs.
Verify that files obtained from untrusted sources are stored outside the web root, with limited
permissions, preferably with strong validation.
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 leakage. For example, backup files (e.g. .bak), temporary
working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other 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 load data/files from.
L1 L2 L3 CWE NIST Tested Verdict

X X X 400

X X 409

X X 770

X X 434

X X X 22

X X X 73

X X X 98

X X X 641

X X X 78

X X 829

X X X 922

X X X 509

X X X 552
X X X 434

X X X 918
Comment
Section Name Item

V13 API 13.1.1

V13 API 13.1.2

V13 API 13.1.3

V13 API 13.1.4

V13 API 13.1.5

V13 API 13.2.1

V13 API 13.2.2

V13 API 13.2.3

V13 API 13.2.4

V13 API 13.2.5

V13 API 13.2.6

V13 API 13.3.1

V13 API 13.3.2

V13 API 13.4.1

V13 API 13.4.2

Description

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.
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, and at the resource level, enforced by model-based
permissions.
Verify that requests containing unexpected or missing content types are rejected with appropriate
headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).
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.
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 the following: triple or double submit cookie pattern (see
[references](https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)), CSRF nonces, or ORIGIN request header
checks.
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 only) may be sufficient in many cases as it provides both
confidentiality and integrity protection. Per-message digital signatures can provide additional
assurance on top of the transport protections for high-security applications but bring with them
additional complexity and risks to weigh against the benefits.
Verify that XSD schema validation takes place to ensure a properly formed XML document, followed
by validation of each input field before any processing of that data takes place.
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 expression denial of service (DoS) as a result of expensive, nested
queries. For more advanced scenarios, query cost analysis should be used.
Verify that GraphQL or other data layer authorization logic should be implemented at the business
logic layer instead of the GraphQL layer.
L1 L2 L3 CWE NIST Tested Verdict

X X X 116

X X X 419
X X X 598

X X 285

X X 434

X X X 650
X X X 20

X X X 352

X X 779

X X 436

X X 345

X X X 20

X X 345

X X 770

X X 285
Comment
Section Name Item

V14 Config 14.1.1

V14 Config 14.1.2

V14 Config 14.1.3

V14 Config 14.1.4

V14 Config 14.1.5

V14 Config 14.2.1

V14 Config 14.2.2

V14 Config 14.2.3

V14 Config 14.2.4

V14 Config 14.2.5

V14 Config 14.2.6

V14 Config 14.3.1

V14 Config 14.3.2

V14 Config 14.3.3

V14 Config 14.4.1
V14 Config 14.4.2

V14 Config 14.4.3

V14 Config 14.4.4

V14 Config 14.4.5

V14 Config 14.4.6

V14 Config 14.4.7

V14 Config 14.5.1

V14 Config 14.5.2

V14 Config 14.5.3

V14 Config 14.5.4

Description
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.
Verify that compiler flags are configured to enable all available buffer overflow protections and
warnings, including stack randomization, data execution prevention, and to break the build if an
unsafe pointer, memory, format string, integer, or string operations are 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 documented and tested runbook in a reasonable time, or restored
from backups in a timely fashion.
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.
Verify that all unneeded features, documentation, samples, configurations are removed, such as
sample applications, platform documentation, and default or example users.
Verify that if application assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted
externally on a content delivery network or external provider, Subresource Integrity is used to
validate the integrity of the asset.
Verify that third party components come from pre-defined, trusted and continually maintained
repositories.
Verify that an inventory catalog is maintained of all third party libraries in use.
Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to
expose only the required behaviour into the application.
Verify that web or application server and framework error messages are configured to deliver user
actionable, customized responses to eliminate any unintended security disclosures.
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.
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 .
Verify that all API responses contain Content-Disposition: attachment; filename="api.json" .
Verify that a content security policy is in place that helps mitigate impact for XSS attacks like HTML,
DOM, JSON, and JavaScript injection vulnerabilities.
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: max-age=15724800; includeSubdomains.
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 embedded in a third-party site.
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 by an attacker.
Verify that the cross-domain resource sharing Access-Control-Allow-Origin header uses a strict
white-list of trusted domains to match against and does not support the "null" origin.
Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are
authenticated by the application.
L1 L2 L3 CWE NIST Tested Verdict

X X

X X 120

X X 16

X X

X X X 1026

X X X 1002

X X X 714

X X 829
X X

X X 265

X X X 209

X X X 497

X X X 200
X X X 173
X X X 116

X X X 1021
X X X 116

X X X 523
X X X 116

X X X 346
X X X 749

X X X 346

X X X 346

X X 306
Comment
Yes Pass
No Fail
N/A Partial