🟢 Day 3 — How the Web Works
Day 60 — Pro Hunter $$$$
03
You typed “google.com” this morning. Do you actually know what happened in the 40 milliseconds between pressing Enter and the page appearing? Most developers — people who build websites for a living — cannot fully answer that question. Every bug bounty hunter who earns serious money can, because understanding what happens between browser and server is what lets you see exactly where things can go wrong.
Understanding how HTTP works for beginners in bug bounty is not optional. Every vulnerability you will ever find — SQL injection, XSS, IDOR, CSRF, SSRF — is fundamentally a manipulation of what you are going to learn today. When you understand the protocol, techniques stop being magic spells you copy from tutorials and start being logical consequences you can derive yourself.
Today has no installations, no tools, and no terminal commands. It is pure, deep understanding. It is the most important theory day in this entire 60-day course — and the one that pays off in every single day that follows.
This is the day most beginners try to skip. Do not. Every hunter who finds high-value bugs — the $3,000 to $30,000 findings — understands HTTP at a depth most developers never reach. Understanding how HTTP works for beginners in bug bounty is not the same as a web development tutorial. We are not building anything. We are learning to see the cracks.
DNS — The Internet’s Phone Book (And Why Bug Hunters Love It)
When you type google.com into a browser, your computer does not know where Google’s server is. It only understands IP addresses — numerical identifiers like 142.250.80.46. DNS (Domain Name System) is the lookup service that translates the domain into that IP address in milliseconds.
As a bug bounty hunter, DNS is your first source of recon intelligence. DNS records for any domain reveal hidden subdomains, third-party services, development environments accidentally left public, and the technology stack. Before you test a single endpoint, you map the DNS.
securityelites.comDNS RESOLUTION FLOW — What Happens When You Type a URL
🌐
BROWSER
You type
“target.com”
① Asks: what IP
for target.com?
→
💾
LOCAL DNS
Checks local
cache first
② If not cached,
asks the resolver
→
🔍
DNS SERVER
8.8.8.8
(Google DNS)
③ Queries
nameservers
→
✅
IP RETURNED
104.21.33.42
→ browser
④ Browser
connects to IP
WHY HUNTERS CARE ABOUT DNS
A records: Find host servers
CNAME: Discover forgotten subdomains
MX records: Find email infrastructure
TXT records: SPF, DKIM, token disclosure
Subdomains: dev.target.com — often less secured!
Zone transfer: If misconfigured, dumps ALL DNS
DNS Resolution Flow — 4 steps in under 50ms every page load. Bug bounty hunters use DNS recon to discover subdomains, staging environments, and forgotten assets that are often far less secured than the main domain.
DNS Recon Commands (used on Day 11)
# Look up all DNS records
dig target.com ANY
# Find subdomains via certificate transparency
curl https://crt.sh/?q=%.target.com&output=json
# Attempt zone transfer (if misconfigured = jackpot)
dig @ns1.target.com target.com AXFR
The HTTP Request-Response Cycle — The Heartbeat of the Web
Once DNS resolves the IP, your browser connects and the conversation begins. Every interaction follows the same structure: the client sends a request, the server sends back a response. Understanding how HTTP works for beginners in a security context means seeing that this conversation is text-based, stateless, and completely open to inspection when proxied through Burp Suite.
HTTP REQUEST (Browser → Server)
POST /api/login HTTP/1.1
Host: target.com
Content-Type: application/json
Cookie: csrf_token=abc123
User-Agent: Mozilla/5.0…
[blank line = end of headers]
{“email”:”user@test.com”,
“password”:”hunter2″}
Hunter notes:
POST to /api/login = auth endpoint
JSON body = test injection here
csrf_token in cookie = CSRF protection
Check if token validated server-side
HTTP RESPONSE (Server → Browser)
HTTP/1.1 200 OK
Server: nginx/1.14.2 ← Version disclosure!
Set-Cookie: session=eyJhbGc…; HttpOnly; Secure
X-Powered-By: PHP/7.4.3 ← Tech stack!
[blank line]
{“token”:”eyJhbGciOiJIUzI1N…”,
“user_id”:4829,”role”:”user”}
Hunter notes:
nginx 1.14.2 = check CVEs
PHP 7.4.3 = EOL, known vulns
JWT returned = test signature
role: “user” = try “admin” forgery
💡 Mr Elite’s Insight: The response above leaks nginx version and PHP version. These are actual information disclosure findings. PHP 7.4.3 is end-of-life since November 2022. Beginners walk past these headers. Hunters submit them as findings and research CVEs against that specific version.
HTTP Methods and Their Security Meaning — Beyond GET and POST
Most people know GET and POST. Bug bounty hunters need to understand all HTTP methods and what unexpected method handling reveals about a server’s security posture. The method tells the server what you want to do. The security question is: does the server verify you are actually allowed to do it?
securityelites.comHTTP METHODS — SECURITY PERSPECTIVE
METHOD
WHAT IT DOES
HUNTER’S ANGLE
GET
Retrieve data. Parameters in URL. Should have no side effects.
Test URL params for IDOR. Check if sensitive data in query string. Force GET on POST-only actions.
POST
Submit data. Body contains payload. Creates or modifies resources.
Primary injection testing ground. Test for CSRF. Try replaying without the token.
PUT
Replace a resource completely. Should require auth and ownership.
High-value target. Try PUT on another user’s resource ID. Missing auth = privilege escalation finding.
PATCH
Partial update. Modify specific fields of a resource.
Test mass assignment. Try adding “role”:”admin” to a user PATCH request body.
DELETE
Remove a resource. Irreversible. Should be heavily authorised.
Can you DELETE resources belonging to other users? Missing ownership check = critical IDOR finding.
OPTIONS
Ask server what methods it supports. Used in CORS preflight.
Run on every endpoint to discover unexpected allowed methods. Server says DELETE allowed? Try it.
HTTP Methods Security Cheat Sheet — Every method has a security implication. Hunters test all methods on every endpoint, not just the ones the UI uses. A button that shows GET might accept DELETE with very different results.
HTTP Status Codes as Hunter Intelligence — Reading Server Reactions
Status codes are how the server communicates the result of your request. For everyday users they are loading spinners or error pages. For bug bounty hunters they are a continuous stream of information about how the server is configured, what it is protecting, and where to probe harder. Learning to read status codes like intelligence is a key skill in understanding how HTTP works for beginners in security contexts.
securityelites.comHTTP STATUS CODES — THE HUNTER’S INTERPRETATION
2xx
SUCCESS
200 OK — Getting 200 on a page that should return 403? That’s a finding.
201 Created — Confirm what was created — mass assignment risk here.
204 No Content — Often DELETE responses. Did the resource actually get deleted?
3xx
REDIRECT
301 Moved — Check Location header — open redirect testing here.
302 Found — Most open redirect testing happens here. Is Location user-controlled?
4xx
CLIENT ERROR
401 Unauthorized — Find endpoints returning 200 that should return 401.
403 Forbidden — IDOR testing ground — try other users’ IDs to get 200.
429 Rate Limited — Test bypass via different IPs, User-Agent headers, X-Forwarded-For.
5xx
SERVER ERROR
HUNTER GOLD
500 Internal Error — Your input triggered unexpected behaviour. Potential injection. Probe aggressively.
502 Bad Gateway — Can reveal internal architecture and backend services.
Critical pattern: 401 = “who are you?” (authentication missing) vs 403 = “I know who you are, but no” (authorisation missing). IDOR testing mostly lives at the 403 boundary — testing whether you can make another user’s 403 return 200.
HTTP Status Codes — Hunter’s Interpretation. The critical insight: a 500 error on an endpoint you are fuzzing means your input is causing server-side errors — strong indicator of injection. Never walk past a 500. Also note: 403 vs 404 tells you a resource exists even when the server tries to hide it.
HTTP headers are metadata transmitted with every request and response. For bug hunters, headers are simultaneously intelligence sources and attack surfaces. There are two categories to understand: security headers that protect applications, and information-leaking headers that expose attack surface.
MISSING HEADERS = FINDINGS
Content-Security-PolicyMissing = no XSS protection. Absence indicates XSS payloads more likely to work.
X-Frame-OptionsMissing = clickjacking possible. Low-Medium severity finding.
Strict-Transport-SecurityMissing = SSL stripping possible. Low finding on most programs.
INFORMATION-LEAKING HEADERS
Server: Apache/2.2.31Version disclosure. Apache 2.2.31 is end-of-life. Look up CVEs immediately.
X-Powered-By: PHP/7.1.0EOL PHP has known RCE vulnerabilities. Always research the specific version.
X-Debug-Token: 1a2b3cDebug mode left on. Often reveals stack traces and internal paths. Critical finding.
Cookies vs Sessions vs Tokens — The Authentication Triangle
HTTP is stateless — every request is independent with no memory of previous requests. To make a web application that remembers you are logged in, developers layer authentication mechanisms on top. Understanding these mechanisms is core to understanding how HTTP works for beginners in security — because most authentication vulnerabilities live exactly at this layer.
securityelites.comCOOKIE ANATOMY — EVERY ATTRIBUTE MATTERS TO A HUNTER
Set-Cookie:
session=eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0ODI5fQ.abc
;
HttpOnly
;
Secure
;
SameSite=Strict
;
Path=/; Expires=Thu, 23 Mar 2026 00:00:00 GMT
session=eyJh…
The token value. If it starts with eyJ it is a JWT. Decode on jwt.io — contains user_id, role, expiry. Test if you can forge it.
Hunt: Decode and test JWT signature
HttpOnly
JavaScript cannot read this cookie. Prevents XSS from stealing the session token. If absent, XSS can steal sessions.
Missing = XSS severity increases
Secure
Cookie only sent over HTTPS. If absent, cookie sent over HTTP = interception possible. Always check on HTTP versions of sites.
Missing on HTTP page = finding
SameSite=Strict
Cookie not sent in cross-site requests. Prevents CSRF attacks. If absent or set to None, CSRF testing becomes important.
None or Lax = CSRF test the app
Cookie Anatomy for Bug Hunters — Every attribute signals the application’s security posture. Missing HttpOnly means XSS session theft is viable. Missing SameSite means CSRF testing is warranted. Missing Secure means cookies may transmit over HTTP. Each absence is a potential finding.
Sessions vs JWTs — The Two Authentication Approaches
Server-Side Sessions
The server stores a table: session_id maps to user data. Cookie contains only the ID. Server validates ID on each request. Attack surface: session fixation, session hijacking, predictable session IDs.
JWTs (JSON Web Tokens)
No server storage. All user data encoded in the token itself. Token is signed with a secret key. Attack surface: algorithm confusion (RS256 to HS256), weak secret keys, “none” algorithm bypass, claim tampering. Day 22 covers these attacks in full.
Same-Origin Policy — The Rule That Explains Half of Web Security
The same-origin policy (SOP) is a browser security rule: JavaScript on one origin cannot read responses from a different origin. An origin is the combination of protocol plus hostname plus port. This single rule is the reason why half of web security vulnerabilities exist and why the other half require bypasses of it.
Same-Origin Examples
SAME origin: https://app.target.com/page1 ↔ https://app.target.com/page2
DIFF origin: https://target.com ↔ https://api.target.com (different subdomain)
DIFF origin: http://target.com ↔ https://target.com (different protocol)
DIFF origin: https://target.com:443 ↔ https://target.com:8443 (different port)
Why XSS is dangerous — SOP explains it
XSS injects malicious JavaScript onto the target origin. Since the script runs on the trusted origin, SOP allows it to read that origin’s cookies and API responses. XSS defeats SOP by running malicious code from within the trusted origin itself rather than from the attacker’s site.
Why CSRF works — the SOP gap
SOP prevents cross-origin reads but does NOT prevent cross-origin writes such as form submissions. A malicious site can submit a form to bank.com/transfer. The browser automatically includes your cookies. CSRF tokens prevent this by adding an unpredictable secret that the attacker’s site cannot read due to SOP.
CORS Misconfiguration — intentionally breaking SOP ($500 to $5,000)
CORS deliberately allows specific cross-origin requests. When misconfigured — especially when Access-Control-Allow-Origin is set to wildcard on an API returning sensitive user data — any website can read that user’s private API responses. That is a High severity finding on most programs.
HTTPS, TLS and What Burp Suite Is Actually Doing When It Intercepts
HTTPS is HTTP with TLS encryption layered on top. The S means traffic is encrypted — in theory. Yesterday you installed Burp’s CA certificate specifically to break this. Understanding why that worked completes your mental model of how HTTP works for beginners in security testing.
What Burp Suite Actually Does to HTTPS
1
Firefox makes a TLS connection to Burp Suite at 127.0.0.1:8080 — not to the real server. Your installed CA certificate means Firefox trusts this connection.
2
Burp decrypts the traffic from Firefox and shows you the plaintext HTTP request in the Intercept panel.
3
Burp makes its own separate TLS connection to the real server and forwards your request. The server thinks it is talking to a normal browser.
4
The server’s response comes to Burp, is decrypted, shown in the Response panel, then re-encrypted and sent to Firefox. Firefox sees a normal page.
This is called a Man-in-the-Middle (MitM) proxy. The only reason it works is because you installed and trusted Burp’s CA certificate. Without it, your browser refuses the connection. This is also exactly why you should never install untrusted CA certificates in your personal browser.
The Hunter’s HTTP Cheat Sheet — Save This for Every Testing Session
securityelites.comTHE BUG HUNTER’S HTTP QUICK REFERENCE
WHEN YOU SEE… → DO THIS
?id=123 in URL → Try id=124, id=1, id=0, id=admin
?redirect=https://… → Try redirect=https://evil.com
500 Server Error → Injection signal — probe aggressively
X-Powered-By header → Look up CVEs for that version
Cookie without HttpOnly → XSS session theft is viable
No CSRF token in POST → Test CSRF — is action state-changing?
JWT token (eyJ…) → Decode on jwt.io, test algorithm confusion
403 on a resource → Try different method, user agent, path
HTTP CONCEPT → BUG TYPE
URL parameters → IDOR, SQL injection, XSS
POST body → Injection, business logic, CSRF
Headers (User-Agent) → Header injection, XSS
Cookies → Session hijacking, JWT attacks
Redirects (301/302) → Open redirect, phishing chain
PUT/DELETE methods → Unauthorised modification
CORS headers → CORS misconfiguration
Missing security headers → Low finding + enables others
QUESTIONS HUNTERS ALWAYS ASK
Is this resource access-controlled? Can other users reach it?
What if I change the HTTP method from POST to GET?
Are there any parameters I can inject values into?
What does a 403 vs 404 tell me about what exists?
Is there a CSRF token? Is it validated? Is it tied to the session?
What information do the response headers leak?
If I replay this request later, does it still work? (token expiry)
What happens with an empty value, a very long value, special chars?
The Bug Hunter’s HTTP Quick Reference — Every item connects an HTTP concept to a specific vulnerability type. Understanding these connections is what lets hunters find bugs methodically rather than randomly. Save this and reference it during every testing session.
🎯 Day 3 Task — Read the Web Like a Hunter
Today’s tasks require no hacking. They require you to look at the web differently using what you have just learned. Open Burp Suite, activate FoxyProxy, and browse normally — but now with hunter eyes.
📋 DAY 3 EXERCISES — Seeing, Not Hacking
1
Read 5 HTTP Responses for Information Leakage
With Burp running, visit 5 websites. In Burp’s HTTP History tab, click each response and look at the headers. Find at least one that leaks a server version or technology. What is the technology? Is it current? Any known CVEs? This is basic recon you will do on every bug bounty target.
Goal: Find 1 server version disclosure in the wild
2
Find a Cookie Missing Security Attributes
Log into any website you own an account on using your testing browser with Burp running. Find the Set-Cookie header in the response. Does it have HttpOnly? Secure? SameSite? Note which are missing and what attack that enables. Most websites miss at least one.
Goal: Find 1 cookie with a missing security attribute
3
Decode a JWT Token
If you find a JWT token starting with eyJ in a cookie or Authorization header while browsing, copy it and paste it into jwt.io. Read the payload — what data is encoded? What is your user ID? Your role? Any admin flag? Understanding the token structure now prepares you for Day 22’s attacks.
Goal: Decode 1 JWT and understand its claims
★
Look Up DNS Records for Your Selected Bug Bounty Program
Run dig target.com ANY on your chosen program’s domain. What subdomains appear? Visit them. Are there development or staging subdomains? Write down everything — you are building a target map before you test anything. Share your subdomain count with #Day3Done 🗺️
⭐ BONUS — Security Headers Audit
Visit securityheaders.com and scan your chosen bug bounty program’s domain. Note every missing or misconfigured security header. Write each up in bug report format: title, description, steps to reproduce, impact. This is your first practice report — even if you do not submit it yet, writing it solidifies the methodology. Share with #Day3Done 🗺️
🧠
HTTP is no longer a mystery. DNS, methods, status codes,
cookies, same-origin policy — you see what the web is made of.
Day 4 is where this course shifts gears. We cover the OWASP Top 10 — the official industry-standard list of the ten most impactful web vulnerability classes. You will get a complete overview of all ten, understand which are beginner-accessible, and build the mental map that organises every technique you will learn from Day 5 onwards.
Day 4: OWASP Top 10 Overview →
Frequently Asked Questions — Day 3
Why does a bug bounty hunter need to understand HTTP?
Every web vulnerability is ultimately an HTTP vulnerability. SQL injection manipulates HTTP request parameters. XSS stores payloads in HTTP responses. IDOR changes resource identifiers in HTTP paths. Without understanding the protocol you can run tools mechanically without understanding why a vulnerability is valid or how to prove its impact. Hunters who understand HTTP find bugs automated scanners miss.
What HTTP methods matter most for bug bounty hunting?
All methods matter but with different priorities. PUT and DELETE are high-value since they modify or delete data and are frequently under-authorised. GET reveals IDOR via URL params. POST is the injection testing ground. OPTIONS is your recon method to discover what methods an endpoint accepts. PATCH tests mass assignment. Test every method on every interesting endpoint.
What do HTTP status codes tell a bug bounty hunter?
Status codes are intelligence signals. A 500 error on input you are testing means injection signal — probe aggressively. A 200 where you expect a 403 is often an access control vulnerability. A 403 versus 404 difference tells you a resource exists even when hidden. A 301 or 302 with user-controlled Location is an open redirect candidate. Read every status code as a signal, not just a result.
What is the same-origin policy and why does it matter?
The same-origin policy prevents JavaScript on one origin from reading data from another origin. It explains XSS (bypasses SOP by running code on the target origin), CSRF (exploits that SOP only blocks reads not writes), and CORS vulnerabilities (deliberately relax SOP). Understanding SOP is understanding why half of web attacks work the way they do.
What is the difference between cookies and session tokens?
A session token is the data that identifies you — stored server-side or as a JWT. A cookie is the browser mechanism that stores and transmits that token. The security attributes HttpOnly, Secure, and SameSite determine how secure the cookie is. Missing HttpOnly means XSS can steal sessions. Missing SameSite means CSRF is worth testing. These are the first things to check in any Set-Cookie header.
📚 Further Reading and Resources
ME
Mr Elite
Founder, SecurityElites.com | Bug Bounty Hunter | Educator
I spent my first three months in bug bounty blindly copying techniques from YouTube videos without understanding why they worked. When I finally sat down and learned HTTP properly — not as a developer, but as someone trying to break things — everything clicked. The techniques stopped being magic and became logical. I started finding bugs nobody else found because I could look at a response and know exactly what was wrong with it. Day 3 is the day that transition happens for you.
