OWASP Top 10 Explained: The Most Critical Web Application Security Risks

The Open Web Application Security Project, better known as OWASP, publishes a regularly updated list of the ten most critical security risks facing web applications. This list -- the OWASP Top 10 -- has become the de facto standard for web application security awareness. It is referenced in security policies, compliance frameworks, developer training programs, and penetration testing methodologies worldwide.

Understanding the OWASP Top 10 is essential whether you are a developer building web applications, a security professional testing them, or a business leader responsible for protecting customer data. This guide explains each of the ten risks in plain language, provides real-world context for how attackers exploit them, and outlines practical defenses.

A01: Broken Access Control

Broken access control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do. Instead of being limited to their own data and permissions, users can access other accounts, view sensitive files, modify data they should not touch, or perform administrative actions.

How attackers exploit it: The most common technique is Insecure Direct Object Reference (IDOR). An attacker notices that their account profile is loaded from https://example.com/api/user/1042 and simply changes the number to 1043 to access someone else's profile. Other attack vectors include modifying hidden form fields, tampering with JWT tokens to escalate privileges, or accessing admin endpoints that lack authorization checks entirely.

Real-world context: In 2019, a major financial institution exposed millions of customer records because its API endpoints verified that a user was logged in but never checked whether that user was authorized to view the specific record being requested. The flaw was trivially exploitable by changing an account number in the URL.

How to defend:

• Implement access controls on the server side, never relying on client-side restrictions alone.
• Deny access by default -- require explicit grants rather than assuming access is permitted.
• Enforce record-level ownership checks so users can only access their own data.
• Log and alert on access control failures to detect probing attempts.
• Disable directory listing on web servers and ensure metadata files like .git are not accessible.

A02: Cryptographic Failures

Previously called "Sensitive Data Exposure," cryptographic failures refer to weaknesses related to cryptography (or the lack of it) that lead to the exposure of sensitive data. This includes transmitting data in clear text, using weak or obsolete algorithms, improperly managing encryption keys, or failing to encrypt data that requires protection.

How attackers exploit it: An attacker performing a man-in-the-middle attack on an unencrypted HTTP connection can capture login credentials, session tokens, and personal data in transit. Against stored data, attackers who gain database access may find passwords hashed with weak algorithms like MD5 or SHA-1 without salting, making them trivially crackable with precomputed rainbow tables.

Real-world context: The 2017 Equifax breach exposed 147 million records in part because sensitive data was not adequately encrypted at rest and the organization failed to patch a known vulnerability in a timely manner. Breaches involving improperly stored passwords -- hashed with outdated algorithms or stored in plain text -- continue to make headlines regularly.

How to defend:

• Classify data by sensitivity and apply appropriate protections to each tier.
• Encrypt all data in transit using TLS 1.2 or higher. Enforce HTTPS everywhere with HSTS headers.
• Encrypt sensitive data at rest using strong, current algorithms (AES-256 for symmetric encryption, RSA-2048 or higher for asymmetric).
• Hash passwords with dedicated password-hashing algorithms like bcrypt, scrypt, or Argon2, never with general-purpose hash functions.
• Manage encryption keys securely using a key management service. Rotate keys on a defined schedule.
• Do not store sensitive data you do not need. Data you do not have cannot be breached.

A03: Injection

Injection flaws occur when an application sends untrusted data to an interpreter as part of a command or query. The most well-known variant is SQL injection, but injection also affects LDAP, XPath, NoSQL, OS commands, SMTP headers, and any other system where user input is concatenated into an interpreted string.

How attackers exploit it: In a classic SQL injection attack, an attacker enters something like ' OR 1=1 -- into a login form's password field. If the application concatenates this input directly into a SQL query without sanitization, the resulting query bypasses authentication. More sophisticated attacks extract entire databases, modify or delete data, or execute operating system commands through the database server.

Real-world context: SQL injection has been behind some of the largest data breaches in history. The 2008 Heartland Payment Systems breach, which compromised 130 million credit card numbers, was initiated through a SQL injection attack. Despite being well understood for over two decades, injection remains prevalent because developers continue to build queries using string concatenation rather than parameterized statements.

How to defend:

• Use parameterized queries (prepared statements) for all database interactions. This is the single most effective defense against SQL injection.
• Use ORM frameworks that generate parameterized queries automatically.
• Validate and sanitize all input on the server side. Apply allowlists rather than denylists where possible.
• Escape special characters when parameterized queries are not an option (for example, in dynamic table names).
• Apply the principle of least privilege to database accounts so that even a successful injection limits the attacker's access.

A04: Insecure Design

Insecure design is a broad category addressing flaws that stem from missing or ineffective security controls at the design level. Unlike implementation bugs that can be fixed with a code patch, insecure design means the application was never architected to handle certain threats in the first place.

How attackers exploit it: Consider an e-commerce site that applies discount codes on the client side and trusts the final price sent by the browser. An attacker simply modifies the request to set the price to zero. The application has no server-side validation because the developers never designed for this threat. Another example is a password reset flow that sends a four-digit code with no rate limiting -- an attacker can brute-force all 10,000 combinations in minutes.

Real-world context: Many business logic vulnerabilities fall into this category. A ride-sharing application that allows unlimited promo code usage, a banking application that does not verify the source account has sufficient funds before initiating a transfer, or an API that returns full user records when the front end only needs a name -- these are all design-level failures.

How to defend:

• Incorporate threat modeling into the development lifecycle. Identify potential threats during the design phase and build controls to address them.
• Use secure design patterns and reference architectures.
• Write abuse cases alongside use cases -- for every feature, ask "how could an attacker misuse this?"
• Implement server-side validation for all business logic, never trusting client-side controls.
• Conduct design reviews with security-focused team members before implementation begins.

A05: Security Misconfiguration

Security misconfiguration is the most commonly seen vulnerability in real-world assessments. It encompasses default configurations left unchanged, unnecessary features enabled, overly permissive permissions, missing security headers, verbose error messages that leak information, and unpatched systems.

How attackers exploit it: An attacker discovers that a web application is running with debug mode enabled in production, exposing detailed stack traces that reveal the application framework, database type, and internal file paths. They find an exposed admin console at /admin protected only by default credentials. They notice that directory listing is enabled, revealing backup files that contain database credentials.

Real-world context: The 2019 Capital One breach was facilitated in part by a misconfigured web application firewall that allowed an attacker to exploit a server-side request forgery vulnerability and access cloud metadata containing credentials. Misconfiguration is especially common in cloud environments, where the number of settings and services creates a vast surface area for error.

How to defend:

• Establish a hardening process that is applied to all environments (development, staging, production) consistently.
• Remove or disable all unused features, frameworks, sample applications, and documentation from production systems.
• Automate configuration management using infrastructure-as-code tools to ensure consistency and detect drift.
• Send security headers (Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security) in all responses.
• Review cloud storage permissions carefully -- S3 buckets, Azure Blob containers, and GCS buckets should not be publicly accessible unless explicitly intended.
• Run regular vulnerability scans and configuration audits.

A06: Vulnerable and Outdated Components

Applications commonly rely on open-source libraries, frameworks, and components. When these components contain known vulnerabilities and are not updated, the entire application inherits those vulnerabilities. Vulnerable and outdated components are a supply chain risk that affects nearly every modern application.

How attackers exploit it: Attackers monitor public vulnerability databases (like the National Vulnerability Database) and scan for applications running vulnerable versions of popular components. The Log4Shell vulnerability (CVE-2021-44228) in the Apache Log4j library is a prime example -- within hours of public disclosure, attackers were scanning the internet for vulnerable applications and exploiting them at massive scale.

Real-world context: The Equifax breach of 2017 was caused by a known vulnerability in Apache Struts (CVE-2017-5638) that had a patch available for months before the breach occurred. The organization simply failed to apply it. This pattern -- known vulnerability, available patch, delayed remediation -- is behind a disproportionate number of major breaches.

How to defend:

• Maintain a software bill of materials (SBOM) that inventories all components and their versions.
• Continuously monitor for new vulnerabilities in your dependencies using tools like Dependabot, Snyk, or OWASP Dependency-Check.
• Establish a patch management process with defined SLAs for applying security updates based on severity.
• Remove unused dependencies. Every component you include expands your attack surface.
• Prefer components that are actively maintained and have strong security track records.

A07: Identification and Authentication Failures

Identification and authentication failures cover weaknesses in confirming a user's identity, managing sessions, and handling credentials. This includes allowing weak passwords, exposing session identifiers in URLs, failing to implement multi-factor authentication, and mishandling password recovery.

How attackers exploit it: Credential stuffing attacks use lists of username-password pairs leaked from previous breaches to attempt logins on other services, exploiting the fact that many people reuse passwords. Session fixation attacks trick users into authenticating with a session ID that the attacker already knows. Brute-force attacks succeed when applications lack rate limiting or account lockout.

Real-world context: Credential stuffing is responsible for billions of unauthorized login attempts every year. In 2020, a major food delivery platform suffered a credential stuffing attack that compromised thousands of customer accounts, which were then used to place fraudulent orders. The platform did not require multi-factor authentication or detect anomalous login patterns.

How to defend:

• Implement multi-factor authentication (MFA) for all user accounts, especially administrative accounts.
• Enforce password complexity requirements and check new passwords against known breached password lists.
• Implement rate limiting, progressive delays, and account lockout to prevent brute-force and credential stuffing attacks.
• Use secure session management: generate long, random session IDs, transmit them only in cookies with Secure, HttpOnly, and SameSite attributes, and invalidate sessions on logout.
• Never expose session identifiers in URLs or log files.

A08: Software and Data Integrity Failures

Software and data integrity failures occur when code or infrastructure does not protect against integrity violations. This includes using software updates without verifying their authenticity, relying on untrusted content delivery networks or package repositories, and implementing insecure CI/CD pipelines that allow unauthorized code to reach production.

How attackers exploit it: Supply chain attacks compromise a widely used library or build system, injecting malicious code that is then distributed to all downstream users. The SolarWinds attack of 2020 is the most notorious example -- attackers compromised the build process of SolarWinds' Orion software, inserting a backdoor that was distributed to approximately 18,000 customers, including multiple U.S. government agencies.

Real-world context: Beyond SolarWinds, the 2021 Codecov breach demonstrated how a compromised CI/CD tool could expose secrets from thousands of organizations. The 2021 ua-parser-js npm package compromise showed how a single hijacked maintainer account could inject malicious code into a package downloaded millions of times per week.

How to defend:

• Verify the integrity of all software updates, libraries, and packages using digital signatures or checksums.
• Use package lock files (like package-lock.json or Pipfile.lock) to pin dependency versions.
• Secure your CI/CD pipeline with access controls, code review requirements, and integrity checks.
• Implement code signing for your own releases.
• Use tools like Sigstore or in-toto to create verifiable provenance for your build artifacts.

A09: Security Logging and Monitoring Failures

Security logging and monitoring failures occur when an application does not log security-relevant events, does not monitor those logs for suspicious activity, or does not respond to detected incidents in a timely manner. Without adequate logging and monitoring, breaches go undetected, and forensic investigation after an incident becomes difficult or impossible.

How attackers exploit it: Attackers directly benefit from poor logging because it allows them to operate undetected for extended periods. The average time to detect a breach is still measured in months, not hours. If failed login attempts are not logged, an attacker can brute-force credentials without triggering any alerts. If API access is not monitored, data exfiltration can occur gradually without notice.

Real-world context: Many major breaches were discovered not by the victim organization's own monitoring but by external parties -- law enforcement, security researchers, or customers noticing their data for sale on the dark web. The Marriott breach disclosed in 2018 involved unauthorized access dating back to 2014 -- four years of undetected compromise, largely due to inadequate monitoring.

How to defend:

• Log all authentication events (successful and failed), access control failures, input validation failures, and security-relevant application events.
• Ensure logs include sufficient context: timestamps, source IP addresses, user identifiers, and the action attempted.
• Protect log integrity -- store logs in append-only storage and forward them to a centralized logging system (SIEM).
• Establish alerting rules for suspicious patterns: multiple failed logins, access from unusual locations, privilege escalation attempts.
• Define and practice an incident response plan so that detected events lead to timely action.
• Conduct regular reviews of logs and alerts to ensure the monitoring system is functioning as intended.

A10: Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF) occurs when a web application fetches a remote resource based on a user-supplied URL without validating the destination. An attacker can abuse this functionality to make the server send requests to unintended locations, such as internal services, cloud metadata endpoints, or other back-end systems that are not directly accessible from the internet.

How attackers exploit it: An attacker finds a feature that accepts a URL -- for example, a profile picture upload that fetches an image from a provided URL, or a webhook configuration field. Instead of supplying a legitimate URL, the attacker provides http://169.254.169.254/latest/meta-data/ (the AWS metadata endpoint) and the server dutifully fetches it, returning cloud credentials that the attacker can use to access other AWS services.

Real-world context: The Capital One breach mentioned earlier was an SSRF attack. The attacker exploited a misconfigured web application firewall to make server-side requests to the AWS metadata service, obtaining temporary credentials that granted access to S3 buckets containing over 100 million customer records. SSRF has gained prominence with the widespread adoption of cloud services, where metadata endpoints provide powerful credentials to any process that can reach them.

How to defend:

• Validate and sanitize all user-supplied URLs on the server side.
• Use allowlists for permitted URL schemes, domains, and IP ranges. Block requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata addresses.
• Disable unnecessary URL fetching functionality.
• In cloud environments, use IMDSv2 (which requires a token obtained through a PUT request) instead of IMDSv1 to protect metadata endpoints from SSRF attacks.
• Segment networks so that web-facing applications cannot reach internal services directly.

Why the OWASP Top 10 Matters

The OWASP Top 10 is not just an academic exercise. It serves as a common language for developers, security teams, auditors, and executives to discuss web application security risks. Many compliance frameworks and security standards reference it directly. PCI DSS, for example, requires organizations to address OWASP Top 10 vulnerabilities in their web applications.

For developers, understanding these risks leads to more secure code from the start. For security professionals, the list provides a structured methodology for testing. For organizations, it offers a prioritized view of where to focus limited security resources.

The most important takeaway is that these vulnerabilities are well understood and preventable. Every risk on this list has known, effective countermeasures. The challenge is not a lack of knowledge but a lack of consistent application -- and that is an organizational and cultural problem as much as a technical one.

To learn more, read our free Ethical Hacking textbook -- covering penetration testing from beginner to advanced.