We support OWASP Top 10 and ASVS 5.0.
The main scan items are listed below.
The actual scan rules included in each scan rule set can be checked via the custom scan rule set feature. For details, please refer to this article
https://www.aeyescan.help/hc/ja/articles/37804926318361
Web Application Scan
■ OWASP TOP 10
A01:2025 Broken Access Control
A02:2025 Security Misconfiguration
A03:2025 Software Supply Chain Failures
A04:2025 Cryptographic Failures
A05:2025 Injection
A06:2025 Insecure Design
A07:2025 Authentication Failures
A08:2025 Software or Data Integrity Failures
A10:2025 Mishandling of Exceptional Conditions
For an overview of each item, please refer to here
*Opens an external website.
■ OWASP Application Security Verification Standard (ASVS) 5.0 Compliance Summary
V1.2.1
Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure.
V1.2.2
Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:).
V1.2.3
Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection).
V1.2.4
Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This is also relevant when writing stored procedures.
V1.2.5
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.
V1.3.1
Verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a well-known and secure HTML sanitization library or framework feature.
V1.3.2
Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized before being executed.
V1.5.1
Verify that the application configures XML parsers to use a restrictive configuration and that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.
V2.1.1
Verify that the application's documentation defines input validation rules for how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, email addresses, telephone numbers, or it could be an internal data format.
V2.2.1
Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow list of values, patterns, and ranges, or be based on comparing the input to an expected structure and logical limits according to predefined rules. For L1, this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input.
V2.2.2
Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability and should be encouraged, it must not be relied upon as a security control.
V2.3.1
Verify that the application will only process business logic flows for the same user in the expected sequential step order and without skipping steps.
V3.2.1
Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a useruploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields (such as Sec-Fetch-*) indicate it is the correct context, using the sandbox directive of the Content-SecurityPolicy header field or using the attachment disposition type in the Content-Disposition header field.
V3.2.2
Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or textContent) to prevent unintended execution of content such as HTML or JavaScript.
V3.3.1
Verify that cookies have the 'Secure' attribute set, and if the '__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for the cookie name.
V3.4.1
Verify that a Strict-Transport-Security header field is included on all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum age of at least 1 year must be defined, and for L2 and up, the policy must apply to all subdomains as well.
V3.4.2
Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP request header field value is used, it is validated against an allowlist of trusted origins. When 'AccessControl-Allow-Origin: *' needs to be used, verify that the response does not include any sensitive information.
V3.5.1
Verify that, if the application does not rely on the CORS preflight mechanism to prevent disallowed cross-origin requests to use sensitive functionality, these requests are validated to ensure they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP header fields that are not CORS-safelisted request-header fields. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF).
V3.5.2
Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a request which does not trigger a CORS-preflight request. This may require checking the values of the 'Origin' and 'Content-Type' request header fields or using an extra header field that is not a CORS-safelisted header-field.
V3.5.3
Verify that HTTP requests to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH, or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected.
V4.1.1
Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according to IANA Media Types, such as "text/", "/+xml" and "/xml".
V4.4.1
Verify that WebSocket over TLS (WSS) is used for all WebSocket connections.
V5.2.1
Verify that the application will only accept files of a size which it can process without causing a loss of performance or a denial of service attack.
V5.2.2
Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. For L1, this can focus just on files which are used to make specific business or security decisions. For L2 and up, this must apply to all files being accepted.
V5.3.1
Verify that files uploaded or generated by untrusted input and stored in a public folder, are not executed as server-side program code when accessed directly with an HTTP request.
V5.3.2
Verify that when the application creates file paths for file operations, instead of usersubmitted filenames, it uses internally generated or trusted data, or if user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied. This is to protect against path traversal, local or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks.
V6.1.1
Verify that application documentation defines how controls such as rate limiting, antiautomation, and adaptive response, are used to defend against attacks such as credential stuffing and password brute force. The documentation must make clear how these controls are configured and prevent malicious account lockout.
V6.2.1
Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended.
V6.2.2
Verify that users can change their password.
V6.2.3
Verify that password change functionality requires the user's current and new password.
V6.2.4
Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords which match the application's password policy, e.g. minimum length.
V6.2.5
Verify that passwords of any composition can be used, without rules limiting the type of characters permitted. There must be no requirement for a minimum number of upper or lower case characters, numbers, or special characters.
V6.2.6
Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password.
V6.2.7
Verify that "paste" functionality, browser password helpers, and external password managers are permitted.
V6.2.8
Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation.
V6.3.1
Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation.
V6.3.2
Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled.
V6.4.1
Verify that system generated initial passwords or activation codes are securely randomly generated, follow the existing password policy, and expire after a short period of time or after they are initially used. These initial secrets must not be permitted to become the long term password.
V6.4.2
Verify that password hints or knowledge-based authentication (so-called "secret questions") are not present.
V7.2.1
Verify that the application performs all session token verification using a trusted, backend service.
V7.2.2
Verify that the application uses either self-contained or reference tokens that are dynamically generated for session management, i.e. not using static API secrets and keys.
V7.2.3
Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number generator (CSPRNG) and possess at least 128 bits of entropy.
V7.2.4
Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token.
V7.4.1
Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session. For reference tokens or stateful sessions, this means invalidating the session data at the application backend. Applications using self-contained tokens will need a solution such as maintaining a list of terminated tokens, disallowing tokens produced before a per-user date and time or rotating a per-user signing key.
V7.4.2
Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company).
V8.1.1
Verify that authorization documentation defines rules for restricting function-level and data-specific access based on consumer permissions and resource attributes.
V8.2.1
Verify that the application ensures that function-level access is restricted to consumers with explicit permissions.
V8.2.2
Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA).
V8.3.1
Verify that the application enforces authorization rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript.
V9.1.1
Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents.
V9.1.2
Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist must include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and must not include the 'None' algorithm. If both symmetric and asymmetric must be supported, additional controls will be needed to prevent key confusion.
V9.1.3
Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.
V9.2.1
Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs, the claims 'nbf' and 'exp' must be verified.
V10.4.1
Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison.
V10.4.2
Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code.
V10.4.3
Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications.
V10.4.4
Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used.
V10.4.5
Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens, i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens using mutual TLS (mTLS). For L1 and L2 applications, refresh token rotation may be used. If refresh token rotation is used, the authorization server must invalidate the refresh token after usage, and revoke all refresh tokens for that authorization if an already used and invalidated refresh token is provided.
V11.3.1
Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used.
V11.3.2
Verify that only approved ciphers and modes such as AES with GCM are used.
V11.4.1
Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose.
V12.1.1
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 must be the preferred option.
V12.2.1
Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications.
V12.2.2
Verify that external facing services use publicly trusted TLS certificates.
V13.4.1
Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are inaccessible both externally and to the application itself.
V14.2.1
Verify that sensitive data is only sent to the server in the HTTP message body or header fields, and that the URL and query string do not contain sensitive information, such as an API key or session token.
V14.3.1
Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The 'Clear-Site-Data' HTTP response header field may be able to help with this but the client-side should also be able to clear up if the server connection is not available when the session is terminated.
V15.1.1
Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components.
V15.2.1
Verify that the application only contains components which have not breached the documented update and remediation time frames.
V15.3.1
Verify that the application only returns the required subset of fields from a data object. For example, it should not return an entire data object, as some individual fields should not be accessible to users.
Network Scan
・ Port Scan
Status survey of TCP (0–65535) / UDP (major ports)
・ Banner Survey
Detection of used software, collection of version information
・ Running Service Configuration Survey
Investigation of configuration flaws in active services (e.g., Telnet, FTP, SMTP, etc.)
・ Account Survey
Default account survey, investigation of services usable without authentication
・ SSL/TLS Encryption Strength Survey, Cryptographic Algorithm Obsolescence Survey (* Performed under Web Application Scan)
Investigates whether ciphers recommended in NIST Special Publication 800-52 Revision 2 and Mozilla Security/Server Side TLS are used.
Also, the list of TLS cipher suites references the Internet Assigned Numbers Authority (IANA).
API Scan
The following is a list of items detectable only with the "API Scan feature".
*The "API Scan feature" is an optional add-on feature available only on Business plans.
■OWASP API Security Top10 2023
・ API1:2023 Broken Object Level Authorization
・ API2:2023 Broken Authentication
・ API3:2023 Broken Object Property Level Authorization
・ API5:2023 Broken Function Level Authorization
・ API7:2023 Server Side Request Forgery
・ API8:2023 Security Misconfiguration
・ API9:2023 Improper Inventory Management
For an overview of each item, please refer to here.
*Opens an external website.