📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
DAY 3 OF 60
BUG BOUNTY MASTERY COURSE
FREE — ALL 60 DAYS
🟢 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.
📋 Day 3 Contents
- DNS — The Internet’s Phone Book
- The HTTP Request-Response Cycle
- HTTP Methods and Their Security Meaning
- Status Codes as Hunter Intelligence
- HTTP Headers — What They Hide and Reveal
- Cookies vs Sessions vs Tokens
- Same-Origin Policy and Why It Breaks
- HTTPS, TLS and What Burp Is Doing
- The Hunter’s HTTP Cheat Sheet
- Day 3 Task and Exercises
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.com
DNS 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.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)