Application Vulnerability Classes

The recurring failure shapes behind most web bugs — injection, client-side, broken access control, and server-side flaws — what each one is, why it happens, and the defense that actually closes it.

IT Abyss

Application Vulnerability Classes

An application vulnerability is rarely a magic exploit; it is a predictable consequence of trusting input that should not be trusted. The whole field organizes into a few recurring failure shapes. Injection is untrusted data crossing into an interpreter and being parsed as code. Client-side flaws abuse the trust a browser extends to your origin. Broken access control is the server acting on a request without checking the caller is allowed to. Server-side flaws are the server processing a request in a way the request author steers. Learn the shape and you can classify a bug you have never met by name.

This topic gives the mental model for each class: what the flaw is, why it happens, how to detect it in your own telemetry, and the fix that genuinely closes it rather than the one from folklore. That last part is where interviews live — naming a defense that works separates the engineer who understands the mechanism from the one who recites "add a WAF."

Topic map

Injection attacks — data crossing into an interpreter; why parameterized queries beat escaping and WAFs; NoSQL, command, LDAP, template, and second-order injection; the defense hierarchy.
Client-side vulnerabilities — the three XSS types, contextual output encoding and CSP, CSRF versus XSS, SameSite/HttpOnly cookies, CORS as a relaxation of the same-origin policy, clickjacking, and postMessage origin checks.
Broken access control — authentication versus authorization, IDOR/BOLA and server-side ownership checks, why hiding a UI element is not a control, mass assignment, RBAC versus ABAC, and deny-by-default.
Server-side vulnerabilities — SSRF and cloud metadata, insecure deserialization, XXE, path traversal, request smuggling, and TOCTOU races, unified by the idea of secure defaults.

Every class here reduces to a boundary the application failed to hold: between data and code, between origins, between callers, or between check and use. Hold the boundary and the class disappears.

intermediate

Application Vulnerability Classes

security-app-vulns

Practice: 13 questions →

Sections

Contents

Detailed explanation

Application Vulnerability Classes

Topic map

Injection attacks — data crossing into an interpreter; why parameterized queries beat escaping and WAFs; NoSQL, command, LDAP, template, and second-order injection; the defense hierarchy.
Client-side vulnerabilities — the three XSS types, contextual output encoding and CSP, CSRF versus XSS, SameSite/HttpOnly cookies, CORS as a relaxation of the same-origin policy, clickjacking, and postMessage origin checks.
Broken access control — authentication versus authorization, IDOR/BOLA and server-side ownership checks, why hiding a UI element is not a control, mass assignment, RBAC versus ABAC, and deny-by-default.
Server-side vulnerabilities — SSRF and cloud metadata, insecure deserialization, XXE, path traversal, request smuggling, and TOCTOU races, unified by the idea of secure defaults.

Every class here reduces to a boundary the application failed to hold: between data and code, between origins, between callers, or between check and use. Hold the boundary and the class disappears.

Why it matters

Almost every real-world web vulnerability is one of a handful of recurring shapes, and interviewers test whether you can name the mechanism and the fix that truly closes it — not the folklore one. A candidate who says "SQL injection is fixed by parameterized queries, because they parse first and bind values as data" is instantly ahead of one who reaches for escaping and a WAF. Learn the shape of each class and you can reason about a flaw you have never seen by name.

Application Vulnerability Classes

IT Abyss

Application Vulnerability Classes

Topic map

Injection attacks — data crossing into an interpreter; why parameterized queries beat escaping and WAFs; NoSQL, command, LDAP, template, and second-order injection; the defense hierarchy.
Client-side vulnerabilities — the three XSS types, contextual output encoding and CSP, CSRF versus XSS, SameSite/HttpOnly cookies, CORS as a relaxation of the same-origin policy, clickjacking, and postMessage origin checks.
Broken access control — authentication versus authorization, IDOR/BOLA and server-side ownership checks, why hiding a UI element is not a control, mass assignment, RBAC versus ABAC, and deny-by-default.
Server-side vulnerabilities — SSRF and cloud metadata, insecure deserialization, XXE, path traversal, request smuggling, and TOCTOU races, unified by the idea of secure defaults.

Every class here reduces to a boundary the application failed to hold: between data and code, between origins, between callers, or between check and use. Hold the boundary and the class disappears.

Application Vulnerability Classes

Topic map

Injection attacks — data crossing into an interpreter; why parameterized queries beat escaping and WAFs; NoSQL, command, LDAP, template, and second-order injection; the defense hierarchy.

Client-side vulnerabilities — the three XSS types, contextual output encoding and CSP, CSRF versus XSS, SameSite/HttpOnly cookies, CORS as a relaxation of the same-origin policy, clickjacking, and postMessage origin checks.

Broken access control — authentication versus authorization, IDOR/BOLA and server-side ownership checks, why hiding a UI element is not a control, mass assignment, RBAC versus ABAC, and deny-by-default.

Server-side vulnerabilities — SSRF and cloud metadata, insecure deserialization, XXE, path traversal, request smuggling, and TOCTOU races, unified by the idea of secure defaults.

Every class here reduces to a boundary the application failed to hold: between data and code, between origins, between callers, or between check and use. Hold the boundary and the class disappears.