Web apps are the single largest attack surface for most organizations. To secure them, master the request/response cycle first.
1POST /login HTTP/1.1
2Host: app.example.com
3Content-Type: application/json
4Cookie: session=abc123
5
6{"username":"alice","password":"hunter2"}| Part | Security relevance |
|---|---|
| Method (GET/POST/...) | GET shouldn't change state; CSRF targets state-changing requests |
| Headers | Carry cookies, auth tokens, content type |
| Cookies | Session identity — a top theft target |
| Body | User input — the source of most injection attacks |
1HTTP/1.1 200 OK
2Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict
3Content-Security-Policy: default-src 'self'Security-relevant response headers are your friends (covered later in this chapter).
HTTP is stateless — each request is independent. Apps track identity via:
If an attacker steals the session ID or token, they become the user. Protecting these is central to web security.
Never trust input from the client. Anything from the browser — form fields, headers, cookies, URL parameters — can be forged. Validate and encode everything on the server.
Client-side validation is for UX only. A determined attacker bypasses the browser entirely with tools like curl or an intercepting proxy.
The browser's Same-Origin Policy prevents scripts on one origin from reading responses from another. CORS headers selectively relax this. Misconfigured CORS (Access-Control-Allow-Origin: * with credentials) is a common vulnerability that exposes APIs to any website.
The OWASP Top 10 is the industry-standard list of the most critical web app risks. The next lessons walk through the highest-impact ones — injection, broken access control, XSS, and authentication failures — which together account for the majority of real-world breaches.