Web Application Security Vulnerabilities: The Complete Taxonomy

Web application vulnerabilities have remained recognisably the same for twenty years. The names change, the payloads evolve, the framework defaults patch some of the obvious ones, but the underlying classes (someone trusted input they should not have, mixed code and data in the same channel, skipped a check, or got confused about whose identity owned the request, as catalogued in CWE-1000 Research Concepts) recur in every audit I have ever run.

This is the map I refer engineers to when they ask "what should I learn first?" or "what are we actually defending against?". Each section is a single attack class with a one-paragraph summary and a link to a deeper article. The intent is breadth first, then depth on whichever class is biting you this week.

A note on framing: I cover how each attack works and how to defend against it with equal weight. Defenders who do not understand the offensive mechanics ship "mitigations" that do not mitigate. The cheapest way to write secure code is to know exactly how the wrong code gets exploited.

The shape of the map

I group these into five families based on the underlying error, not the OWASP ranking:

Five families, fifteen classes. There are more, but these fifteen account for nearly every web compromise I have personally handled or read a credible post-mortem on.

Injection family

SQL injection

User input gets concatenated into a database query instead of being passed as a parameter, so the input can change the query's shape. An attacker can read arbitrary tables, modify rows, dump password hashes, sometimes write files to the database server, and in some configurations execute operating-system commands. It is the oldest class on this list and still in the top three of nearly every annual breach report, ranked A03 in the current OWASP Top 10.

Deep dive: SQL injection: variants, exploitation, and defence.

Cross-site scripting (XSS)

The application returns user-controlled data into an HTML page without encoding it, so an attacker's input lands in a victim's browser as executable JavaScript. The attacker's script runs with the victim's session: it can read the DOM, exfiltrate cookies (if they are not HttpOnly), make requests as the victim, or rewrite the page to phish credentials. Reflected, stored, and DOM-based XSS each have their own mechanics. The fix is consistent output encoding plus a Content-Security-Policy that blocks inline script by default.

Deep dive: Cross-site scripting: variants, exploitation, and defence. Tooling: best XSS tools 2026.

Cross-site request forgery (CSRF)

A victim who is logged in to a target site visits an attacker-controlled page. The attacker's page makes a request to the target (often a form POST), and the browser dutifully attaches the victim's session cookie. If the target acts on the request without checking that it came from its own pages, the attacker has effectively performed an action as the victim: change email, transfer funds, add an admin user. The classic defence is a CSRF token tied to the session; modern browsers help by treating cookies as SameSite=Lax by default, but that default does not cover every case.

Deep dive: Cross-site request forgery. Tooling: best CSRF tools 2026.

Remote code execution (RCE)

The attacker gets the server to execute code of their choosing. This is the worst-case outcome of many other bugs (file upload, deserialization, template injection, SSRF chained to internal services, command injection in a shell wrapper). The exploit varies wildly; the consequence is uniform: shell on the host, lateral movement, credential theft, persistence. Most RCEs I have seen in production trace back to a single trusted-input mistake that escaped into a shell, an eval, or a Runtime.exec call. The dense sub-classes are OS command injection, argument injection, and server-side template injection.

Deep dive: Remote code execution. Tooling: best RCE tools 2026.

Server-side request forgery (SSRF)

The application takes a URL from the user and fetches it server-side (image proxy, webhook callback, URL preview, PDF generator). An attacker supplies an internal URL: http://localhost:8080/admin, http://169.254.169.254/latest/meta-data/ (cloud metadata SSRF), file:///etc/passwd, or a gopher:// URL that forges arbitrary TCP traffic. The 2019 Capital One breach was, at its root, SSRF against the EC2 metadata service. Defence is allow-listing destination hosts and refusing link-local, loopback, and metadata IPs at the HTTP-client layer. Variants worth knowing: blind SSRF and DNS rebinding SSRF.

Deep dive: Server-side request forgery. Tooling: best SSRF tools 2026.

XML external entities (XXE)

An XML parser is configured to resolve external entities, and the application accepts user-controlled XML. The attacker defines an entity that references a local file or an internal URL, and the parsed XML reveals its contents in the response. XXE has been heavily mitigated by modern parser defaults (libxml2 disabled external entities by default in 2.9.0, released 2012), but legacy code and SOAP-era frameworks still ship with it on. The fix is one line of parser config, always. Related variants: blind XXE OOB, XInclude attacks, and the entity-expansion DoS class billion laughs.

Deep dive: XML external entities. Tooling: best XXE tools 2026.

Trust and identity family

Authentication and session attacks

Everything that goes wrong between "user enters credentials" and "server trusts the session token thereafter". Credential stuffing against reused passwords, brute force against missing rate limits, password reset tokens generated with Math.random(), session fixation where the attacker plants a known session ID then waits for the victim to authenticate, session IDs leaked in URLs and logged by the CDN, JWTs with alg: none accepted as valid. There is no single attack here, there is a family of failures around the same primitive: proving who you are.

Clickjacking

The attacker iframes the target site inside a malicious page, layers an opaque element over it (or uses opacity:0), and tricks the victim into clicking what they think is the attacker's UI but is in fact a sensitive button on the target. "Confirm transfer", "delete account", "grant permission". The defence is the X-Frame-Options header (or Content-Security-Policy: frame-ancestors) telling the browser the page cannot be framed by third parties. Easy to fix, easy to forget on a new endpoint.

Deep dive: Clickjacking. Tooling: best clickjacking tools 2026.

Session attacks via XSS

A close relative of XSS that deserves its own attention: once a script runs in the victim's browser, the next step is almost always to steal the session. Stealing session cookies via XSS walks the full chain (cookie exfil, AiTM proxies, infostealer malware) and the modern defences (HttpOnly, Secure, SameSite, token rotation, WebAuthn).

File and path family

File upload vulnerabilities

The application lets a user upload a file. The mistakes are predictable: trusting the file extension instead of the contents, trusting the Content-Type header (controlled by the client), double-extension handler confusion, storing uploads inside the web root with execute permissions (so an uploaded shell.php executes as PHP), failing to strip metadata, allowing path traversal in the filename, or not enforcing size limits. The worst case is RCE: an attacker uploads a webshell and gets command execution. The fix is content-based validation (magic bytes, library-level type detection), randomised storage filenames, storage outside the web root, and serving downloads via a controller that sets explicit Content-Type and Content-Disposition.

Deep dive: File upload vulnerabilities. Tooling: best file upload tools 2026.

Path traversal (directory traversal)

User input is concatenated into a filesystem path, and the input contains ../ segments (or encoded variants: %2e%2e%2f, ..%c0%af, unicode tricks) that escape the intended directory. The attacker reads /etc/passwd, the application's config file, source code, or whatever else the process can read. The dense PHP variants are php://filter source disclosure, php://input LFI to RCE, and log poisoning. Defence is to refuse path-separator characters in user input, then resolve the final path and verify it still sits inside the intended base directory after resolution. Never trust pre-resolution checks.

Deep dive: Path traversal. Tooling: best LFI tools 2026.

Data and dependencies family

Insecure deserialization

The application deserializes attacker-controlled bytes using a deserializer that can instantiate arbitrary classes or trigger gadget chains during deserialization. Java's native serialization, Python's pickle, PHP's unserialize, .NET's BinaryFormatter. The 2017 Equifax breach involved deserialization in Apache Struts. The defence is to refuse: use JSON (or another schema-based format), never deserialize from untrusted sources with a code-aware deserializer, and treat any framework feature that promises "automatic object reconstruction from a request body" with extreme suspicion.

Deep dive: Insecure deserialization. Tooling: best deserialization tools 2026.

Supply chain attacks

The dependency you trust is itself untrustworthy. A malicious package gets published to npm or PyPI with a typosquatted name. A legitimate maintainer's account gets hijacked. A build-system compromise injects a payload into otherwise-clean code (the SolarWinds breach, 2020). A malicious GitHub Action exfiltrates secrets from your build. Defence is lockfiles, dependency pinning, provenance verification (sigstore, npm provenance), automated scanning, and a hard look at the privilege every dependency actually needs.

Availability and infrastructure family

Denial of service (DoS)

An attacker exhausts a resource the application needs: CPU, memory, file descriptors, database connections, bandwidth, or budget on an autoscaled platform. Algorithmic complexity attacks (a regex that backtracks exponentially on crafted input, a hash collision flooding a HashMap), application-layer attacks (slowloris-style connection holds, HTTP/2 rapid reset CVE-2023-44487), or just brute volume from a botnet. Defence is rate limiting at the edge, sensible timeouts and bounded queues, regex auditing, and capacity planning that distinguishes "we got popular" from "we got attacked".

Deep dive: Application-layer DoS. Tooling: best application-layer DoS testing tools 2026.

DNS attacks

DNS is trusted infrastructure, and that trust is misplaced. Cache poisoning, DNS hijacking via compromised registrar accounts, subdomain takeover when a CNAME points at a dangling cloud resource, NXNS-style amplification against authoritative servers, DNS rebinding to bypass same-origin protections, and DNSSEC misconfigurations. The DNS attack surface for a web app is broader than most developers realise: the app's own DNS, the email DNS (SPF, DKIM, DMARC), third-party domains the app embeds, and the CDN's DNS all contribute.

API attacks

REST and GraphQL APIs concentrate every other vulnerability into denser endpoints with fewer human checkpoints. Broken object-level authorisation (you ask for /users/123 and get user 124 back when you should not), mass-assignment where an extra field in the JSON body promotes you to admin, GraphQL queries with no depth limit (a single query that joins ten levels deep and costs the database minutes of CPU), and over-permissive CORS that turns same-origin protections into a rubber stamp. The OWASP API Security Top 10 is now a separate project from the main Top 10 for a reason.

Deep dive: API security attacks. Tooling: best API security tools 2026.

How do you use this taxonomy?

If you are starting out, learn SQL injection first. It is the densest single class, the tooling around it is the most mature, and understanding it deeply teaches the meta-skill of "where else does the application mix code and data". From there I would go XSS (covers the entire client-side trust problem), then SSRF (covers the entire "the server is a confused client" problem), then auth attacks (covers the entire identity story).

If you are reviewing an application, walk the trust boundaries first: every place untrusted input enters, every place the app makes an outbound request, every place the app reads a file by name, every endpoint that mutates state. The fifteen classes above are different symptoms of the same handful of crossings.

If you are building, the cheapest thing you can do is adopt frameworks and patterns that make each class hard by default: parameterised queries (no SQL injection), context-aware output encoding plus a strict CSP (no XSS), allow-listed URL fetchers (no SSRF), schema-validated request bodies (no mass assignment), and so on. Audit catches the leftovers; defaults prevent the bulk.

What the deep-dive articles look like

Each of the fifteen classes above gets its own article with the same structure:

1. Definition: one paragraph, quotable.
2. Mechanism: what the application is actually doing wrong.
3. Vulnerable example: real code, the kind of thing I have actually seen ship.
4. Exploitation walkthrough: against the example above, with the tools real attackers use.
5. Detection signals: what defenders see in logs.
6. Defence at the code level.
7. Defence at the infrastructure level.
8. Common mistakes when defending: where well-intentioned mitigations fail.
9. References: CVEs, CWE, official docs.

For the larger classes (SQL injection, XSS) the variants get their own sub-articles. For the tooling, each class has a companion "best tools" annual listicle and per-tool deep dives covering setup, attack walkthroughs against my lab targets, anonymity (Tor and proxychains), and anti-detection.

The vertical slices are now built across SQL injection and the six labbed attack classes (XSS, SSRF, file upload, path traversal, RCE, XXE), each with a spoke article, a 2026 tool listicle, and a cheat sheet + tutorial for the primary tool. The remaining five (deserialization, API, CSRF, clickjacking, application-layer DoS) ship with a spoke and a tool listicle but no companion lab. Start anywhere a real bug is biting you this week. The recommended starting path is still SQL injection if you are new: the SQL injection deep dive, the best SQL injection tools list for 2026, and the sqlmap cheat sheet.