Req # Category

1 1.1 V1. Architecture, design and threat modelling

2 1.2 V1. Architecture, design and threat modelling

3 1.3 V1. Architecture, design and threat modelling
4 1.4 V1. Architecture, design and threat modelling

5 1.5 V1. Architecture, design and threat modelling

6 1.6 V1. Architecture, design and threat modelling

7 1.7 V1. Architecture, design and threat modelling

8 1.8 V1. Architecture, design and threat modelling

9 1.9 V1. Architecture, design and threat modelling

10 1.10 V1. Architecture, design and threat modelling
11 2.1 V2: Authentication Verification Requirements
12 2.2 V2: Authentication Verification Requirements
13 2.4 V2: Authentication Verification Requirements
14 2.6 V2: Authentication Verification Requirements

15 2.7 V2: Authentication Verification Requirements

16 2.8 V2: Authentication Verification Requirements

17 2.9 V2: Authentication Verification Requirements

18 2.12 V2: Authentication Verification Requirements

19 2.13 V2: Authentication Verification Requirements

20 2.16 V2: Authentication Verification Requirements

21 2.17 V2: Authentication Verification Requirements

22 2.18 V2: Authentication Verification Requirements
23 2.19 V2: Authentication Verification Requirements

24 2.20 V2: Authentication Verification Requirements

25 2.21 V2: Authentication Verification Requirements
26 2.22 V2: Authentication Verification Requirements

27 2.23 V2: Authentication Verification Requirements

28 2.24 V2: Authentication Verification Requirements

29 2.25 V2: Authentication Verification Requirements

30 2.26 V2: Authentication Verification Requirements

31 2.27 V2: Authentication Verification Requirements
32 2.28 V2: Authentication Verification Requirements
33 2.29 V2: Authentication Verification Requirements
34 2.30 V2: Authentication Verification Requirements

35 2.31 V2: Authentication Verification Requirements

36 2.32 V2: Authentication Verification Requirements
37 3.1 V3: Session Management Verification Requirements
38 3.2 V3: Session Management Verification Requirements
39 3.3 V3: Session Management Verification Requirements
40 3.4 V3: Session Management Verification Requirements
41 3.5 V3: Session Management Verification Requirements

42 3.6 V3: Session Management Verification Requirements

43 3.7 V3: Session Management Verification Requirements
44 3.10 V3: Session Management Verification Requirements
45 3.11 V3: Session Management Verification Requirements

46 3.12 V3: Session Management Verification Requirements

47 3.16 V3: Session Management Verification Requirements
48 3.17 V3: Session Management Verification Requirements
49 3.18 V3: Session Management Verification Requirements

50 4.1 V4: Access Control Verification Requirements

51 4.4 V4: Access Control Verification Requirements

52 4.5 V4: Access Control Verification Requirements

53 4.8 V4: Access Control Verification Requirements
54 4.9 V4: Access Control Verification Requirements

55 4.10 V4: Access Control Verification Requirements

56 4.11 V4: Access Control Verification Requirements

57 4.12 V4: Access Control Verification Requirements
58 4.13 V4: Access Control Verification Requirements

59 4.14 V4: Access Control Verification Requirements

60 4.15 V4: Access Control Verification Requirements

61 4.16 V4: Access Control Verification Requirements

62 5.1 V5: Malicious input handling verification requirements
63 5.3 V5: Malicious input handling verification requirements
64 5.5 V5: Malicious input handling verification requirements
65 5.6 V5: Malicious input handling verification requirements
66 5.10 V5: Malicious input handling verification requirements
67 5.11 V5: Malicious input handling verification requirements
68 5.12 V5: Malicious input handling verification requirements
69 5.13 V5: Malicious input handling verification requirements
 70 5.14 V5: Malicious input handling verification requirements
71 5.15 V5: Malicious input handling verification requirements
72 5.16 V5: Malicious input handling verification requirements
73 5.17 V5: Malicious input handling verification requirements
74 5.18 V5: Malicious input handling verification requirements
75 5.19 V5: Malicious input handling verification requirements
76 5.20 V5: Malicious input handling verification requirements
77 5.21 V5: Malicious input handling verification requirements
78 5.22 V5: Malicious input handling verification requirements
79 5.23 V5: Malicious input handling verification requirements
80 5.24 V5: Malicious input handling verification requirements
81 5.25 V5: Malicious input handling verification requirements
82 5.26 V5: Malicious input handling verification requirements
83 7.2 V7: Cryptography at rest verification requirements
84 7.6 V7: Cryptography at rest verification requirements
85 7.7 V7: Cryptography at rest verification requirements
86 7.8 V7: Cryptography at rest verification requirements
87 7.9 V7: Cryptography at rest verification requirements
88 7.11 V7: Cryptography at rest verification requirements
89 7.12 V7: Cryptography at rest verification requirements
90 7.13 V7: Cryptography at rest verification requirements
91 7.14 V7: Cryptography at rest verification requirements
92 7.15 V7: Cryptography at rest verification requirements
93 8.1 V8: Error handling and logging verification requirements
94 8.2 V8: Error handling and logging verification requirements
95 8.3 V8: Error handling and logging verification requirements
96 8.4 V8: Error handling and logging verification requirements
97 8.5 V8: Error handling and logging verification requirements
98 8.6 V8: Error handling and logging verification requirements
99 8.7 V8: Error handling and logging verification requirements
100 8.8 V8: Error handling and logging verification requirements
101 8.9 V8: Error handling and logging verification requirements
102 8.10 V8: Error handling and logging verification requirements
103 8.11 V8: Error handling and logging verification requirements
104 8.12 V8: Error handling and logging verification requirements
105 9.1 V9: Data protection verification requirements
106 9.2 V9: Data protection verification requirements
107 9.3 V9: Data protection verification requirements

108 9.4 V9: Data protection verification requirements

109 9.5 V9: Data protection verification requirements

110 9.6 V9: Data protection verification requirements
111 9.7 V9: Data protection verification requirements
112 9.8 V9: Data protection verification requirements
113 9.9 V9: Data protection verification requirements
114 9.10 V9: Data protection verification requirements
115 9.11 V9: Data protection verification requirements
116 10.1 V10: Communications security verification requirements
117 10.3 V10: Communications security verification requirements
118 10.4 V10: Communications security verification requirements
119 10.5 V10: Communications security verification requirements
120 10.6 V10: Communications security verification requirements
121 10.8 V10: Communications security verification requirements

122 10.10 V10: Communications security verification requirements

123 10.11 V10: Communications security verification requirements
124 10.12 V10: Communications security verification requirements
125 10.13 V10: Communications security verification requirements
126 10.14 V10: Communications security verification requirements
127 10.15 V10: Communications security verification requirements
128 10.16 V10: Communications security verification requirements
129 11.1 V11: HTTP security configuration verification requirements
130 11.2 V11: HTTP security configuration verification requirements
131 11.3 V11: HTTP security configuration verification requirements
132 11.4 V11: HTTP security configuration verification requirements
133 11.5 V11: HTTP security configuration verification requirements
134 11.6 V11: HTTP security configuration verification requirements
135 11.7 V11: HTTP security configuration verification requirements
136 11.8 V11: HTTP security configuration verification requirements
137 13.1 V13: Malicious controls verification requirements
138 13.2 V13: Malicious controls verification requirements

139 15.1 V15: Business logic verification requirements

140 15.2 V15: Business logic verification requirements

141 16.1 V16: Files and resources verification requirements
142 16.2 V16: Files and resources verification requirements
143 16.3 V16: Files and resources verification requirements
144 16.4 V16: Files and resources verification requirements
145 16.5 V16: Files and resources verification requirements
146 16.6 V16: Files and resources verification requirements
147 16.7 V16: Files and resources verification requirements
148 16.8 V16: Files and resources verification requirements
149 16.9 V16: Files and resources verification requirements
150 17.1 V17: Mobile verification requirements
151 17.2 V17: Mobile verification requirements
152 17.3 V17: Mobile verification requirements
153 17.4 V17: Mobile verification requirements
154 17.5 V17: Mobile verification requirements
155 17.6 V17: Mobile verification requirements
156 17.7 V17: Mobile verification requirements
157 17.8 V17: Mobile verification requirements
158 17.9 V17: Mobile verification requirements
159 17.10 V17: Mobile verification requirements
160 17.11 V17: Mobile verification requirements
161 18.1 V18: Web services verification requirements
162 18.2 V18: Web services verification requirements
163 18.3 V18: Web services verification requirements
164 18.4 V18: Web services verification requirements
165 18.5 V18: Web services verification requirements
166 18.6 V18: Web services verification requirements
167 18.7 V18: Web services verification requirements
168 18.8 V18: Web services verification requirements
169 18.9 V18: Web services verification requirements
170 18.10 V18: Web services verification requirements
171 19.1 V19. Configuration
172 19.2 V19. Configuration
173 19.3 V19. Configuration
174 19.4 V19. Configuration
175 19.5 V19. Configuration
176 19.6 V19. Configuration
177 19.7 V19. Configuration
178 19.8 V19. Configuration
179 19.9 V19. Configuration
Detail
Verify that all application components are identified and are known to be needed.
Verify that all components, such as libraries, modules, and external systems, that are not part of the application but that th
identified.
Verify that a high-level architecture for the application has been defined.
Verify that all application components are defined in terms of the business functions and/or security functions they provide
Verify that all components that are not part of the application but that the application relies on to operate are defined in te
functions, they provide.
Verify that a threat model for the target application has been produced and covers off risks associated with Spoofing, Tamp
and Elevation of privilege (STRIDE).
Verify all security controls (including libraries that call external security services) have a centralized implementation.

Verify that components are segregated from each other via a defined security control, such as network segmentation, firew
Verify the application has a clear separation between the data layer, controller layer and the display layer, such that securit
systems.
Verify that there is no sensitive business logic, secret keys or other proprietary information in client side code.
Verify all pages and resources by default require authentication except those specifically intended to be public (Principle of
Verify that all password fields do not echo the user’s password when it is entered.
Verify all authentication controls are enforced on the server side.
Verify all authentication controls fail securely to ensure attackers cannot log in.

Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent long passphrases/highly comp
Verify all account identity authentication functions (such as update profile, forgot password, disabled / lost token, help des
account are at least as resistant to attack as the primary authentication mechanism.
Verify that the changing password functionality includes the old password, the new password, and a password confirmatio

Verify that all suspicious authentication decisions are logged. This should include requests with relevant metadata needed

Verify that account passwords make use of a sufficient strength encryption routine and that it withstands brute force attack
Verify that credentials are transported using a suitable encrypted link and that all pages/functions that require a user to en
encrypted link.
Verify that the forgotten password function and other recovery paths do not reveal the current password and that the new
user.
Verify that information enumeration is not possible via login, password reset, or forgot account functionality.
Verify there are no default passwords in use for the application framework or any components used by the application (suc

Verify that request throttling is in place to prevent automated attacks against common authentication attacks such as brute
Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a pro
Verify that forgotten password and other recovery paths use a soft token, mobile push, or an offline recovery mechanism.
Verify that account lockout is divided into soft and hard lock status, and these are not mutually exclusive. If an account is te
force attack, this should not reset the hard lock status.

Verify that if knowledge based questions (also known as "secret questions") are required, the questions should be strong e
Verify that the system can be configured to disallow the use of a configurable number of previous passwords.
Verify re-authentication, step up or adaptive authentication, two factor authentication, or transaction signing is required be
operations are permitted as per the risk profile of the application.
Verify that measures are in place to block the use of commonly chosen passwords and weak passphrases.
Verify that all authentication challenges, whether successful or failed, should respond in the same average response time.
Verify that secrets, API keys, and passwords are not included in the source code, or online source code repositories.
Verify that if an application allows users to authenticate, they use a proven secure authentication mechanism.
Verify that if an application allows users to authenticate, they can authenticate using two-factor authentication or other str
that provides protection against username + password disclosure.
Verify that administrative interfaces are not accessible to untrusted parties.
Verify that there is no custom session manager, or that the custom session manager is resistant against all common session
Verify that sessions are invalidated when the user logs out.
Verify that sessions timeout after a specified period of inactivity.
Verify that sessions timeout after an administratively-configurable maximum time period regardless of activity (an absolute
Verify that all pages that require authentication have easy and visible access to logout functionality.
Verify that the session id is never disclosed in URLs, error messages, or logs. This includes verifying that the application doe
cookies.
Verify that all successful authentication and re-authentication generates a new session and session id.
Verify that only session ids generated by the application framework are recognized as active by the application.
Verify that session ids are sufficiently long, random and unique across the correct active session base.
Verify that session ids stored in cookies have their path set to an appropriately restrictive value for the application, and aut
the “HttpOnly” and “secure” attributes
Verify that the application limits the number of active concurrent sessions.
Verify that an active session list is displayed in the account profile or similar of each user. The user should be able to termin
Verify the user is prompted with the option to terminate all other active sessions after a successful change password proce
Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers,
they possess specific authorization. This implies protection against spoofing and elevation of privilege.
Verify that access to sensitive records is protected, such that only authorized objects or data is accessible to each user (for
with a parameter to see or alter another user's account).
Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery o
such as Thumbs.db, .DS_Store, .git or .svn folders.
Verify that access controls fail securely.
Verify that the same access control rules implied by the presentation layer are enforced on the server side.

Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users

Verify that there is a centralized mechanism (including libraries that call external authorization services) for protecting acce
Verify that all access control decisions can be logged and all failed decisions are logged.
Verify that the application or framework uses strong random anti-CSRF tokens or has another transaction protection mecha
Verify the system can protect against aggregate or continuous access of secured functions, resources, or data. For example
limit the number of edits per hour or to prevent the entire database from being scraped by an individual user.
Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and
applications to enforce anti-fraud controls as per the risk of application and past fraud.

Verify that the application correctly enforces context-sensitive authorisation so as to not allow unauthorised manipulation
Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflow
Verify that server side input validation failures result in request rejection and are logged.
Verify that input validation routines are enforced on the server side.
Verify
Verify that
that aallsingle input validation
SQL queries, control
HQL, OSQL, NOSQLis used
andby the application
stored procedures,for each of
calling type of data
stored that is accepted.
procedures are protected by the use
parameterization, and thus not susceptible to SQL injection
Verify that the application is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection.
Verify that the application is not susceptible to OS Command Injection, or that security controls prevent OS Command Injec
Verify that the application is not susceptible to Remote File Inclusion (RFI) or Local File Inclusion (LFI) when content is used
Verify
Ensurethat
thatthe application
all string is not
variables susceptible
placed into HTMLto common
or otherXMLwebattacks, suchisaseither
client code XPathproperly
query tampering,
contextuallyXML External
encoded Entity a
manually
encode contextually
If the application to ensureallows
framework the application
automatic is not parameter
mass susceptibleassignment
to reflected,(also
stored andautomatic
called DOM Cross-Site
variableScripting
binding)(XSS)
fromatta
th
security sensitive fields such as “a ccountBalance ”, “r ole ” or “p assword ” are protected from malicious
Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework automatic binding
request parameters (GET, POST, cookies, headers, environment, etc.)
Verify
feeds, that client positive
etc; using side validation is used
validation as a second
(whitelisting), linelesser
then of defense,
forms of in addition
validationtosuch
server
as side validation.
greylisting (eliminating known bad
(blacklisting).
Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length an
telephone, or validating that two related fields are reasonable, such as validating suburbs and zip or post codes match).
context
Make sure should be escaped
untrusted HTML(e.g.
fromnatural
WYSIWYGnames withor
editors Unicode
similar or
areapostrophes, ねこ
such aswith
properly sanitized an or O'Hara)
HTML sanitizer and handle it ap
validation task and encoding task.
For auto-escaping template technology, if UI escaping is disabled, ensure that HTML sanitization is enabled instead.
Verify that data transferred from one DOM context to another, uses safe JavaScript methods, such as using .innerText and .
Verify when parsing JSON in browsers, that JSON.parse is used to parse JSON on the client. Do not use eval() to parse JSON
Verify that authenticated data is cleared from client storage, such as the browser DOM, after the session is terminated.
Verify
Verify that
that all
all cryptographic
random numbers, modules fail file
random securely,
names, and errors GUIDs,
random are handled in a waystrings
and random that does not enableusing
are generated oracle
thepadding.
cryptograp
generator when these random values are intended to be not guessable by an attacker.
Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent stand
Verify
Verify that
that cryptographic modules
there is an explicit policyoperate
for howincryptographic
their approvedkeys modeare according
managed to their
(e.g., publisheddistributed,
generated, security policies.
revoked, and ex
properly enforced.
Verify that all consumers of cryptographic services do not have direct access to key material. Isolate cryptographic processe
the use of a hardware key vault (HSM).
Personally Identifiable Information should be stored encrypted at rest and ensure that communication goes via protected c
Verify that where possible, keys and secrets are zeroed when destroyed.
Verify
Verify that
that all keys and
random passwords
numbers are replaceable,
are created with proper and are generated
entropy even when or replaced at installation
the application is undertime.
heavy load, or that the ap
circumstances.
Verify that the application does not output error messages or stack traces containing sensitive data that could assist an atta
software/framework versions and personal information
Verify that error handling logic in security controls denies access by default.
Verify security logging controls provide the ability to log success and particularly failure events that are identified as securit
Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when
Verify that all events that include untrusted data will not execute as code in the intended log viewing software.
Verify
Verify that
that security logs aredoes
the application protected
not logfrom unauthorized
sensitive access and
data as defined under modification.
local privacy laws or regulations, organizational sen
or sensitive authentication data that could assist an attacker, including user’s session identifiers, passwords, hashes, or API
Verify that all non-printable symbols and field separators are properly encoded in log entries, to prevent log injection.
Verify that log fields from trusted and untrusted sources are distinguishable in log entries.
Verify that an audit log or similar allows for non-repudiation of key transactions.
Verify that security logs have some form of integrity checking or controls to prevent unauthorized modification.
Verify that the logs are stored on a different partition than the application is running with proper log rotation.
Verify
Verify that
that all
theforms
list ofcontaining sensitive
sensitive data information
processed have disabled
by the application client sideand
is identified, caching, including
that there is anautocomplete
explicit policyfeatures.
for how acc
encrypted and enforced under relevant data protection directives.
Verify that all sensitive data is sent to the server in the HTTP message body or headers (i.e., URL parameters are never used

Verify that the application sets appropriate anti-caching headers as per the risk of the application, such as the following:
Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Verify that on the server, all cached or temporary copies of sensitive data stored are protected from unauthorized access o
user accesses the sensitive data.
Verify that there is a method to remove each type of sensitive data from the application at the end of the required retentio
Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and h
Verify
Verify the
thatapplication
data storedhas the ability
in client to detect
side storage and as
- such alert on abnormal
HTML5 numbers
local storage, of requests
session storage,for data harvesting
IndexedDB, regularfor an examp
cookies or F
PII).
Verify
Verify accessing sensitive
that sensitive data isdata is logged,
rapidly if the
sanitized data
from is collected
memory under
as soon as itrelevant data protection
is no longer needed anddirectives
handled or where logging
in accordance to fo
framework/library/operating system.
Verify
Verify that
that aTLS
path can be
is used forbuilt from a trusted
all connections CA to each
(including bothTransport Layer
external and Security
backend (TLS) serverthat
connections) certificate, and that each
are authenticated serv
or that
does not fall back to insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm.
Verify that backend TLS connection failures are logged.
Verify that certificate paths are built and verified for all client certificates using configured trust anchors and revocation info
Verify that all connections to external systems that involve sensitive information or functions are authenticated.
Verify that there is a single standard TLS implementation that is used by the application that is configured to operate in an a

Verify
Verify that
that TLS
HTTP certificate public key
Strict Transport pinning
Security is implemented
headers are includedwith
onproduction
all requestsandandbackup public keys. For
for all subdomains, more
such information
as Strict-Transp
includeSubdomains
Verify that production website URL has been submitted to preloaded list of Strict Transport Security domains maintained b
references below.
Ensure forward secrecy ciphers are in use to mitigate passive attackers recording traffic.
Verify
Verify that
that proper certification
only strong revocation,
algorithms, ciphers, such as Online are
and protocols Certificate Status Protocol
used, through (OSCP) Stapling,
all the certificate is enabled
hierarchy, includingand
rootconfigu
and i
certifying authority.
Verify
Verify that
that the
the TLS settingsaccepts
application are in line with
only currentset
a defined leading practice,
of required particularly
HTTP as common
request methods, configurations,
such as GET and POSTciphers, and alg
are accepte
and DELETE) are explicitly blocked.
Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).
Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the applica
Verify that the Content Security Policy V2 (CSP) is in use for sites where content should not be viewed in a 3rd-party X-Fram
Verify
Verify that
that the HTTP
all API headerscontain
responses or any part of the HTTP responsenosniff
X-Content-Type-Options: do notand
expose detailed version information
Content-Disposition: attachment;of system comp
filename="api.j
content type).
Verify that the Content Security Policy V2 (CSP) is in use in a way that either disables inline JavaScript or provides an integri
noncing or hashing.
Verify that the X-XSS-Protection: 1; mode=block header is in place.
Verify all malicious activity is adequately sandboxed, containerized or isolated to delay and deter attackers from attacking o
Verify that a code review looks for malicious code, back doors, Easter eggs, and logic flaws.
Verify the application will only process business logic flows in sequential step order, with all steps being processed in realisti
order, skipped steps, process steps from another user, or too quickly submitted transactions.
Verify the application has business limits and correctly enforces on a per user basis, with configurable alerting and automat
attack.
Verify
Verify that
that URL redirects
untrusted file and
dataforwards
submitted only allow
to the whitelisted
application is destinations, or show
not used directly with afile
warning when redirecting
I/O commands, to potential
particularly to prote
file mime type, and OS command injection vulnerabilities.
Verify that files obtained from untrusted sources are validated to be of expected type and scanned by antivirus scanners to
content.
Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities to prevent remote/local file inc
Verify that untrusted data is not used within cross-domain resource sharing (CORS) to protect against arbitrary remote con
Verify that files obtained from untrusted sources are stored outside the webroot, with limited permissions, preferably with
Verify that the web or application server is configured by default to deny access to remote resources or systems outside the
Verify the application code does not execute uploaded data obtained from untrusted sources.
Do not use Flash, Active-X, Silverlight, NACL, client-side Java or other client side technologies not supported natively via W3
Verify that ID values stored on the device and retrievable by other applications, such as the UDID or IMEI number are not u
Verify that the mobile app does not store sensitive data onto potentially unencrypted shared resources on the device (e.g.
Verify that sensitive data is not stored unprotected on the device, even in system protected areas such as key chains.
Verify
Verify that
that secret keys,app
the mobile API prevents
tokens, orleaking
passwords are dynamically
of sensitive informationgenerated in mobile
(for example, applications.
screenshots are saved of the current app
or writing sensitive information in console).
Verify that the application is requesting minimal permissions for required functionality and resources.
Verify that the application sensitive code is laid out unpredictably in memory (For example ASLR).
Verify that there are anti-debugging techniques present that are sufficient enough to deter or delay likely attackers from in
example GDB).
Verify
Verify that
that the app does
mutable not export
structures have sensitive
been used activities, intents,
for sensitive content
strings suchproviders
as account etc., for other
numbers andmobile apps on the
are overwritten same
when notd
analysis attacks).
Verify that the app’s exposed activities, intents, content providers etc. validate all inputs.
Verify that the same encoding style is used between the client and the server.
Verify that access to administration and management functions within the Web Service Application is limited to web servic
Verify that XML or JSON schema is in place and verified before accepting input.
Verify that all input is limited to an appropriate size limit.
Verify that SOAP based web services are compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum.
Verify the use of session-based authentication and authorization. Please refer to sections 2, 3 and 4 for further guidance. A
Verify that the REST service is protected from Cross-Site Request Forgery.
Verify the REST service explicitly check the incoming Content-Type to be the expected one, such as application/xml or appl
Verify that the message payload is signed to ensure reliable transport between client and service.
Verify that alternative
All components shouldand lesstosecure
be up access
date with pathssecurity
proper do not configuration(s)
exist. and version(s). This should include removal of un
sample applications, platform documentation, and
Communications between components, such as between the default or example users.
application server and the database server, should be encryp
in different containers
Communications betweenor oncomponents,
different systems.
such as between the application server and the database server should be authen
necessary privileges.
Verify application deployments are adequately sandboxed, containerized or isolated to delay and deter attackers from attac
Verify
Verify that
that the application
authorised build and deployment
administrators processes
have the capability are performed
to verify in a of
the integrity secure fashion.
all security-relevant configurations to ens
with.
Verify that all application components are signed.
Verify that third party components come from trusted repositories.
Ensure that build processes for system level languages have all security flags enabled, such as ASLR, DEP, and security chec
Level 1 Level 2 Level 3 Since
x x x 1.0

x x 1.0
x x 1.0
x 1.0

x 1.0

x 1.0
x 1.0

x x 3.0

x x 3.0
x x 3.0
x x x 1.0
x x x 1.0
x x x 1.0
x x x 1.0

x x x 3.0

x x x 2.0
x x x 1.0

x x 2.0

x x 3.0

x x x 3.0

x x x 2.0
x x x 2.0
x x x 2.0

x x x 3.0
x x 2.0
x x x 3.0

x x 3.0

x x x 2.0
x x 2.0

x x 2.0
x x x 3.0
x 3.0
 x 3.0
x x x 3.0

x x 3.0
x x x 3.0
x x x 1.0
x x x 1.0
x x x 1.0
x 1.0
x x x 1.0

x x x 1.0
x x x 1.0
x x 1.0
x x 1.0

x x x 3.0
x x x 3.0
x x x 3.0
x x x 3.0

x x x 1.0

x x x 1.0

x x x 1.0
x x x 1.0
x x x 1.0

x x 1.0

x 1.0
x x 2.0
x x x 2.0

x x 2.0

x x 3.0

x x x 3.0
x x x 1.0
x x x 1.0
x x x 1.0
x 1.0
x x x 2.0
x x x 2.0
x x x 2.0
x x x 3.0
x x x 2.0
x x x 2.0
x x 2.0
x x 2.0
x x 3.0
x x 3.0
x x 3.0
x x 3.0
x x x 3.0
x x 3.0
x x 3.0
x x 3.0
x x 3.0
x x x 1.0
x x 1.0
x x x 1.0
x 1.0
x x 1.0
x 3.0
x x 3.0
x x 3.0
x x 3.0
x 3.0
x x x 1.0
x x 1.0
x x 1.0
x x 1.0
x 1.0
x x 1.0
x x 3.0
x 2.0
x 2.0
x x 3.0
x 3.0
x 3.0
x x x 1.0
x 1.0
x x x 1.0

x x x 1.0

x x 1.0
x 1.0
x x 2.0
 x 2.0
x x x 3.0
x x 3.0
x x 3.0
x x x 1.0
x x x 3.0
x 1.0
x 1.0
x x 1.0
x 1.0

x 3.0
x x x 3.0
x 3.0
x x x 3.0
x x x 3.0
x x x 3.0
x x x 3.0
x x x 1.0
x x x 1.0
x x 2.0
x x 2.0
x x x 2.0
x x x 3.0
x x x 3.0
x x x 3.0
x 2.0
x 3.0

x x 2.0

x x 2.0
x x x 2.0
x x x 2.0
x x x 2.0
x x x 2.0
x x x 2.0
x x 3.0
x x 2.0
x x x 3.0
x x x 2.0
x x x 2.0
x x x 2.0
x x x 2.0
x x 2.0
x x 2.0
x x 2.0
x x x 2.0
 x 2.0
x x x 2.0
x 2.0
x x x 2.0
x x x 3.0
x x x 3.0
x x x 3.0
x x x 3.0
x x x 3.0
x x x 3.0
x x x 3.0
x x 3.0
x x 3.0
x x 3.0
x x x 3.0
x x 3.0
x x 3.0
x x 3.0
x x 3.0
x 3.0
x 3.0
x 3.0
x 3.0
Original
2.3
2.5
2.10
2.11
2.14
2.15
3.8
3.9
3.13
3.14
3.15
4.2
4.3
4.13
4.15
5.2
5.4
5.7
5.8
5.9
5.14
5.15
5.19
7.1
7.3
7.4
7.5
7.10
8.2
8.3
8.9
8.11
8.12
8.15
10.2
10.7
10.9
V11.1
V11.4
V11.5
V11.6
V11.7
V11.8
V11.4
V13.1
V13.2
V13.3
V13.4
V13.5
V13.6
V13.7
V13.8
V13.9
15.1
15.2
15.3
15.4
15.5
15.6
15.7
15.9
15.11
16.4
17.1
V17.7
V17.8
V17.10
V17.11
V17.12
V17.13
V17.14
V17.15
V17.16
V17.17
V17.18
V17.19
V17.20
V17.22
V17.23
V17.24
Description
Verify that if a maximum number of authentication attempts is exceeded, the account is locked for a period of time long enoug
Verify that all authentication controls (including libraries that call external authentication services) have a centralized implemen
Verify that re-authentication is required before any application- specific sensitive operations are permitted.
Verify that after an administratively- configurable period of time, authentication credentials expire.
Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protec
Verify that all code implementing or using authentication controls is not affected by any malicious code.
Verify that the session id is changed upon re-authentication
Verify that the session id is changed or cleared on logout
Verify that all code implementing or using session management controls is not affected by any malicious code
Verify that authenticated session tokens using cookies are protected by the use of "HttpOnly".
Verify that authenticated session tokens using cookies are protected with the "secure" attribute.
Verify that users can only access secured URLs for which they possess specific authorization.
Verify that users can only access secured data files for which they possess specific authorization.
Verify that limitations on input and access imposed by the business on the application (such as daily transaction limits or seque
Verify that all code implementing or using access controls is not affected by any malicious code.
Verify that a positive validation pattern is defined and applied to all input
Verify that a character set, such as UTF-8, is specified for all sources of input
Verify that all input validation failures are logged.
Verify that all input data is canonicalized for all downstream decoders or interpreters prior to validation.
Verify that all input validation controls are not affected by any malicious code
Verify that the runtime environment is not susceptible to XML Injections or that security controls prevents XML Injections
-- EMPTY REQUIREMENT --
Verify that for each type of output encoding/escaping performed by the application, there is a single security control for that ty
Verify that all cryptographic functions used to protect secrets from the application user are implemented server side
Verify that access to any master secret(s) is protected from unauthorized access (A master secret is an application credential st
Verify that password hashes are salted when they are created
Verify that cryptographic module failures are logged
Verify that all code supporting or using a cryptographic module is not affected by any malicious code
Verify that all error handling is performed on trusted devices
Verify that all logging controls are implemented on the server.
Verify that there is a single application-level logging implementation that is used by the software.
Verify that a log analysis tool is available which allows the analyst to search for log events based on combinations of search crit
Verify that all code implementing or using error handling and logging controls is not affected by any malicious code.
Verify that logging is performed before executing the transaction. If logging was unsuccessful (e.g. disk full, insufficient permiss
Verify that failed TLS connections do not fall back to an insecure HTTP connection
Verify that all connections to external systems that involve sensitive information or functions use an account that has been set
Verify that specific character encodings are defined for all connections (e.g., UTF-8).
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Business Logic Section.
Business Logic Section.
Business Logic Section.
Business Logic Section.
Business Logic Section.
Business Logic Section.
Business Logic Section.
Business Logic Section.
Verify that the application covers off risks associated with Spoofing, Tampering, Repudiation, Information Disclosure, and Eleva
Verify that parameters obtained from untrusted sources are not used in manipulating filenames, pathnames or any file system
Verify that the client validates SSL certificates
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
Deprecated
 Status Removed
Deprecated 2.0
Merged 3.0
Deprecated 2.0
Deprecated 2.0
Updated 2.0
Moved 2.0
Updated 3.0
Updated 3.0
Moved 2.0
Updated 3.0
Updated 3.0
Updated 3.0
Updated 3.0
Moved 3.0
Moved 2.0
Deprecated 2.0
Deprecated 3.0
Deprecated 3.0
Deprecated 3.0
Moved 2.0
Merged 3.0
Deleted 3.0
Merged 3.0
Deprecated 3.0
Moved 3.0
Moved 2.0
Deprecated 2.0
Moved 2.0
3.0
Moved 3.0
Moved 3.0
Deprecated 3.0
Moved 2.0
Deprecated 3.0
Merged 3.0
inimum privileges necessary for the application to function properly
Merged 3.0
Merged 3.0
Merged 3.0
Merged 3.0
Merged 3.0
Merged 3.0
Merged 3.0
Merged 3.0
Duplicate 3.0
Moved 3.0
Deprecated 3.0
 Reason
A more complex requirement replaced it (v2.20)
Genericized to include all security controls and moved to 1.10
Re-authentication is so rarely observed that we decided to remove the control
Absolute timeouts and credential expiry removed as not being an effective control.
Became V2.21
Moved to V13 - Malicious Code
Rolled into 3.7
Rolled into 3.7
Moved to V13 - Malicious code
Moved into 3.13
Moved into 3.13
Rolled into 4.1
Rolled into 4.1
Moved to V15 Business Logic
Moved to V13 Malicious Controls
Removed as too difficult to implement particularly for free form text inputs
Removed as too difficult to implement in most languages
Removed as would create too many useless logs that would be ignored
Removed as Type 1 JSP technology specific and not an issue for most modern frameworks
Moved to V13 Malicious controls
Merged with V5.13
This requirement never existed
Genericized to include all security controls and moved to 1.10
Many modern responsive and mobile apps include this by design
Moved to V2.29
Moved to V2.13
Creating unnecessary logs that are never reviewed is counterproductive
Moved to V13
Deprecated
Became a more generic architectural control V1.13
Became a more generic architectural control V1.13
Removed as not required for secure software
Moved to V13 Malicious Controls
Removed as too detailed a control that would only be applicable to small percentage of all apps
Merged with 10.3
for the application to function properly
Most of section 15 has been merged into 15.8 and 15.10.
Most of section 15 has been merged into 15.8 and 15.10.
Most of section 15 has been merged into 15.8 and 15.10.
Most of section 15 has been merged into 15.8 and 15.10.
Most of section 15 has been merged into 15.8 and 15.10.
Most of section 15 has been merged into 15.8 and 15.10.
Most of section 15 has been merged into 15.8 and 15.10.
Most of section 15 has been merged into 15.8 and 15.10.
Duplicated requirement. Captured by V1.6
Moved to V16.2
Duplicated requirement. General requirement already captured by V10.