Why Know This
Almost every web vuln (SQLi, XSS, SSRF, IDOR…) is exploited via HTTP requests. Without the protocol you can't read Burp or build payloads.
Request anatomy
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123
username=admin&password=secret
Method + path + version; headers (metadata); blank line; then body.
Methods
GET (URL params → SQLi/IDOR), POST (body/forms), PUT/DELETE (access control?), OPTIONS (allowed methods, CORS).
Key headers
Cookie/Set-Cookie (HttpOnly,Secure,SameSite), Authorization (Bearer <JWT>),
Host (Host header injection), X-Forwarded-For (spoofable), Referer/Origin (CSRF/CORS),
security headers (CSP, X-Frame-Options, HSTS).
Status codes for a tester
2xx success; 3xx redirect (open redirect?); 4xx client (401 unauth vs 403
forbidden — key for IDOR; 404 for fuzzing); 5xx server (500 often = a vuln:
stack trace, SQL error).
Practical trick
Change one parameter, watch the status and length change — that's how you spot SQLi (error), IDOR (200 instead of 403), fuzzing (404 vs 200).
Tool: Burp Suite. Practice: the web labs.