The OWASP Top 10 Explained in Plain English (2026)

In plain English. The application lets a user do or see something they are not authorized to. This is now the most common high-impact web flaw.

Real-world example. A user changes the account ID in a URL from their own to a stranger's and the app happily returns the stranger's invoice — no permission check at all.

The defense. Enforce authorization on the server for every request, deny by default, and never trust an identifier supplied by the client. Test it with a low-privilege account, not an admin one.

ATT&CK link. Maps loosely to Valid Accounts (T1078) and privilege abuse once a foothold exists.

In plain English. Sensitive data is exposed because it was not encrypted, was encrypted weakly, or the keys were mishandled.

Real-world example. Passwords stored as unsalted MD5, or session tokens sent over plain HTTP on an internal admin tool that someone assumed nobody could reach.

The defense. Encrypt sensitive data in transit (TLS everywhere) and at rest, use modern algorithms and a vetted library, hash passwords with bcrypt/argon2, and manage keys in a secrets manager — never in source.

ATT&CK link. Feeds Adversary-in-the-Middle (T1557) and credential theft.

In plain English. Untrusted input is interpreted as a command. SQL injection is the classic, but the same flaw covers OS command, LDAP, and NoSQL injection.

Real-world example. A login form that builds a query by string concatenation, so typing ' OR '1'='1 into the username field logs an attacker in as the first user in the table.

The defense. Use parameterized queries / prepared statements and ORMs that bind parameters. Validate and encode output. Never build a query or shell command by concatenating user input.

ATT&CK link. A textbook Exploit Public-Facing Application (T1190).

In plain English. The flaw is in the design itself, not the code. No amount of clean implementation fixes a feature that was unsafe by concept.

Real-world example. A password-reset flow that emails a 4-digit code with no rate limit and no lockout — the implementation is bug-free, but the design lets an attacker brute-force the code.

The defense. Threat-model features before building them, define abuse cases alongside use cases, and apply secure-by-design patterns (rate limits, lockouts, defense in depth) at the architecture stage.

ATT&CK link. Often the root cause behind Brute Force (T1110) success.

In plain English. Insecure default settings, verbose error messages, unnecessary features left enabled, or missing hardening.

Real-world example. A cloud storage bucket left publicly readable, a debug endpoint shipped to production, or default admin credentials never changed.

The defense. Harden every environment from a documented baseline, disable unused features, suppress stack traces in production, and verify configuration with automated checks in CI.

ATT&CK link. Enables Exploit Public-Facing Application (T1190) and exposure of secrets.

In plain English. Using a library, framework, or runtime with a known vulnerability — including transitive dependencies you did not choose directly.

Real-world example. An app pinned to a years-old version of a serialization library with a published remote-code-execution CVE that an attacker exploits with a public proof-of-concept.

The defense. Maintain a dependency inventory (SBOM), run npm audit / pip-audit / Dependabot, patch on a cadence, and remove components you no longer use.

ATT&CK link. Exploitation for Client Execution (T1203) and public-facing exploitation.

In plain English. Weaknesses in how the app proves who a user is — weak passwords, broken session handling, missing MFA, or credential stuffing exposure.

Real-world example. No rate limit on login plus no MFA, so a leaked password list from another breach is replayed until accounts fall.

The defense. Require MFA on sensitive accounts, rate-limit and lock out on failed logins, rotate and invalidate sessions properly, and check passwords against known-breached lists.

ATT&CK link. Brute Force (T1110) and Valid Accounts (T1078).

In plain English. Code or data is trusted without verifying it was not tampered with — insecure deserialization, unsigned updates, or a compromised CI/CD pipeline.

Real-world example. A build pipeline that pulls a dependency from an unverified source, letting a poisoned package execute in your production build (a supply-chain attack).

The defense. Verify signatures on dependencies and updates, lock and review your CI/CD, use integrity checks (subresource integrity, signed artifacts), and never deserialize untrusted data into objects.

ATT&CK link. Supply Chain Compromise (T1195).

In plain English. You cannot detect or investigate an attack because the right events were not logged, or the logs are not monitored.

Real-world example. An attacker enumerates accounts for weeks, but failed-login and authorization-denied events were never logged, so nobody noticed until customer data appeared for sale.

The defense. Log authentication, authorization, and high-value actions with enough context to investigate, centralize logs, alert on anomalies, and test that your alerts actually fire.

ATT&CK link. The absence that lets every other ATT&CK technique go unnoticed.

In plain English. The app fetches a URL supplied or influenced by the user, letting an attacker make the server request internal resources it should not reach.

Real-world example. An image-import feature that fetches any URL the user provides, which an attacker points at a cloud metadata endpoint to steal instance credentials.

The defense. Validate and allow-list outbound destinations, block requests to internal and metadata IP ranges, and do not let user input choose the host of a server-side request.

ATT&CK link. A pivot toward Cloud Instance Metadata API abuse and internal recon.