New The 2026 Continuous Validation Methodology Paper is now available. Read the paper →

Web Attack & Defense — Canonical Reference.

Each vulnerability class presented as an attack/defense pair, with the briefing-level overview and the protocol/header/encoding points where weaknesses recur.

Class-by-class — attack / defense / detection signal

XSS

  • Attack. Inject HTML or JS into a sink (innerHTML, document.write, attribute, JS string).
  • Defense. Context-aware output encoding, strict CSP (script-src 'self', no unsafe-inline), Trusted Types in modern browsers.
  • Detection. CSP report-uri violations spiking, WAF rule OWASP CRS 941xxx firing, requests with <script or onerror= in parameters.

SQL injection

  • Attack. Unescaped concatenation into SQL string.
  • Defense. Parameterized queries. ORMs help only if you avoid their raw-query escape hatches.
  • Detection. DB-tier errors involving syntax error near; WAF rules 942xxx; queries with UNION SELECT, SLEEP(, or '; --.

SSRF

  • Attack. Server fetches attacker-supplied URL → internal services, cloud metadata.
  • Defense. Allow-list of destination hosts at the egress layer. Deny RFC1918, 169.254/16, ::ffff:0:0/96, link-local. Resolve once, validate, then connect — defeats DNS rebinding.
  • Detection. Outbound HTTP from app tier to 169.254.169.254, localhost, RFC1918. DNS queries for attacker domains.

CSRF

  • Attack. State-changing request triggered cross-origin.
  • Defense. SameSite=Lax cookies (default in modern browsers), anti-CSRF token bound to session, custom-header requirement for JSON APIs (forces preflight).
  • Detection. Sensitive POSTs with Origin/Referer from unexpected hosts.

Deserialization

  • Attack. Untrusted serialized object reaches a deserializer with available gadgets.
  • Defense. Don't deserialize untrusted input. If you must, use a format-only serializer (JSON without typed binding) and validate before unmarshaling.
  • Detection. JVM/CLR exceptions involving InvocationTargetException; child process spawned from app-server JVM.

File upload to RCE

  • Attack. Upload with executable extension, request URL, server executes.
  • Defense. Store uploads on a domain that doesn't execute server-side; serve with Content-Disposition: attachment; never trust client-provided MIME or extension.
  • Detection. First-time-seen file extensions written to upload dirs; web-server access logs hitting .php / .jsp / .aspx in user-upload paths.

Protocol / header / encoding hotspots

  • Set-Cookie attributes. Missing Secure, HttpOnly, or wrong SameSite on session cookies. Domain attribute scoping too broadly.
  • CSP gaps. script-src 'self' 'unsafe-inline' is a fig leaf. script-src https: trivially bypassable via attacker-controlled https origin.
  • Content-type sniffing. Browser ignores wrong Content-Type and renders user-uploaded HTML. Defense: X-Content-Type-Options: nosniff.
  • Reverse-proxy encoding mismatch. nginx normalizes ..%2f differently than backend. Backend gets a path traversal that proxy normalization hid from the WAF.
  • HTTP/2 → HTTP/1.1 conversion. Pseudo-header smuggling between front-end and back-end. Defense: end-to-end H/2 or strict re-encoding at the gateway.
Rule of thumbDefense is a system property, not a feature list. A CSP without upgrade-insecure-requests and a SameSite policy and an Origin check isn't a CSP — it's a placebo. Look for the missing layer when reviewing.

From reference to evidence

Run this against your own environment.