This Wiki is a unique database with vulnerability Proof of Concepts to act as a resource for pentesters. The findings are categorized by the OWASP ASVS category.
The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding. This weakness leads to almost all of the significant vulnerabilities in web applications, such as Cross-Site Scripting (XSS), SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.
Ensure that a verified application satisfies the following high-level requirements:
• Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.
• Input data is strongly typed, validated, range or length checked, or at worst, sanitized or filtered.
• Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.
With modern web application architecture, output encoding is more important than ever. It is difficult to provide robust input validation in certain scenarios, so the use of safer API such as parameterized queries, auto-escaping templating frameworks, or carefully chosen output encoding is critical to the security of the application.
Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords.
When the ASVS was first released, username + password was the most common form of authentication outside of high security systems. Multi-factor authentication (MFA) was commonly accepted in security circles but rarely required elsewhere. As the number of password breaches increased, the idea that usernames are somehow confidential and passwords unknown, rendered many security controls untenable. For example, NIST 800-63 considers usernames and knowledge based authentication (KBA) as public information, SMS and email notifications as "restricted" authenticator types , and passwords as pre-breached. This reality renders knowledge based authenticators, SMS and email recovery, password history, complexity, and rotation controls useless. These controls always have been less than helpful, often forcing users to come up with weak passwords every few months, but with the release of over 5 billion username and password breaches, it's time to move on.
Of all the sections in the ASVS, the authentication and session management chapters have changed the most. Adoption of effective, evidence-based leading practice will be challenging for many, and that's perfectly okay. We have to start the transition to a post-password future now.
One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or device interacting with it. Session management changes a stateless protocol to stateful, which is critical for differentiating different users or devices.
Ensure that a verified application satisfies the following high-level session management requirements:
Sessions are unique to each individual and cannot be guessed or shared
Sessions are invalidated when no longer required and timed out during periods of inactivity.
As previously noted, these requirements have been adapted to be a compliant subset of selected NIST 800-63b controls, focused around common threats and commonly exploited authentication weaknesses. Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory NIST 800-63b requirements.
Authorization is the concept of allowing access to resources only to those permitted to use them. Ensure that a verified application satisfies the following high level requirements:
• Persons accessing resources hold valid credentials to do so.
• Users are associated with a well-defined set of roles and privileges.
• Role and permission metadata is protected from replay or tampering.
The primary objective of error handling and logging is to provide useful information for the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high quality logs, with more signal than discarded noise.
High quality logs will often contain sensitive data, and must be protected as per local data privacy laws or directives. This should include:
• Not collecting or logging sensitive information unless specifically required.
• Ensuring all logged information is handled securely and protected as per its data classification.
• Ensuring that logs are not stored forever, but have an absolute lifetime that is as short as possible.
If logs contain private or sensitive data, the definition of which varies from country to country, the logs become some of the most sensitive information held by the application and thus very attractive to attackers in their own right.
It is also important to ensure that the application fails securely and that errors do not disclose unnecessary information.
There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA). This standard assumes that data protection is enforced on a trusted system, such as a server, which has been hardened and has sufficient protections.
Applications have to assume that all user devices are compromised in some way. Where an application transmits or stores sensitive information on insecure devices, such as shared computers, phones and tablets, the application is responsible for ensuring data stored on these devices is encrypted and cannot be easily illicitly obtained, altered or disclosed.
Ensure that a verified application satisfies the following high level data protection requirements:
• Confidentiality: Data should be protected from unauthorized observation or disclosure both in transit and when stored.
• Integrity: Data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
• Availability: Data should be available to authorized users as required.
Ensure that a verified application satisfies the following high level requirements:
• TLS or strong encryption is always used, regardless of the sensitivity of the data being transmitted
• The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers
• Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort
• Deprecated or known insecure algorithms and ciphers are disabled.
Leading industry advice on secure TLS configuration changes frequently, often due to catastrophic breaks in existing algorithms and ciphers. Always use the most recent versions of TLS configuration review tools (such as SSLyze or other TLS scanners) to configure the preferred order and algorithm selection. Configuration should be periodically checked to ensure that secure communications configuration is always present and effective.
Ensure that code satisfies the following high level requirements:
• Malicious activity is handled securely and properly to not affect the rest of the application.
• Does not have time bombs or other time-based attacks.
• Does not "phone home" to malicious or unauthorized destinations.
• Does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.
Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.
Ensure that a verified application satisfies the following high level requirements:
• The business logic flow is sequential, processed in order, and cannot be bypassed.
• Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
• High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.
Ensure that a verified application that uses trusted service layer APIs (commonly using JSON or XML or GraphQL) has:
• Adequate authentication, session management and authorization of all web services.
• Input validation of all parameters that transit from a lower to higher trust level.
• Effective security controls for all API types, including cloud and Serverless API
Please read this chapter in combination with all other chapters at this same level; we no longer duplicate authentication or API session management concerns.
• A secure, repeatable, automatable build environment.
• Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
• A secure-by-default configuration, such that administrators and users have to weaken the default security posture.
Configuration of the application out of the box should be safe to be on the Internet, which means a safe out of the box configuration.
The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding. This weakness leads to almost all of the significant vulnerabilities in web applications, such as Cross-Site Scripting (XSS), SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.
Ensure that a verified application satisfies the following high-level requirements:
• Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.
• Input data is strongly typed, validated, range or length checked, or at worst, sanitized or filtered.
• Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.
With modern web application architecture, output encoding is more important than ever. It is difficult to provide robust input validation in certain scenarios, so the use of safer API such as parameterized queries, auto-escaping templating frameworks, or carefully chosen output encoding is critical to the security of the application.
V2 - Authentication
Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords.
When the ASVS was first released, username + password was the most common form of authentication outside of high security systems. Multi-factor authentication (MFA) was commonly accepted in security circles but rarely required elsewhere. As the number of password breaches increased, the idea that usernames are somehow confidential and passwords unknown, rendered many security controls untenable. For example, NIST 800-63 considers usernames and knowledge based authentication (KBA) as public information, SMS and email notifications as "restricted" authenticator types , and passwords as pre-breached. This reality renders knowledge based authenticators, SMS and email recovery, password history, complexity, and rotation controls useless. These controls always have been less than helpful, often forcing users to come up with weak passwords every few months, but with the release of over 5 billion username and password breaches, it's time to move on.
Of all the sections in the ASVS, the authentication and session management chapters have changed the most. Adoption of effective, evidence-based leading practice will be challenging for many, and that's perfectly okay. We have to start the transition to a post-password future now.
V3 - Session management
One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or device interacting with it. Session management changes a stateless protocol to stateful, which is critical for differentiating different users or devices.
Ensure that a verified application satisfies the following high-level session management requirements:
Sessions are unique to each individual and cannot be guessed or shared
Sessions are invalidated when no longer required and timed out during periods of inactivity.
As previously noted, these requirements have been adapted to be a compliant subset of selected NIST 800-63b controls, focused around common threats and commonly exploited authentication weaknesses. Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory NIST 800-63b requirements.
V4 - Access control
Authorization is the concept of allowing access to resources only to those permitted to use them. Ensure that a verified application satisfies the following high level requirements:
• Persons accessing resources hold valid credentials to do so.
• Users are associated with a well-defined set of roles and privileges.
• Role and permission metadata is protected from replay or tampering.
V6 - Cryptography
Ensure that a verified application satisfies the following high level requirements:
• All cryptographic modules fail in a secure manner and that errors are handled correctly.
• A suitable random number generator is used.
• Access to keys is securely managed
V7 - Error Logging
The primary objective of error handling and logging is to provide useful information for the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high quality logs, with more signal than discarded noise.
High quality logs will often contain sensitive data, and must be protected as per local data privacy laws or directives. This should include:
• Not collecting or logging sensitive information unless specifically required.
• Ensuring all logged information is handled securely and protected as per its data classification.
• Ensuring that logs are not stored forever, but have an absolute lifetime that is as short as possible.
If logs contain private or sensitive data, the definition of which varies from country to country, the logs become some of the most sensitive information held by the application and thus very attractive to attackers in their own right.
It is also important to ensure that the application fails securely and that errors do not disclose unnecessary information.
V8 - Data Protection
There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA). This standard assumes that data protection is enforced on a trusted system, such as a server, which has been hardened and has sufficient protections.
Applications have to assume that all user devices are compromised in some way. Where an application transmits or stores sensitive information on insecure devices, such as shared computers, phones and tablets, the application is responsible for ensuring data stored on these devices is encrypted and cannot be easily illicitly obtained, altered or disclosed.
Ensure that a verified application satisfies the following high level data protection requirements:
• Confidentiality: Data should be protected from unauthorized observation or disclosure both in transit and when stored.
• Integrity: Data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
• Availability: Data should be available to authorized users as required.
V9 - Communications
Ensure that a verified application satisfies the following high level requirements:
• TLS or strong encryption is always used, regardless of the sensitivity of the data being transmitted
• The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers
• Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort
• Deprecated or known insecure algorithms and ciphers are disabled.
Leading industry advice on secure TLS configuration changes frequently, often due to catastrophic breaks in existing algorithms and ciphers. Always use the most recent versions of TLS configuration review tools (such as SSLyze or other TLS scanners) to configure the preferred order and algorithm selection. Configuration should be periodically checked to ensure that secure communications configuration is always present and effective.
V10 - Malicious Code
Ensure that code satisfies the following high level requirements:
• Malicious activity is handled securely and properly to not affect the rest of the application.
• Does not have time bombs or other time-based attacks.
• Does not "phone home" to malicious or unauthorized destinations.
• Does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.
Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.
V11 - Business Logic
Ensure that a verified application satisfies the following high level requirements:
• The business logic flow is sequential, processed in order, and cannot be bypassed.
• Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
• High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.
V12 - Files Resources
Ensure that a verified application satisfies the following high level requirements:
• Untrusted file data should be handled accordingly and in a secure manner.
• Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions.
V13 - API
Ensure that a verified application that uses trusted service layer APIs (commonly using JSON or XML or GraphQL) has:
• Adequate authentication, session management and authorization of all web services.
• Input validation of all parameters that transit from a lower to higher trust level.
• Effective security controls for all API types, including cloud and Serverless API
Please read this chapter in combination with all other chapters at this same level; we no longer duplicate authentication or API session management concerns.
V14 - Config
Ensure that a verified application has:
• A secure, repeatable, automatable build environment.
• Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
• A secure-by-default configuration, such that administrators and users have to weaken the default security posture.
Configuration of the application out of the box should be safe to be on the Internet, which means a safe out of the box configuration.
V5 - Validation / Sanitization
Blind SQL injection
V5 - Validation / Sanitization
Clickjacking
V5 - Validation / Sanitization
Command Injection
V5 - Validation / Sanitization
Cookie-Based XSS
V5 - Validation / Sanitization
Cross Site Script Inclusion (XSSI)
V5 - Validation / Sanitization
CSRF/URL-Based XSS
V5 - Validation / Sanitization
CSS injection
V5 - Validation / Sanitization
CSV Injection
V5 - Validation / Sanitization
DOM-Based XSS
V5 - Validation / Sanitization
Flash-Based XSS
V5 - Validation / Sanitization
HTML injection
V5 - Validation / Sanitization
HTTP Parameter Pollution to XSS
V5 - Validation / Sanitization
HTTP Request Smuggling
V5 - Validation / Sanitization
HTTP Response Splitting (CRLF)
V5 - Validation / Sanitization
iframe Injection
V5 - Validation / Sanitization
LDAP injection
V5 - Validation / Sanitization
Local File Inclusion
V5 - Validation / Sanitization
OOB (Out of Band) XXE
V5 - Validation / Sanitization
Open Redirect
V5 - Validation / Sanitization
Reflected File Download (RFD)
V5 - Validation / Sanitization
Reflected Self-XSS
V5 - Validation / Sanitization
Reflected XSS
V5 - Validation / Sanitization
Reflected XSS - WAF bypass
V5 - Validation / Sanitization
Remote Code Execution
V5 - Validation / Sanitization
Remote File Inclusion
V5 - Validation / Sanitization
Rosetta Flash
V5 - Validation / Sanitization
Server Side Template Injection
V5 - Validation / Sanitization
Server Side Template Injection (SSTI) in Flask
V5 - Validation / Sanitization
SQL Injection
V5 - Validation / Sanitization
SSI Injection
V5 - Validation / Sanitization
SSRF
V5 - Validation / Sanitization
Stored XSS
V5 - Validation / Sanitization
Tabnabbing
V5 - Validation / Sanitization
TRACE Method XSS - Cross-Site Tracing (XST)
V5 - Validation / Sanitization
Universal (UXSS) XSS
V5 - Validation / Sanitization
WAF Bypass
V5 - Validation / Sanitization
XSS via Referer
V5 - Validation / Sanitization
XXE
V2 - Authentication
Authentication Bypass
V2 - Authentication
2-Factor Authentication (2FA) Bypass
V2 - Authentication
CAPTCHA Bypass - X-Forwarded-For
V2 - Authentication
Lack of Password Confirmation
V2 - Authentication
Lack of Verification Email
V2 - Authentication
Mail Bombing in the Contact Form
V2 - Authentication
Missing brute-force protection for two-factor authentication
V2 - Authentication
No Rate Limiting on a Form
V2 - Authentication
No Rate Limiting or Captcha on Login Page
V2 - Authentication
Password Cracking for Common/Weak Passwords when Password Policy is Weak
V2 - Authentication
Username/Email Address Enumeration
V2 - Authentication
Using Default Credentials
V2 - Authentication
Weak 2FA Implementation
V2 - Authentication
Weak Login Function
V2 - Authentication
Weak Password Policy
V2 - Authentication
Weak Registration Implementation over HTTP
V3 - Session management
Insecure Storage of JWT Token
V3 - Session management
JWT token over URL (GET method)
V3 - Session management
Old Session do not invalidate after logout
V3 - Session management
Old Session do not invalidate after password change
V3 - Session management
Password Link Expiration Errors
V3 - Session management
Password Reset Token Sent Over HTTP
V3 - Session management
Session Fixation for Concurrent Sessions
V3 - Session management
Session Fixation for the Same Account
V3 - Session management
Session Timeout is Too Long
V3 - Session management
Session token predictable / low entropy
V4 - Access control
Account takeover via "Forgot your password" functionality
V4 - Access control
Admin panel publicly accessible
V4 - Access control
Admin panel takeover
V4 - Access control
AWS bucket misconfiguration
V4 - Access control
Critically Sensitive Data - Password Disclosure
V4 - Access control
Critically Sensitive Data - Private API Keys
V4 - Access control
CSRF
V4 - Access control
Database Management System (DBMS) Misconfiguration:Excessively Privileged User / DBA
V4 - Access control
Directory Listing Enabled
V4 - Access control
EXIF Geolocation Data Not Stripped From Uploaded Images - User Enumeration
