OWASP Top 10 Web Application Vulnerabilities Explained (2025 Edition)

The OWASP Top 10 is the most widely-cited reference for web application security. Published by the Open Web Application Security Project, it represents the consensus opinion of security experts worldwide on the ten most critical risks to web applications. Understanding each category is the first step to building and maintaining a secure application.

This guide breaks down each category with plain-English explanations, real-world attack examples, and practical remediation advice.

---

A01: Broken Access Control

What it is: The application doesn't properly enforce what authenticated users are allowed to do or see.

Examples:

• Visiting /admin/users when you're a regular user and seeing all user accounts
• Changing ?user_id=42 to ?user_id=43 in a URL and viewing another user's profile (IDOR)
• A user with read-only permissions calling a DELETE API endpoint and it working

Why it's #1: Broken access control moved from #5 to #1 in the 2021 update because it appears in 94% of tested applications. It's extremely common and easy to miss because authorization logic is often inconsistently applied across an application's many endpoints.

How to fix it:

• Deny access by default; explicitly grant permissions
• Implement access control checks server-side, not client-side
• Log all access control failures and alert on repeated failures (potential enumeration attack)
• Use automated tools that specifically test for IDOR and privilege escalation

---

A02: Cryptographic Failures

What it is: Sensitive data is exposed because it's transmitted or stored without adequate encryption, or with weak/broken cryptography.

Examples:

• Passwords stored as MD5 or SHA-1 hashes (trivially cracked with rainbow tables)
• Credit card numbers stored in plaintext in a database
• Authentication cookies transmitted over HTTP instead of HTTPS
• Using rand() for token generation instead of a cryptographically secure source

How to fix it:

• Use HTTPS everywhere; redirect HTTP to HTTPS; set HSTS headers
• Hash passwords with bcrypt, scrypt, or Argon2 (not MD5 or SHA-1)
• Encrypt sensitive data at rest using AES-256
• Use crypto.randomBytes() (Node.js) or equivalent for tokens and session IDs

---

A03: Injection

What it is: Untrusted data is sent to an interpreter (SQL, OS shell, LDAP, etc.) as part of a command, causing the interpreter to execute unintended commands.

SQL Injection example:

A login form with this query:

SELECT * FROM users WHERE username = '$username' AND password = '$password'

If an attacker enters ' OR '1'='1' -- as the username, the query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = '...'

The -- comments out the password check. Every user is returned. The attacker logs in as the first user in the table — often an admin.

How to fix it:

• Use parameterized queries / prepared statements (never string-concatenate SQL)
• Use an ORM that parameterizes by default
• Validate and sanitize all input at the server side
• Apply principle of least privilege to database accounts

---

A04: Insecure Design

What it is: Security flaws baked into the design or architecture of an application, not just implementation bugs. No amount of correct coding can fix an insecure design.

Examples:

• A password reset flow that sends a 6-digit SMS code with no rate limiting (brute-forceable in 10 minutes)
• An API that returns an entire user object when only a name is needed (over-fetching enables data scraping)
• "Security questions" used as the only second factor

How to fix it:

• Threat model your application during design, before writing code
• Follow secure design principles: least privilege, defense in depth, fail securely
• Conduct design-level security reviews, not just code reviews

---

A05: Security Misconfiguration

What it is: Security settings that are left at insecure defaults, incomplete, or misconfigured.

Examples:

• Default admin credentials not changed (admin/admin)
• Stack traces and debug information returned in production error responses
• S3 bucket set to public read
• Unnecessary HTTP methods enabled (TRACE, PUT on a read-only API)
• Directory listing enabled on a web server

How to fix it:

• Build with a repeatable, automated hardening process
• Review and disable all features, components, and endpoints not in use
• Ensure error responses never reveal stack traces or internal paths
• Regularly audit cloud storage and database permissions

---

A06: Vulnerable and Outdated Components

What it is: Using libraries, frameworks, or other software components with known vulnerabilities.

Why it matters: In 2021, the Log4Shell vulnerability (CVE-2021-44228) in the Apache Log4j library affected hundreds of millions of systems. The library was buried deep in thousands of applications' dependency trees. Many teams didn't know they were using it.

How to fix it:

• Maintain a software bill of materials (SBOM) for your dependencies
• Subscribe to vulnerability advisories for your key dependencies
• Use tools like npm audit, Dependabot, or Snyk to automate detection
• Have a documented process for applying security patches within 48 hours of a critical CVE

---

A07: Identification and Authentication Failures

What it is: Weaknesses in authentication and session management that allow attackers to compromise passwords, keys, or session tokens.

Examples:

• No brute-force protection on login forms
• Session tokens that don't expire after logout
• Passwords stored without salting
• "Remember me" tokens that are predictable
• Exposing session IDs in URLs

How to fix it:

• Implement multi-factor authentication
• Rate-limit and lock out failed login attempts
• Use long, random session tokens; invalidate them on logout and after inactivity
• Never put session IDs in URLs
• Use a proven authentication library rather than rolling your own

---

A08: Software and Data Integrity Failures

What it is: Code and infrastructure that doesn't protect against integrity violations — using untrusted plugins, libraries, or data without verifying their integrity.

Examples:

• Using npm packages without verifying checksums (supply chain attacks)
• Auto-updating software from untrusted CDNs without subresource integrity (SRI) checks
• Deserializing data from untrusted sources without validation (insecure deserialization)

Notable attack: The 2020 SolarWinds attack used a compromised build pipeline to insert malicious code into software updates that were then distributed to thousands of customers.

How to fix it:

• Use lockfiles (package-lock.json) and verify hashes
• Use SRI attributes on externally-loaded scripts and stylesheets
• Sign your CI/CD pipeline artifacts
• Never deserialize data from untrusted sources without strict schema validation

---

A09: Security Logging and Monitoring Failures

What it is: Insufficient logging and monitoring, allowing attacks to go undetected and unaddressed.

Why it matters: The average time to detect a breach is 207 days (IBM Cost of Data Breach Report 2023). Adequate logging cuts that dramatically.

What to log:

• Authentication events (success and failure)
• Access control failures
• Input validation failures
• High-value transactions (payments, data exports)

How to fix it:

• Log authentication and authorization events with user ID, timestamp, and IP
• Set up alerts on repeated authentication failures (brute force detection)
• Use a SIEM or log aggregation system that supports alerting
• Test that your logging works by running simulated attacks

---

A10: Server-Side Request Forgery (SSRF)

What it is: The application fetches a remote resource based on a user-supplied URL without validating that URL, allowing attackers to make the server send requests to internal resources.

Example attack:

An application has a webhook feature where you provide a URL and it sends a POST request there. An attacker supplies http://169.254.169.254/latest/meta-data/ (the AWS instance metadata URL) and the server returns AWS credentials — giving the attacker access to cloud infrastructure.

How to fix it:

• Validate and sanitize all user-supplied URLs before making server-side requests
• Use an allowlist of permitted domains/IP ranges
• Block requests to internal IP ranges (10.x.x.x, 172.16.x.x, 192.168.x.x, 169.254.x.x)
• Disable HTTP redirects in your HTTP client configuration

---

How to Test Your Application Against the OWASP Top 10

Manual testing against all 10 categories is time-consuming. Automated AI vulnerability scanning can cover most categories in minutes:

• A01 (Broken Access Control): IDOR detection, privilege escalation checks
• A03 (Injection): SQL injection, command injection testing
• A05 (Security Misconfiguration): Header analysis, error disclosure checks
• A07 (Auth Failures): Cookie attribute checks, session management review
• A10 (SSRF): URL parameter testing

AI Vulnerability Scanner runs all of these checks automatically. A typical scan of a 20-page web application completes in under 5 minutes and produces a prioritized report of findings with CVSS severity scores.

Scan your web application now →

---

AI Vulnerability Scanner maps its findings directly to OWASP categories so you can track your coverage across the OWASP Top 10 in a single report.