OWASP Top 10

Broken Access Control

Access control failures occur when users can act outside their intended permissions — accessing other users' accounts, viewing sensitive data, performing privileged functions, or manipulating access control mechanisms. The classic example is Insecure Direct Object Reference: changing /account?id=12345 to /account?id=12346 and accessing another user's data because the server only checks whether you are authenticated, not whether the resource belongs to you.

Why it's #1: 94% of applications tested had some form of broken access control. It is the highest-impact category because it directly exposes data and functionality that should be inaccessible. Defences: server-side access control checks on every request, deny by default, rate limiting on access control failures.

Cryptographic Failures

Previously called "Sensitive Data Exposure" — the rename in 2021 acknowledged that the root cause is cryptographic failure, not just exposure. This covers data transmitted without encryption (HTTP instead of HTTPS), data stored without encryption (plaintext passwords in a database), weak or deprecated algorithms (MD5 for password hashing, RC4 for transport encryption), and improper key management (hardcoded encryption keys in source code).

Real impact: The 2013 Adobe breach exposed 153 million user records — passwords encrypted with 3DES ECB mode (same plaintext produced same ciphertext, allowing pattern analysis) rather than hashed. The encryption was technically present but cryptographically useless. Defences: TLS everywhere, bcrypt or Argon2 for passwords, no secrets in code.

Injection

Injection occurs when untrusted data is sent to an interpreter as part of a command or query. SQL injection is the most well-known — inserting SQL syntax into an input field causes the database to execute attacker-controlled queries. Command injection inserts OS commands. LDAP injection targets directory services. Template injection targets server-side rendering engines. The root cause is always the same: user input is not separated from the command structure that processes it.

Why it dropped from #1: Not because it became less dangerous — SQL injection is still critical when present — but because parameterised queries and modern ORMs have significantly reduced its prevalence in well-maintained applications. Legacy codebases remain vulnerable. Lesson 38 covers SQL injection in depth.

Insecure Design

A new category in 2021 that separates design flaws from implementation bugs. A perfectly implemented feature can still be insecure if the design itself is flawed. A password reset flow that emails a link without any expiry is a design flaw. An application that allows unlimited guesses on a PIN with no throttling is a design flaw. These cannot be fixed with a patch — they require redesigning the feature from scratch.

The distinction matters: Injection is an implementation bug — a developer wrote code incorrectly. Insecure design is an architectural decision — the specification itself was insecure. Fixing implementation bugs is fast. Fixing design flaws requires planning, development time, and often user migration. The earlier a design flaw is caught, the cheaper it is to fix.

Security Misconfiguration

The entire category of misconfiguration issues from Section III — now applied to web applications and their supporting infrastructure. Default credentials on admin panels. Unnecessary features enabled. Verbose error messages exposing stack traces and database queries. Directory listing enabled on web servers. Missing security headers. Publicly accessible cloud storage buckets. Each of these appeared in real breaches before the organisations realised the configuration was exposed.

The Capital One 2019 breach — 106 million customer records compromised — traced to a misconfigured web application firewall that allowed SSRF (server-side request forgery) to reach the AWS metadata endpoint, which returned credentials for the IAM role running the application. Misconfiguration remains the easiest class of finding to prevent and the most consistently overlooked.

Vulnerable and Outdated Components

Libraries, frameworks, and other software components run with the same privileges as the application. Using a component with a known vulnerability means the application inherits that vulnerability regardless of how well the application itself is written. The 2017 Equifax breach — 147 million records — was caused by an unpatched Apache Struts vulnerability (CVE-2017-5638) that had a public exploit available two months before the breach. The patch existed. It was not applied.

Modern applications have hundreds of dependencies. npm packages, Python requirements, Ruby gems, Maven dependencies — each with their own dependency tree. Software composition analysis tools (Snyk, Dependabot, OWASP Dependency-Check) automate discovery of vulnerable components. Without automation, manual tracking across hundreds of dependencies is not realistic.

Identification and Authentication Failures

Covers all weaknesses in how applications identify and authenticate users: default credentials not changed, weak passwords permitted, missing account lockout, insecure password recovery flows, session tokens not invalidated on logout, session IDs exposed in URLs, missing MFA on sensitive operations. The practical consequence of any of these is that an attacker gains access to accounts they should not be able to reach — either by guessing, brute forcing, or stealing session state.

Session IDs in URLs are a particularly consequential misconfiguration. If an application includes the session token in the URL (/dashboard?sessid=abc123), it appears in server logs, browser history, and Referer headers sent to third-party sites — exposing it to anyone who can read those logs. Session tokens belong exclusively in cookies with HttpOnly set. Lesson 40 and 41 cover this in depth.

Software and Data Integrity Failures

Covers situations where code and infrastructure do not protect against integrity violations — including insecure deserialisation and CI/CD pipeline integrity failures. Insecure deserialisation occurs when applications reconstruct objects from user-supplied serialised data without verifying integrity — allowing attackers to craft malicious objects that execute code when deserialised. The SolarWinds attack (Lesson 28) was a software integrity failure at the supply chain level — malicious code inserted into a trusted build pipeline.

Auto-update mechanisms that fetch updates without signature verification are a straightforward integrity failure. An attacker who can intercept or replace the update file can deliver arbitrary code to every instance of the application. npm packages installed without integrity checking (the --ignore-scripts flag), and CDN-hosted scripts loaded without subresource integrity hashes, are both covered by this category.

Security Logging and Monitoring Failures

Applications that do not log security-relevant events — authentication attempts, access control failures, input validation errors — cannot detect attacks in progress or reconstruct what happened during a breach. The Verizon DBIR consistently shows that most breaches take months to detect, during which the attacker operates freely. Missing logging is a direct contributor to that dwell time.

What must be logged: every authentication attempt (success and failure) with username and source IP, every access control failure with the requested resource, every input validation failure, every high-value transaction. What must not be logged: passwords, session tokens, credit card numbers, PII. Logging sensitive data in plaintext is itself a security failure — breaches of log files have exposed credentials exactly this way.

Testing approach: Attempt a brute force against the login — then check whether any alert was generated. Try to access a forbidden resource — then check whether the access control failure was logged. If neither produced a log entry, the application has a logging failure that belongs in the report.

Server-Side Request Forgery (SSRF)

SSRF occurs when a web application fetches a remote resource based on a URL supplied by the user — and does not validate or restrict what URLs are permitted. An attacker can supply an internal IP address or a cloud metadata endpoint URL, causing the server to make the request on their behalf. The server trusts itself and its internal network, so SSRF effectively turns the application into a proxy for reaching internal systems that should never be reachable from the internet.

The Capital One breach used SSRF against the AWS metadata endpoint at 169.254.169.254 — a special IP that returns temporary credentials for the IAM role attached to the running instance. In cloud environments, SSRF to the metadata endpoint is a critical finding that can expose cloud credentials and entire cloud account access. AWS now requires IMDSv2 by default, which makes this specific attack path significantly harder — but SSRF to internal services remains a valid and frequent finding.