This article teaches the foundational web protocol knowledge that enables bug bounty hunters to identify vulnerabilities systematically rather than mechanically. It covers DNS resolution, the HTTP request-response cycle, HTTP methods and status codes, authentication mechanisms, and the same-origin policy—arguing that mastering these concepts transforms vulnerability hunting from copying exploits into logical analysis of how systems fail.
Key insights
DNS reconnaissance reveals attack surface before testingDNS records expose hidden subdomains, third-party services, and development environments often less secured than production. Bug hunters query A records for host servers, CNAME records for forgotten subdomains, MX records for email infrastructure, and TXT records for SPF/DKIM data and token disclosure. Zone transfers, if misconfigured, dump all DNS records at once—a critical reconnaissance finding.
HTTP status codes signal injection and access control flawsA 500 error when fuzzing input indicates the request triggered unexpected server behavior—a strong injection signal warranting aggressive probing. A 200 response on an endpoint that should return 403 is an access control vulnerability. The 403 versus 404 distinction matters: 403 means 'I know who you are but no,' revealing the resource exists, while 404 hides resource existence. These patterns guide where to test and what to probe harder.
Every HTTP method has distinct security implicationsGET parameters should be tested for IDOR and injection. POST is the primary injection testing ground and CSRF target. PUT allows resource replacement and frequently lacks ownership verification—high-value target for privilege escalation. DELETE is irreversible and should be heavily authorized; missing ownership checks create critical IDOR findings. PATCH enables mass assignment attacks by allowing attackers to add fields like 'role':'admin' to request bodies. OPTIONS reveals what methods a server supports, often exposing unintended enabled methods.
Cookie security attributes directly enable specific attacksMissing HttpOnly allows JavaScript from XSS payloads to steal session tokens. Missing Secure allows cookies to transmit over HTTP, enabling interception. Missing SameSite (or set to None/Lax) enables CSRF attacks since cookies are sent in cross-site requests. The SameSite=Strict attribute prevents cross-site cookie transmission. Each missing attribute represents a concrete attack surface: hunters check all three attributes on every Set-Cookie header encountered.
Same-origin policy explains core vulnerability mechanicsThe browser security rule preventing JavaScript on one origin from reading responses from different origins explains why XSS is dangerous—malicious code runs on the trusted origin, bypassing SOP restrictions. CSRF works because SOP blocks cross-origin reads but not writes; forms submit to other origins with cookies automatically included. CORS misconfigurations deliberately relax SOP, and when a server reflects any Origin header with Allow-Credentials: true, any website can read that user's sensitive API responses—a high-severity finding.
Server version disclosure in headers reveals CVE pathwaysHeaders like Server: Apache/2.2.31 and X-Powered-By: PHP/7.4.3 leak software versions. PHP 7.4.3 reached end-of-life in November 2022 with known vulnerabilities. Hunters research exact versions for CVEs and report only when demonstrating real impact, as many programs exclude standalone version disclosure from scope. Debug tokens and X-Debug-Token headers left enabled expose stack traces, internal paths, and secrets.
JWT tokens contain exploitable structural weaknessesJWTs starting with 'eyJ' can be decoded on jwt.io to reveal encoded user data including user_id, role, and expiry. Attack surface includes algorithm confusion (attackers changing RS256 to HS256), weak secret keys allowing forgery, the 'none' algorithm bypass, and claim tampering. Understanding JWT structure during reconnaissance prepares hunters for Day 17's signature and algorithm attacks where tokens can be forged or modified.
Burp Suite's man-in-the-middle decryption requires trustBurp functions as a man-in-the-middle proxy by intercepting TLS connections from the browser to itself at 127.0.0.1:8080 (using the installed CA certificate), decrypting traffic to show plaintext HTTP, then making a separate TLS connection to the real server. This works only because the user explicitly trusted Burp's CA certificate in the browser. Understanding this mechanism explains why installing untrusted certificates is dangerous—any certificate authority could decrypt and modify your traffic.
Bottom line: Mastering HTTP fundamentals—DNS reconnaissance, request-response structure, status codes, method behaviors, authentication mechanisms, and same-origin policy—transforms bug bounty hunting from blindly applying tools into logical analysis of where systems fail. Hunters who understand these concepts find vulnerabilities automated scanners miss because they can read a response and immediately know what security control has broken down.
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.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 6)
# Look up the main records (most servers now refuse ANY)
dig target.com A +short
# 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. PHP 7.4.3 is end-of-life since November 2022. Beginners walk past these headers. Hunters treat them as leads: most programs list version banners as out of scope on their own, so look up CVEs for that exact version and report only when you can show real impact.
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.com
HTTP 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.com
HTTP 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.
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 — What They Hide, What They Reveal, What They Protect
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-Policy
Missing = no extra XSS protection. Not a bug by itself, but an XSS you find elsewhere is more likely to work.
X-Frame-Options
Missing = clickjacking may be possible. Only reportable if a sensitive action can be framed (Day 20).
Strict-Transport-Security
Missing = SSL stripping possible. Usually out of scope on its own.
INFORMATION-LEAKING HEADERS
Server: Apache/2.2.31
Version disclosure. Apache 2.2.31 is end-of-life. Look up CVEs immediately.
X-Powered-By: PHP/7.1.0
EOL PHP has known RCE vulnerabilities. Always research the specific version.
X-Debug-Token: 1a2b3c
Debug mode left on. Worth investigating: an exposed debug profiler can reveal stack traces, internal paths and secrets.
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.com
COOKIE ANATOMY — EVERY ATTRIBUTE MATTERS TO A HUNTER
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 17 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
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 deliberately allows specific cross-origin requests. When misconfigured — especially when the server reflects any Origin back in Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true on an API returning sensitive user data — any website can read that user’s private API responses. (A plain wildcard * cannot be combined with credentials, so it is usually lower risk.) 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
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 → Usually out of scope alone: note it, look for a bug it enables
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 17’s attacks.
Goal: Decode 1 JWT and understand its claims
★
Look Up DNS Records for Your Selected Bug Bounty Program
Run dig target.com A +short, then dig target.com MX +short and dig target.com TXT +short on your chosen program’s domain. Note the mail and verification services the TXT records reveal. Then search crt.sh for the domain to list subdomains from certificate logs. Only visit subdomains that the program lists as in scope. Are there development or staging subdomains? Write down everything — you are building a target map before you test anything.
⭐ 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 practice only: most programs list missing headers as out of scope, so do not submit these unless the policy explicitly accepts them. This is your first practice report — even if you do not submit it yet, writing it solidifies the methodology.
🧠
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.
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.
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.
Founder of Securityelites and creator of the SE-ARTCP credential. Working penetration tester focused on AI red team, prompt injection research, and LLM security education.
