The Open Web Application Security Project (OWASP) Top 10 is the most widely referenced standard for web application security awareness. Updated periodically based on data from hundreds of organizations and thousands of real-world applications, this list represents the consensus view of the most critical security risks that web applications face. The most recent version, published in 2021, reflects significant shifts in the threat landscape.
For developers, security engineers, and organizations building web applications, understanding these risks is not optional. It is the baseline for building software that can withstand attack.
A01: Broken Access Control
Broken access control moved from fifth place to first in the 2021 update, reflecting how pervasive this issue has become. Access control enforces that users can only perform actions within their intended permissions. When it fails, attackers can access unauthorized data, modify records, or escalate privileges.
Common examples include insecure direct object references (IDOR), where changing a parameter value in a URL grants access to another user's data, and missing function-level access checks that allow regular users to call administrative endpoints.
Prevention: Implement access control on the server side where attackers cannot modify it. Deny by default. Log access control failures and alert on repeated violations. Disable web server directory listing and ensure file metadata and backup files are not present in web roots.
A02: Cryptographic Failures
Previously called "Sensitive Data Exposure," this category focuses on failures related to cryptography that lead to exposure of sensitive data. This includes transmitting data in cleartext, using deprecated hash functions like MD5 or SHA-1 for passwords, using weak or default cryptographic keys, and failing to enforce encryption through proper HTTP headers.
Prevention: Classify data processed, stored, or transmitted by the application. Identify which data is sensitive according to privacy laws and business requirements. Apply appropriate controls including encryption at rest and in transit. Use strong, current algorithms and protocols. Enforce encryption with directives like HTTP Strict Transport Security (HSTS).
A03: Injection
Injection attacks occur when untrusted data is sent to an interpreter as part of a command or query. SQL injection remains the most well-known variant, but injection flaws also affect NoSQL databases, OS commands, LDAP queries, and expression language parsers. Cross-site scripting (XSS), previously its own category, is now included under injection.
Prevention: Use parameterized queries and prepared statements for database interactions. Validate and sanitize all user input on the server side. Apply context-aware output encoding to prevent XSS. Use LIMIT and other SQL controls to prevent mass disclosure in case of successful injection.
A04: Insecure Design
New in the 2021 edition, this category addresses fundamental design flaws rather than implementation bugs. An insecure design cannot be fixed by perfect implementation. This category calls for greater use of threat modeling, secure design patterns, and reference architectures during the design phase of development.
Prevention: Establish a secure development lifecycle that integrates security at every phase. Use threat modeling for critical authentication, access control, business logic, and key flows. Write unit and integration tests to validate that all critical flows are resistant to the threat model.
A05: Security Misconfiguration
Security misconfiguration is the most common issue in the real world. It includes missing security hardening, improperly configured permissions, unnecessary features enabled, default accounts with unchanged passwords, overly informative error messages, and disabled or improperly configured security settings in frameworks and libraries.
Prevention: Implement a repeatable hardening process that makes it fast and easy to deploy locked-down environments. Use a minimal platform with no unnecessary features or components. Review and update configurations as part of the patch management process. Use automated tools to verify the effectiveness of configurations across all environments.
A06: Vulnerable and Outdated Components
Applications often rely on dozens or hundreds of third-party components, libraries, and frameworks. If any of these contain known vulnerabilities and the organization fails to patch or update them, the entire application is at risk. This category also covers unsupported or end-of-life software.
Prevention: Maintain an inventory of all components and their versions, including nested dependencies. Continuously monitor sources like CVE and NVD for vulnerabilities in those components. Subscribe to security advisories for the components you use. Only obtain components from official sources over secure links.
A07: Identification and Authentication Failures
Formerly called "Broken Authentication," this category covers weaknesses in authentication mechanisms that allow attackers to compromise passwords, keys, or session tokens. Common issues include permitting weak passwords, using plain text or weakly hashed passwords, missing or ineffective multi-factor authentication, and improper session management.
Prevention: Implement multi-factor authentication. Do not ship or deploy with default credentials. Check passwords against lists of known weak and breached passwords. Align password policies with NIST 800-63 guidelines. Ensure session identifiers are generated with high entropy and invalidated after logout.
A08: Software and Data Integrity Failures
This category relates to code and infrastructure that does not protect against integrity violations. Examples include relying on plugins, libraries, or modules from untrusted sources, insecure CI/CD pipelines that allow unauthorized modifications, and auto-update functionality that downloads and applies updates without integrity verification.
Prevention: Use digital signatures or similar mechanisms to verify that software and data come from expected sources. Ensure your CI/CD pipeline has proper segregation, configuration, and access controls. Verify that unsigned or unencrypted serialized data is not sent to untrusted clients without integrity checks.
A09: Security Logging and Monitoring Failures
Without proper logging, monitoring, and alerting, breaches go undetected. Studies consistently show that the average time to detect a breach exceeds 200 days. Insufficient logging of security-relevant events, failure to monitor logs for suspicious activity, and lack of an incident response plan all contribute to this risk.
Prevention: Ensure all login, access control, and server-side input validation failures are logged with sufficient context for forensic analysis. Use a centralized log management solution. Establish effective monitoring and alerting so that suspicious activities are detected and responded to in a timely fashion.
A10: Server-Side Request Forgery (SSRF)
SSRF occurs when a web application fetches a remote resource without validating the user-supplied URL. Attackers can coerce the application to send crafted requests to unexpected destinations, even when protected by firewalls, VPNs, or network access control lists. The severity of SSRF has increased with the growth of cloud services and microservices architectures.
Prevention: Sanitize and validate all client-supplied input data. Enforce URL schemas, ports, and destinations with a positive allow list. Disable HTTP redirections. Do not deploy raw responses to clients. Segment remote resource access functionality into separate networks to reduce the impact of SSRF.
Applying the OWASP Top 10 in Practice
The OWASP Top 10 is a starting point, not a complete security program. Organizations should integrate these risks into their security testing, code review processes, and developer training programs. Automated tools like static application security testing (SAST) and dynamic application security testing (DAST) can help identify many of these issues, but manual review and threat modeling remain essential for catching design-level flaws and business logic vulnerabilities.
Building secure web applications requires treating security as a continuous practice, not a one-time checklist.
