ThreatFoundacademy
Web Application Security
Web Application Security

HTTP, the language of the web

Requests, responses, methods, status codes and headers — the foundation every web attack builds on.

8 min read

Almost every web vulnerability is, underneath, a misuse of HTTP — the request/response protocol browsers and servers speak. Before you can break a web app, you have to be able to read its conversations fluently.

A request, dissected

A client sends a request: a method, a path, headers, and an optional body.

GET /search?q=hello HTTP/1.1
Host: example.com
Cookie: session=ab12cd
User-Agent: Mozilla/5.0
Accept: text/html

The server replies with a status line, headers, and a body:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=ab12cd; HttpOnly; Secure

<html>…results for "hello"…</html>

Methods that matter

  • GET — fetch a resource; should never change state (but apps often break this rule, enabling CSRF).
  • POST — submit data / change state.
  • PUT / PATCH / DELETE — REST-style updates and deletes; frequently under-protected.
  • OPTIONS — preflight for CORS; reveals allowed methods and origins.

Status codes you’ll read constantly

  • 2xx success · 3xx redirect · 4xx client error (401 unauth, 403 forbidden, 404 not found) · 5xx server error.
  • A 500 after a quote character is a classic hint of SQL injection. A 302 to /login tells you an endpoint is auth-gated.

Run everything through an intercepting proxy (Burp Suite or mitmproxy). Seeing the raw requests — not the rendered page — is the single biggest skill jump for a beginner.

Headers are where the security lives

Cookies (HttpOnly, Secure, SameSite), Content-Security-Policy, Authorization, and Origin headers decide whether an attack works. We’ll return to each as we cover specific bugs.