How web applications actually work
Requests, responses, statelessness, sessions, and where trust boundaries live.
Every web vulnerability is a failure at a trust boundary — a point where data crosses from something the attacker controls into something the server or another user trusts.
The request/response cycle
An HTTP request is just text: a method and path, headers, and an optional
body. The server parses it, runs application code, touches a database or
filesystem, and returns a response. Everything in the request — the path,
query string, cookies, Content-Type, Host, the body — is
attacker-controlled and must be treated as hostile.
POST /login HTTP/1.1
Host: example.com
Cookie: session=abc123
Content-Type: application/x-www-form-urlencoded
username=alice&password=hunter2
State and sessions
HTTP is stateless. Applications fake continuity with a session token, usually a cookie. If that token is guessable, leaked, or not invalidated on logout, the whole authentication model collapses.
Client vs. server trust
The browser enforces rules — same-origin policy, cookie flags, CSP — but an attacker can send raw requests that ignore the browser entirely.
Warning
Never rely on client-side validation for security. It is a UX feature, not a control. Anything the browser checks, an attacker skips.
Key takeaway
When you look at a feature, ask: what does this input become? A SQL fragment? An HTML node? A filesystem path? A URL the server fetches? The answer tells you which vulnerability class to test.