OWASP Top 10: Web Application Security Guide for Developers [2026]

95% of web application breaches exploit one of ten well-documented vulnerability categories. The OWASP Top 10 — updated by the Open Web Application Security Project every three to four years — is the security industry's consensus list of those categories, ranked by prevalence, exploitability, and impact. Understanding the Top 10 is not optional for any team building web applications that handle user data.

This guide covers each OWASP Top 10 category (2021 edition, still current as of 2026) with concrete exploitation scenarios, business impact analysis, and practical remediation. By the end, you will have the knowledge to identify and address the vulnerabilities responsible for the vast majority of web application breaches.

OWASP Top 10: Overview

The 2021 OWASP Top 10 categories:

1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery (SSRF)

A01: Broken Access Control

Broken Access Control moved to the top of the OWASP list in 2021. Access control failures allow users to act outside their intended permissions — reading other users' data, modifying data they don't own, or accessing administrative functions without authorization.

How It Happens

The most common pattern is Insecure Direct Object Reference (IDOR). An application uses a predictable identifier in a URL or API request without verifying that the requesting user owns or is authorized to access that specific resource.

Example: A project management SaaS exposes task details at /api/tasks/1847. User A is authorized for task 1847. If the application does not verify that the authenticated user owns task 1847 on every request, User A can modify the URL to /api/tasks/1848 and access User B's task — a complete breach of tenant isolation.

Privilege escalation is the second common pattern: a user manipulates a request to escalate their role. Example: a registration form accepts a role parameter in the POST body. An attacker submits role=admin and receives an admin account.

Business Impact

Broken access control enables unauthorized data access, data modification, and in the worst cases, full administrative takeover. Regulatory exposure includes GDPR Article 32 violations (failure to implement appropriate technical measures to protect personal data) with fines up to 4% of global annual revenue.

Remediation

• Implement server-side access control on every request. Client-side access control (hiding UI elements for unauthorized users) is not security — it is cosmetic.
• Use a deny-by-default policy. Only explicitly grant access; do not assume denial.
• Verify object ownership or authorization before returning or modifying any resource identified by a user-controlled parameter.
• Log access control failures and alert on patterns (a user hitting 403 on sequential IDs indicates an IDOR probe).
• Use frameworks that provide centralized authorization (OPA, Casbin) rather than ad-hoc permission checks scattered across business logic.

A02: Cryptographic Failures

Cryptographic failures — formerly "Sensitive Data Exposure" — covers two distinct failure modes: transmitting sensitive data without encryption and storing sensitive data with weak or no encryption.

How It Happens

Weak storage: A 2024 breach exposed a SaaS platform's customer database with passwords hashed using MD5. MD5 has been computationally broken for decades — modern GPU-based cracking tools can reverse MD5 hashes for common passwords in seconds. The correct algorithms for password storage are bcrypt, scrypt, or Argon2, which are deliberately slow and memory-intensive.

Weak transport: An e-commerce application transmitted payment form data over HTTP rather than HTTPS, allowing a network-based attacker to intercept credit card numbers in transit.

Key management failures: Encryption that uses hardcoded keys, stores keys adjacent to the encrypted data, or fails to rotate keys provides minimal actual protection. Encryption is only as strong as the key management protecting the keys.

Business Impact

Cryptographic failures lead to credential theft (enabling account takeover), payment card data theft (PCI-DSS violations, card scheme fines), and exposure of health records (HIPAA violations in the US, GDPR Article 9 for health data in EU).

Remediation

• Password hashing: bcrypt (cost factor 12+), Argon2id, or scrypt. Never MD5, SHA-1, or unsalted SHA-256.
• Transport encryption: TLS 1.3 for all client-server communication. Disable TLS 1.0 and 1.1. Reject weak cipher suites (RC4, DES, 3DES).
• Data-at-rest encryption: AES-256 for sensitive fields. Application-layer encryption (encrypting before writing to the database) is stronger than database-level encryption because it protects against compromised database access.
• Key management: Store encryption keys in dedicated key management systems (AWS KMS, HashiCorp Vault, Azure Key Vault). Never hardcode keys in source code or store them in environment variables without a secrets manager.

A03: Injection

Injection vulnerabilities occur when untrusted user input is incorporated into a query or command without proper separation — the application cannot distinguish attacker-controlled data from legitimate query syntax.

How It Happens

SQL injection remains the archetype. An application constructs a SQL query using string concatenation with user-provided input. An attacker submits input containing SQL syntax that modifies the query's logic.

Classic example: a login form that constructs SELECT * FROM users WHERE username='$input' AND password='$pass'. An attacker submits admin' OR '1'='1 as the username. The query becomes WHERE username='admin' OR '1'='1' — the OR '1'='1' condition is always true, returning all users and bypassing the password check.

Beyond SQL, injection affects LDAP queries, OS command execution, template engines (Server-Side Template Injection), and XML parsers (XXE). The root cause is the same in all cases: mixing untrusted data with executable code.

Business Impact

A successful SQL injection attack can read, modify, or delete the entire database. Blind SQL injection (where the attacker receives no direct query output) can still exfiltrate the full database via timing attacks or out-of-band channels, just more slowly.

Remediation

• Parameterized queries (prepared statements): The primary defense. Parameterization ensures user input is always treated as data, never as SQL syntax. ORMs (SQLAlchemy, Hibernate, ActiveRecord) use parameterized queries internally when used correctly.
• Input validation: Validate that input conforms to expected format and type. A phone number field should accept only digits and formatting characters. Do not rely on input validation alone as the primary injection defense — it is a secondary defense.
• Least privilege database accounts: Application database users should have only SELECT, INSERT, UPDATE permissions on the specific tables they need. They should not have DROP TABLE, GRANT, or administrative permissions.

A04: Insecure Design

Insecure Design is the only OWASP Top 10 category that addresses security problems that cannot be fixed with better implementation — the architecture itself is flawed.

How It Happens

A password reset flow generates reset links using the format https://app.example.com/reset?token=USER_ID-TIMESTAMP-RANDOM. If the random component is insufficiently random (a few thousand possibilities rather than cryptographically random 128-bit tokens), an attacker can brute-force valid reset tokens for any user.

Another pattern: a feature is designed without considering adversarial use. An API rate limit was not designed into a login endpoint — the feature works correctly but allows brute-force attacks because no designer considered that scenario.

Insecure Design is a failure at the requirements and design phase. The security gap cannot be patched — the feature must be redesigned.

Remediation

• Threat modeling during the design phase. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is a structured method for identifying threats before implementation.
• Security design patterns: Document and reuse patterns for common security requirements — password reset flows, API rate limiting, session management. Reviewed patterns prevent reinventing security features with new vulnerabilities each time.
• Security requirements in user stories: Security acceptance criteria belong in the backlog alongside functional requirements. "The password reset token must be cryptographically random, at least 128 bits, and expire within 15 minutes" is a security requirement that prevents this category of insecure design.

A05: Security Misconfiguration

Security misconfiguration is the most widespread OWASP category. Secure software running with insecure configuration provides minimal actual protection.

How It Happens

• Cloud storage buckets (S3, GCS, Azure Blob) left publicly readable — common cause of data breaches
• Default credentials unchanged: admin/admin, admin/password on database admin interfaces
• Debug mode enabled in production: stack traces, environment variables, and internal paths exposed to users
• CORS policy configured as Access-Control-Allow-Origin: * when the application handles authenticated requests
• Unnecessary ports, services, or interfaces exposed

Remediation

• Minimal installation: Run only the services, ports, and features needed in production. Disable everything else.
• Configuration hardening checklists: Document the secure configuration baseline for every component (database, web server, container runtime, cloud services). Validate against the baseline regularly.
• Infrastructure as Code: Define infrastructure configuration in version-controlled IaC (Terraform, Pulumi). Peer review catches misconfigurations before deployment; drift detection catches runtime changes.
• Security headers: HTTP security headers prevent client-side attacks. Minimum baseline: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options.

A06: Vulnerable and Outdated Components

Modern applications contain hundreds of third-party dependencies. Each dependency's vulnerabilities are inherited by the application that uses them.

How It Happens

A Node.js application uses lodash 4.17.15. A prototype pollution vulnerability (CVE-2020-8203) was published for this version. The development team patched their own code but did not update the dependency — their application remained vulnerable for months.

The Log4Shell vulnerability (CVE-2021-44228) in the Java Log4j library demonstrated the scale of this problem — millions of Java applications were affected because they used a widely-adopted logging library.

Remediation

• Dependency inventory: Know every third-party library in your application and its version. SBOM (Software Bill of Materials) documents this inventory for auditing and vulnerability response.
• Automated dependency scanning: npm audit for Node.js, pip-audit for Python, Dependabot or Renovate for automated pull requests when vulnerabilities are published.
• OWASP Dependency-Check: Language-agnostic scanner that identifies known vulnerabilities in project dependencies.
• End-of-life tracking: Libraries no longer receiving security updates (EOL) are permanently vulnerable. Plan migrations before EOL dates.

A07: Identification and Authentication Failures

Authentication failures allow attackers to assume other users' identities — account takeover is the direct consequence.

How It Happens

• No rate limiting or account lockout on login endpoints — enables brute-force and credential stuffing attacks
• Weak or predictable session tokens — enables session prediction attacks
• Passwords stored in recoverable form — enables credential extraction if the database is compromised
• Missing MFA on high-privilege accounts — enables account takeover with only stolen credentials

Remediation

• Credential stuffing protection: Rate limiting and CAPTCHA on login endpoints. IP-based rate limiting is insufficient (attackers use distributed botnets) — pair with device fingerprinting and behavioral analysis.
• Strong session management: Session IDs must be cryptographically random (128+ bits of entropy). Regenerate session IDs after authentication.
• MFA for sensitive operations: Require MFA for admin accounts, payment changes, and data export operations at minimum.
• Modern authentication protocols: OAuth 2.0 + OIDC for delegated authorization. Avoid building custom authentication flows when mature platforms (Auth0, Keycloak) implement these correctly.

A08: Software and Data Integrity Failures

Software and data integrity failures occur when code or data is used without verifying that it has not been modified by an unauthorized party.

How It Happens

A CI/CD pipeline pulls a third-party GitHub Action without pinning to a specific commit hash. The action's publisher pushes malicious code to the same tag — the pipeline executes the malicious code on the next run.

CDN-hosted JavaScript loaded without Subresource Integrity (SRI) can be served with malicious modifications by a compromised CDN node.

Remediation

• Pin dependencies to specific versions or hashes: In package managers, prefer exact version pins over ranges for production dependencies. In CI/CD, pin GitHub Actions and similar tools to full commit SHAs.
• Subresource Integrity (SRI): For CDN-hosted CSS and JavaScript, add integrity attributes with cryptographic hashes. Browsers verify the hash before executing the resource.
• Code signing: Sign software artifacts and verify signatures before deployment. Sigstore/Cosign for container images; GPG signing for packages.
• SLSA framework: Supply-chain Levels for Software Artifacts provides a graduated framework for provenance verification.

A09: Security Logging and Monitoring Failures

Without adequate logging and monitoring, breaches go undetected. IBM's Cost of a Data Breach report consistently shows that breaches detected quickly — within 30 days — cost significantly less than those discovered after months.

How It Happens

• Failed login attempts are not logged — credential stuffing attacks run undetected
• Database queries are monitored for performance but not for unusual access patterns
• Log files are stored locally and overwritten — forensic investigation impossible after incident

Remediation

• Log all security-relevant events: Authentication (success and failure), authorization decisions, data access, data modification, and administrative actions. Include: timestamp, user ID, action, target resource, IP address, result.
• Centralized logging (SIEM): Route logs to a system where they cannot be modified or deleted by a compromised application — Splunk, Elastic Security, Microsoft Sentinel.
• Alerting on anomalies: Define alert conditions for patterns that indicate attacks — multiple failed logins from the same IP, sequential access to predictable resource IDs (IDOR probe), access from unusual geographic locations.
• Log integrity: Logs are evidence in incident investigations. Protect log integrity with append-only storage and cryptographic chaining where regulations require tamper evidence.

A10: Server-Side Request Forgery (SSRF)

SSRF allows attackers to induce the server-side application to make HTTP requests to an arbitrary destination — including internal services, cloud metadata endpoints, and other internal infrastructure.

How It Happens

An application allows users to specify a URL for an external webhook or to import data from a URL. The application fetches the URL server-side without validating the destination.

An attacker submits http://169.254.169.254/latest/meta-data/iam/security-credentials/ — the AWS Instance Metadata Service endpoint. If the server is running on AWS EC2, it fetches and returns the instance's IAM credentials, giving the attacker access to all AWS services the instance is authorized for.

Remediation

• Input validation for URLs: Reject private IP ranges (10.x.x.x, 192.168.x.x, 172.16-31.x.x, 169.254.x.x, ::1, fe80::), localhost, and internal hostnames. Validate the scheme (allow only http/https, block file://, dict://, gopher://).
• DNS rebinding protection: An attacker-controlled DNS record can initially resolve to a permitted IP, then rebind to an internal IP. Validate the resolved IP address, not just the hostname.
• Allowlist-based URL validation: If the application only needs to fetch from specific external services, maintain an allowlist of permitted destinations.
• Network segmentation: The server making outbound requests should have minimal network access. An application server does not need direct access to internal databases, administrative interfaces, or cloud metadata services from its outbound networking configuration.

Applying OWASP Top 10 in Practice

Addressing the OWASP Top 10 systematically:

Assess: Evaluate current applications against each category. SAST tools (Semgrep, CodeQL, SonarQube) detect many OWASP vulnerabilities in source code. DAST tools (OWASP ZAP, Burp Suite) test running applications.

Prioritize: Rank remediation by business impact. For most applications, Broken Access Control (A01) and Injection (A03) carry the highest risk.

Remediate and verify: Fix vulnerabilities and validate fixes with re-testing. Document remediation in issue trackers with links to the original finding.

Integrate into SDLC: OWASP Top 10 coverage should be part of the development process, not just periodic audits. SAST in CI/CD, developer security training, and security design review for new features prevent vulnerabilities from reaching production.

Regular penetration testing validates that automated tools and manual code review are working — and finds the vulnerabilities that tools miss.