OWASP Application Security Verification Standard Report

ID	Name
1.2.1	Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers.
1.2.2	Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed.
1.2.3	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.
1.2.4	Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.
1.4.4	Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths.
1.4.5	Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles.
1.5.2	Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection.
1.5.3	Verify that input validation is enforced on a trusted service layer.
1.5.4	Verify that output encoding occurs close to or by the interpreter for which it is intended.
1.6.2	Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.
1.6.3	Verify that all keys and passwords are replaceable and are part of a well- defined process to re-encrypt sensitive data.
1.6.4	Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.
1.9.1	Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers.
1.9.2	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.
1.11.2	Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.
1.11.3	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.
1.14.6	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.
2.1.1	Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined).
2.1.2	Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied.
2.2.1	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.
2.2.2	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.
2.2.4	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.
2.2.5	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.
2.2.6	Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.
2.3.1	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.
2.4.1	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.
2.4.2	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.
2.4.3	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.
2.4.4	Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10.
2.4.5	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).
2.5.1	Verify that a system generated initial activation or recovery secret is not sent in clear text to the user.
2.5.2	Verify password hints or knowledge-based authentication (so- called secret questions) are not present.
2.5.3	Verify password credential recovery does not reveal the current password in any way.
2.5.4	Verify shared or default accounts are not present (e.g. root, admin, or sa).
2.6.1	Verify that lookup secrets can be used only once.
2.6.2	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.
2.6.3	Verify that lookup secrets are resistant to offline attacks, such as predictable values.
2.10.1	Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.
2.10.2	Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation).
2.10.3	Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.
2.10.4	Verify passwords, integrations with databases and third- party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.
3.1.1	Verify the application never reveals session tokens in URL parameters.
3.2.1	Verify the application generates a new session token on user authentication.
3.2.2	Verify that session tokens possess at least 64 bits of entropy.
3.2.3	Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.
3.2.4	Verify that session tokens are generated using approved cryptographic algorithms.
3.3.1	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.
3.3.2	If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period.
3.3.3	Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties.
3.3.4	Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.
3.4.1	Verify that cookie-based session tokens have the 'Secure' attribute set.
3.4.2	Verify that cookie-based session tokens have the 'HttpOnly' attribute set
3.4.3	Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks.
3.4.4	Verify that cookie-based session tokens use the '__Host-' prefix so cookies are only sent to the host that initially set the cookie.
3.4.5	Verify that if the application is published under a domain name with other applications that set or use session cookies that might disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible
3.5.1	Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications.
3.5.2	Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.
3.5.3	Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.
3.7.1	Verify the application ensures a full, valid login session or requires re- authentication or secondary verification before allowing any sensitive transactions or account modifications.
4.1.1	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.
4.1.2	Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
4.1.3	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.
4.1.5	Verify that access controls fail securely including when an exception occurs.
4.2.1	Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) 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.
4.2.2	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.
4.3.2	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.
5.1.1	Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).
5.1.2	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.
5.1.3	Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists).
5.1.4	Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match).
5.1.5	Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.
5.2.1	Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature.
5.2.2	Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.
5.2.3	Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
5.2.4	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.
5.2.6	Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.
5.2.7	Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.
5.2.8	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.
5.3.1	Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこor O'Hara).
5.3.2	Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled.
5.3.3	Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.
5.3.4	Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks.
5.3.5	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.
5.3.6	Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation.
5.3.7	Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.
5.3.8	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.
5.3.9	Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.
5.3.10	Verify that the application protects against XPath injection or XML injection attacks.
5.4.1	Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.
5.4.2	Verify that format strings do not take potentially hostile input, and are constant.
5.4.3	Verify that sign, range, and input validation techniques are used to prevent integer overflows.
5.5.1	Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.
5.5.2	Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.
5.5.3	Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).
5.5.4	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.
6.1.1	Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.
6.1.2	Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.
6.1.3	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.
6.2.1	Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.
6.2.2.	Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.
6.2.3	Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.
6.2.4	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.
6.2.5	Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.
6.2.6	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.
6.2.7	Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.
6.2.8	Verify that all cryptographic operations are constant-time, with no 'short- circuit' operations in comparisons, calculations, or returns, to avoid leaking information.
6.3.1	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.
6.3.2	Verify that random GUIDs are created using the GUID v4 algorithm, and a Cryptographically-secure Pseudo-random Number Generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable.
6.3.3	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.
6.4.1	Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets.
6.4.2	Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations.
7.1.1	Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form.
7.1.2	Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy.
7.1.3	Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures.
7.1.4	Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens.
7.3.1	Verify that all logging components appropriately encode data to prevent log injection.
7.3.3	Verify that security logs are protected from unauthorized access and modification.
7.4.1	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.
7.4.2	Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions.
7.4.3	Verify that a 'last resort' error handler is defined which will catch all unhandled exceptions.
8.1.1	Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.
8.1.2	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.
8.1.3	Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.
8.1.4	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.
8.3.1	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.
8.3.6	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.
8.3.7	Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity.
9.1.1	Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications.
9.1.3	Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.
9.2.1	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.
9.2.2	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.
9.2.3	Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.
10.2.1	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.
10.2.2	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.
10.2.3.	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.
10.2.4	Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.
10.2.5	Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.
10.2.6	Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.
10.3.1	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.
10.3.2	Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.
10.3.3	Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.
11.1.1	Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.
11.1.2	Verify that 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.
11.1.3	Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.
11.1.4	Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.
11.1.5	Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies.
11.1.6	Verify that the application does not suffer from 'Time Of Check to Time Of Use' (TOCTOU) issues or other race conditions for sensitive operations.
12.1.1	Verify that the application will not accept large files that could fill up storage or cause a denial of service.
12.1.3	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.
12.3.1	Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.
12.3.2	Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).
12.3.3	Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks.
12.3.4	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.
12.3.5	Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.
12.3.6	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.
12.4.1	Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.
12.5.1	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.
12.5.2	Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.
12.6.1	Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.
13.1.1	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.
13.1.3	Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.
13.1.4	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.
13.1.5	Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).
13.2.1	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.
13.2.2	Verify that JSON schema validation is in place and verified before accepting input.
13.2.3	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: double submit cookie pattern, CSRF nonces, or Origin request header checks.
13.2.5	Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.
13.2.6	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.
13.3.1	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.
13.3.2	Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.
13.4.1	Verify that a query allow list or a combination of depth limiting and amount limiting is 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.
14.1.3	Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.
14.2.2	Verify that all unneeded features, documentation, sample applications and configurations are removed.
14.2.3	Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.
14.2.4	Verify that third party components come from pre-defined, trusted and continually maintained repositories.
14.3.2	14.3.2 - 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.
14.3.3	Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
14.4.1	Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.
14.4.2	Verify that all API responses contain a Content-Disposition: attachment; filename='api.json' header (or other appropriate filename for the content type).
14.4.3	Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.
14.4.4	Verify that all responses contain a X-Content-Type-Options: nosniff header.
14.4.5	Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max- age=15724800; includeSubdomains.
14.4.6	Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.
14.4.7	Verify that the content of a web application cannot be embedded in a third- party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame- ancestors and X-Frame-Options response headers.
14.5.1	Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.
14.5.2	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.
14.5.3	Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow- Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the 'null' origin.
14.5.4	Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.

1.2.1

Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers.

1.2.2

Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed.

1.2.3

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.

1.2.4

Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.

1.4.4

Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths.

1.4.5

Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles.

1.5.2

Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection.

1.5.3

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

1.5.4

Verify that output encoding occurs close to or by the interpreter for which it is intended.

1.6.2

Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.

1.6.3

Verify that all keys and passwords are replaceable and are part of a well- defined process to re-encrypt sensitive data.

1.6.4

Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.

1.9.1

Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers.

1.9.2

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.

1.11.2

Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.

1.11.3

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.

1.14.6

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.

2.1.1

Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined).

2.1.2

Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied.

2.2.1

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.

2.2.2

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.

2.2.4

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.

2.2.5

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.

2.2.6

Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.

2.3.1

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.

2.4.1

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.

2.4.2

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.

2.4.3

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.

2.4.4

Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10.

2.4.5

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

2.5.1

Verify that a system generated initial activation or recovery secret is not sent in clear text to the user.

2.5.2

Verify password hints or knowledge-based authentication (so- called secret questions) are not present.

2.5.3

Verify password credential recovery does not reveal the current password in any way.

2.5.4

Verify shared or default accounts are not present (e.g. root, admin, or sa).

2.6.1

Verify that lookup secrets can be used only once.

2.6.2

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.

2.6.3

Verify that lookup secrets are resistant to offline attacks, such as predictable values.

2.10.1

Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.

2.10.2

Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation).

2.10.3

Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.

2.10.4

Verify passwords, integrations with databases and third- party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.

3.1.1

Verify the application never reveals session tokens in URL parameters.

3.2.1

Verify the application generates a new session token on user authentication.

3.2.2

Verify that session tokens possess at least 64 bits of entropy.

3.2.3

Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.

3.2.4

Verify that session tokens are generated using approved cryptographic algorithms.

3.3.1

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.

3.3.2

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

3.3.3

Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties.

3.3.4

Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.

3.4.1

Verify that cookie-based session tokens have the 'Secure' attribute set.

3.4.2

Verify that cookie-based session tokens have the 'HttpOnly' attribute set

3.4.3

Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks.

3.4.4

Verify that cookie-based session tokens use the '__Host-' prefix so cookies are only sent to the host that initially set the cookie.

3.4.5

Verify that if the application is published under a domain name with other applications that set or use session cookies that might disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible

3.5.1

Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications.

3.5.2

Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.

3.5.3

Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.

3.7.1

Verify the application ensures a full, valid login session or requires re- authentication or secondary verification before allowing any sensitive transactions or account modifications.

4.1.1

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.

4.1.2

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

4.1.3

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.

4.1.5

Verify that access controls fail securely including when an exception occurs.

4.2.1

Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) 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.

4.2.2

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.

4.3.2

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.

5.1.1

Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).

5.1.2

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.

5.1.3

Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists).

5.1.4

Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match).

5.1.5

Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.

5.2.1

Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature.

5.2.2

Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.

5.2.3

Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.

5.2.4

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.

5.2.6

Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.

5.2.7

Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.

5.2.8

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.

5.3.1

Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこor O'Hara).

5.3.2

Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled.

5.3.3

Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.

5.3.4

Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks.

5.3.5

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.

5.3.6

Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation.

5.3.7

Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.

5.3.8

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.

5.3.9

Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.

5.3.10

Verify that the application protects against XPath injection or XML injection attacks.

5.4.1

Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.

5.4.2

Verify that format strings do not take potentially hostile input, and are constant.

5.4.3

Verify that sign, range, and input validation techniques are used to prevent integer overflows.

5.5.1

Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.

5.5.2

Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.

5.5.3

Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).

5.5.4

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.

6.1.1

Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.

6.1.2

Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.

6.1.3

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.

6.2.1

Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.

6.2.2.

Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.

6.2.3

Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.

6.2.4

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.

6.2.5

Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.

6.2.6

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.

6.2.7

Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.

6.2.8

Verify that all cryptographic operations are constant-time, with no 'short- circuit' operations in comparisons, calculations, or returns, to avoid leaking information.

6.3.1

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.

6.3.2

Verify that random GUIDs are created using the GUID v4 algorithm, and a Cryptographically-secure Pseudo-random Number Generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable.

6.3.3

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.

6.4.1

Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets.

6.4.2

Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations.

7.1.1

Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form.

7.1.2

Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy.

7.1.3

Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures.

7.1.4

Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens.

7.3.1

Verify that all logging components appropriately encode data to prevent log injection.

7.3.3

Verify that security logs are protected from unauthorized access and modification.

7.4.1

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.

7.4.2

Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions.

7.4.3

Verify that a 'last resort' error handler is defined which will catch all unhandled exceptions.

8.1.1

Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.

8.1.2

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.

8.1.3

Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.

8.1.4

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.

8.3.1

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.

8.3.6

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.

8.3.7

Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity.

9.1.1

Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications.

9.1.3

Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.

9.2.1

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.

9.2.2

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.

9.2.3

Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.

10.2.1

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.

10.2.2

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.

10.2.3.

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.

10.2.4

Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.

10.2.5

Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.

10.2.6

Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.

10.3.1

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.

10.3.2

Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.

10.3.3

Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.

11.1.1

Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.

11.1.2

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

11.1.3

Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.

11.1.4

Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.

11.1.5

Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies.

11.1.6

Verify that the application does not suffer from 'Time Of Check to Time Of Use' (TOCTOU) issues or other race conditions for sensitive operations.

12.1.1

Verify that the application will not accept large files that could fill up storage or cause a denial of service.

12.1.3

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.

12.3.1

Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.

12.3.2

Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).

12.3.3

Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks.

12.3.4

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.

12.3.5

Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.

12.3.6

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.

12.4.1

Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.

12.5.1

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.

12.5.2

Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.

12.6.1

Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.

13.1.1

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.

13.1.3

Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.

13.1.4

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.

13.1.5

Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).

13.2.1

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.

13.2.2

Verify that JSON schema validation is in place and verified before accepting input.

13.2.3

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: double submit cookie pattern, CSRF nonces, or Origin request header checks.

13.2.5

Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.

13.2.6

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.

13.3.1

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.

13.3.2

Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.

13.4.1

Verify that a query allow list or a combination of depth limiting and amount limiting is 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.

14.1.3

Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.

14.2.2

Verify that all unneeded features, documentation, sample applications and configurations are removed.

14.2.3

Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.

14.2.4

Verify that third party components come from pre-defined, trusted and continually maintained repositories.

14.3.2

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

14.3.3

Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.

14.4.1

Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.

14.4.2

Verify that all API responses contain a Content-Disposition: attachment; filename='api.json' header (or other appropriate filename for the content type).

14.4.3

Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.

14.4.4

Verify that all responses contain a X-Content-Type-Options: nosniff header.

14.4.5

Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max- age=15724800; includeSubdomains.

14.4.6

Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.

14.4.7

Verify that the content of a web application cannot be embedded in a third- party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame- ancestors and X-Frame-Options response headers.

14.5.1

Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.

14.5.2

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.

14.5.3

Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow- Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the 'null' origin.

14.5.4

Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.

OWASP Application Security Verification Standard Report

Application Security Verification Standard (ASVS) goals

AppScan and the ASVS standard

Sections of the regulation