Web Application Security - OWASP Top 10, Injection, XSS, CSRF & SSRF

Overview

Almost every web vulnerability on the OWASP Top 10 comes from one mistake: untrusted data crosses a trust boundary and gets interpreted as something other than data. A quote turns into SQL syntax (injection). A <script> tag turns into code in someone else's browser (XSS). A cookie the browser attaches automatically turns into an action the user never meant to take (CSRF). A URL turns into a request from inside your network (SSRF). A permissive header turns into another site reading your users' data (CORS misconfiguration). The senior answer is never "sanitize all input". It is: know each sink, use the API that keeps code and data separate at that sink, and stack a second layer for when the first one is forgotten.

This cluster covers the five classes interviewers and security reviews ask about most, with the fix that actually works for each and what goes wrong if you pick a weaker one.

Broken access control is the Authorization lesson. Cryptographic failures and key handling are Secrets and KMS. Identification and session failures are OAuth 2.1 and OIDC. Known-CVE dependencies and unsigned updates are CI/CD pipelines. This page stays on the sink model.

The OWASP Top 10 (2021) in one table

CSRF dropped off the Top 10 list in 2017 because frameworks and SameSite cookies made it rarer. It still shows up in interviews and in any app with cookie sessions, so it has its own page: CSRF.

flowchart TB
  a["1. Untrusted input: form, header, URL, file, webhook"]
  b["2. Trust boundary: your server or the victim's browser"]
  c["3. Sink: SQL, shell, HTML, JS, URL fetch, cookie-bearing request"]
  d["4. Interpreter parses data as code or as authority"]
  a -->|1. Untrusted input: form, header, URL, file, webhook to 2. Trust boundary: your server or the victim's browser| b
  b -->|2. Trust boundary: your server or the victim's browser to 3. Sink: SQL, shell, HTML, JS, URL fetch, cookie-bearing request| c
  c -->|3. Sink: SQL, shell, HTML, JS, URL fetch, cookie-bearing request to 4. Interpreter parses data as code or as authority| d

Same payload, five sinks

The point of this demo is that one string can be harmless or dangerous depending on where it lands, so the fix belongs at the sink, not at the front door.

# Same untrusted string, five different "sinks". Safety depends on the SINK,
# not on the input: this is why "sanitize all input" is the wrong mental model.
import html, json, sqlite3, shlex
from urllib.parse import quote

payload = "x'); DROP TABLE t;-- </script><img src=x onerror=alert(1)> $(id)"

# 1. SQL sink: a bound parameter is sent as DATA, never parsed as SQL.
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE t (name TEXT)")
db.execute("INSERT INTO t (name) VALUES (?)", (payload,))
print("sql   ->", db.execute("SELECT count(*) FROM t").fetchone()[0], "row stored, table intact")

# 2. HTML body sink: encode <, >, &, quotes so the browser renders text.
print("html  ->", html.escape(payload)[:70], "...")

# 3. JS string sink: JSON-encode AND break '</' so </script> can't close the tag.
print("js    ->", json.dumps(payload).replace("</", "<\\/")[:70], "...")

# 4. URL query sink: percent-encode the value (never the whole URL).
print("url   ->", quote(payload, safe="")[:70], "...")

# 5. Shell sink: best fix is "no shell"; if forced, quote one argument.
print("shell ->", shlex.quote(payload)[:70], "...")

Output:

sql   -> 1 row stored, table intact
html  -> x'); DROP TABLE t;-- </script><img src=x onerror=alert(1 ...
js    -> "x'); DROP TABLE t;-- <\/script><img src=x onerror=alert(1)> $(id)" ...
url   -> x%27%29%3B%20DROP%20TABLE%20t%3B--%20%3C%2Fscript%3E%3Cimg%20src%3Dx%2 ...
shell -> 'x'"'"'); DROP TABLE t;-- </script><img src=x onerror=alert(1)> $(id)' ...

Why "validate input" alone loses

Defense in depth as a checklist

A useful review habit is to list each risk and the independent layers that stop it. A risk with zero layers is a finding, and a risk with one layer is a candidate for a second.

// Defense in depth: score a handler's controls per OWASP risk.
// One missing layer is tolerable; a risk with ZERO layers is a finding.
type Control = { name: string; covers: string[] };

const controls: Control[] = [
  { name: "parameterized queries (ORM)", covers: ["injection"] },
  { name: "template auto-escaping", covers: ["xss"] },
  { name: "CSP with nonces", covers: ["xss"] },
  { name: "SameSite=Lax session cookie", covers: ["csrf"] },
  { name: "object-level authz check", covers: ["broken-access-control"] },
  // note: nothing covers "ssrf" in this service yet
];

const risks = ["broken-access-control", "injection", "xss", "csrf", "ssrf"];

for (const risk of risks) {
  const layers = controls.filter((c) => c.covers.includes(risk)).map((c) => c.name);
  const verdict = layers.length === 0 ? "FINDING (no layer)" : layers.length === 1 ? "single layer" : "defense in depth";
  console.log(`${risk.padEnd(22)} ${String(layers.length)} -> ${verdict}`);
}

Output:

broken-access-control  1 -> single layer
injection              1 -> single layer
xss                    2 -> defense in depth
csrf                   1 -> single layer
ssrf                   0 -> FINDING (no layer)

What happens if you choose differently

• Rely on a WAF instead of fixing code: WAFs catch the textbook payloads and miss encoded or business-logic variants. Attackers test against WAFs on purpose. Use one as a speed bump and for virtual patching while a fix ships.
• Escape on input and store escaped data: you double-encode on display, corrupt data used by non-HTML consumers (APIs, CSV, mobile), and still miss contexts like JS and URLs. Store raw, encode on output.
• Trust the frontend to validate: anything the browser enforces, an attacker with curl skips. Client validation is UX; server validation is security.
• Treat internal services as trusted: SSRF and lateral movement turn "internal only" endpoints into public ones. Authenticate service-to-service calls too.

Threat modeling in five minutes (STRIDE-lite)

For any new endpoint ask:

1. Who can call it? Anonymous, logged-in user, admin, another service.
2. What untrusted data enters? Body, query, headers, cookies, uploaded files, URLs to fetch.
3. Which sinks does that data reach? DB query, template, shell, outbound HTTP, logs, redirects.
4. What authority does the request carry automatically? Cookies, mTLS identity, cloud IAM role of the host.
5. What is the blast radius if the check is missing? One user's data, every tenant, the cloud account.

Pros and cons of common framework defaults

Interview Q&A

Go Deeper

• OWASP Top 10 (2021)
• OWASP Cheat Sheet Series
• PortSwigger Web Security Academy
• OWASP Threat Modeling Cheat Sheet