How HTTP Works

beginner20 minWriteup

Understanding HTTP protocol, methods, headers, and status codes for web security testing

Learning Objectives

  • Understand the HTTP request/response cycle
  • Learn common HTTP methods (GET, POST, PUT, DELETE)
  • Identify security-relevant headers
  • Recognize different status codes and their meanings

Welcome to the Web's Secret Language

Imagine you're at a restaurant. You sit down, look at the menu, and tell the waiter "I'd like a burger with extra cheese, please." The waiter nods, walks to the kitchen, and comes back with your food. Simple, right?

That's exactly how the web works. When you type "google.com" in your browser, you're essentially placing an order. Your browser (the customer) asks a server (the kitchen) for a webpage (your burger). The language they use to communicate? That's HTTP - Hypertext Transfer Protocol.

Understanding HTTP isn't just nice to have for hackers - it's absolutely essential. Every single web vulnerability, from SQL injection to XSS to authentication bypasses, happens within HTTP requests and responses. If you don't understand HTTP, you're trying to hack blindfolded.

Why This Matters

About 90% of penetration testing involves web applications. HTTP is the foundation of it all. Master this, and everything else becomes 10x easier to understand.

What Exactly IS HTTP?

HTTP stands for Hypertext Transfer Protocol. Let's break that down:

  • Hypertext: Fancy word for text with links. You know, clickable stuff that takes you places. Revolutionary in 1989, boring now.
  • Transfer: Moving data from one place to another. Like texting, but for computers.
  • Protocol: A set of rules for how to communicate. Like how in English we agree that "hello" is a greeting, computers agree that "GET" means "give me something."

HTTP was invented by Tim Berners-Lee in 1989 at CERN (yes, the particle accelerator place). He wanted scientists to share documents easily. Little did he know he'd create the backbone of cat videos, online shopping, and... well, cybersecurity careers.

HTTP is "stateless" - meaning each request is independent. The server has the memory of a goldfish. It doesn't remember you from one request to the next. (This is why cookies were invented, but that's another lesson!)

The Request-Response Dance

Every HTTP conversation follows the same pattern:

  1. Client sends a Request: "Hey server, can I have the homepage?"
  2. Server sends a Response: "Sure! Here's the HTML for the homepage."

That's it. Request → Response. Over and over, thousands of times when you load a single webpage. Every image, every script, every stylesheet is a separate request.

Think of it like a very polite ping-pong game where one player only serves (the client) and one only returns (the server). Except sometimes the server returns an error, which is like returning the ball directly into your face.

A Simple Request

When you visit http://example.com/page, your browser sends something like this:

HTTP Request
1GET /page HTTP/1.1
2Host: example.com
3User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
4Accept: text/html,application/xhtml+xml
5Accept-Language: en-US,en;q=0.9
6Connection: keep-alive

A Simple Response

The server responds with:

HTTP Response
1HTTP/1.1 200 OK
2Content-Type: text/html; charset=UTF-8
3Content-Length: 1234
4Date: Mon, 29 Dec 2025 12:00:00 GMT
5Server: Apache/2.4.41
6 
7<!DOCTYPE html>
8<html>
9<head><title>Welcome!</title></head>
10<body>
11<h1>Hello, World!</h1>
12</body>
13</html>
See that blank line between the headers and the HTML? That's crucial! It separates the headers (metadata) from the body (actual content). Miss this, and your HTTP parsing is broken.

Anatomy of an HTTP Request

Let's dissect a request like a frog in biology class (but less gross and more useful):

1. Request Line

The first line contains three things:

1GET /page HTTP/1.1
2│    │      │
3│    │      └── HTTP Version
4│    └── Path (what you want)
5└── Method (what you want to DO)

2. HTTP Methods (The Verbs)

HTTP methods tell the server what action you want to perform. Think of them as verbs:

MethodPurposeAnalogy
GETRetrieve data"Show me the menu"
POSTSend data to create something"I'd like to place an order"
PUTUpdate/replace data"Change my order to a salad"
DELETERemove data"Cancel my order"
PATCHPartially update data"Add extra cheese to my burger"
OPTIONSWhat methods are allowed?"What CAN I order here?"
HEADLike GET but no body"Is the kitchen open?" (don't need food)
Security Note: Many developers only protect GET and POST, forgetting about PUT, DELETE, PATCH, etc. As a pentester, always check what happens when you use unexpected methods!

3. Headers

Headers are key-value pairs that provide extra information. They're like the metadata of your request - they don't affect WHAT you're asking for, but HOW.

http
1Host: example.com              → Which website (required!)
2User-Agent: Mozilla/5.0...     → What browser/tool you're using
3Accept: text/html              → What format you want back
4Cookie: session=abc123         → Your identity token
5Content-Type: application/json → Format of data YOU'RE sending
6Authorization: Bearer xyz      → Your credentials
The Host header is required in HTTP/1.1. Why? Because one server can host multiple websites (virtual hosting). Without Host, the server wouldn't know which site you want!

Anatomy of an HTTP Response

1. Status Line

1HTTP/1.1 200 OK
2│        │   │
3│        │   └── Reason phrase (human-readable)
4│        └── Status code (machine-readable)
5└── HTTP version

2. Status Codes (The Server's Mood)

Status codes are 3-digit numbers that tell you how the server feels about your request. The first digit indicates the category:

1xx
Informational
"Hold on, I'm thinking..."
2xx
Success
"Here you go! All good!"
3xx
Redirection
"Go look over there instead"
4xx
Client Error
"You messed up."
5xx
Server Error
"I messed up."

Common Status Codes You'll See Daily

1200 OK           → Success! Here's your data.
2201 Created      → Success! I made the thing you asked for.
3204 No Content   → Success! Nothing to show though.
4301 Moved        → This moved permanently. Update your bookmarks.
5302 Found        → Temporary redirect. Check here instead.
6400 Bad Request  → Your request makes no sense to me.
7401 Unauthorized → Who are you? Login first.
8403 Forbidden    → I know who you are. You can't have this.
9404 Not Found    → Doesn606070;">#a5d6ff;">'t exist. The internet's "¯\_(ツ)_/¯"
10405 Method Not Allowed → You can't POST here, buddy.
11500 Internal Server Error → Server crashed. Oops.
12502 Bad Gateway  → Server asked another server and got garbage.
13503 Service Unavailable → Server is overloaded or down.

Security Gold

Status codes can leak information! A 403 vs 404 tells you whether a resource EXISTS (forbidden) or doesn't exist at all. Smart attackers use this to enumerate hidden files!

HTTP vs HTTPS: The "S" That Matters

HTTP sends everything in plain text. Anyone between you and the server can read everything. Your passwords, your messages, your embarrassing searches - all visible to:

  • Your ISP (Internet Service Provider)
  • The coffee shop WiFi owner
  • Hackers on the same network
  • Government agencies
  • That sketchy dude in the corner

HTTPS (HTTP Secure) wraps everything in TLS encryption. It's like putting your letter in a locked box that only the recipient can open.

❌ HTTP
1GET /login HTTP/1.1
2Host: bank.com
3 
4username=alice
5password=supersecret123

Everyone can see "supersecret123"

✓ HTTPS
1[Encrypted Gibberish]
2x7Fk2mN9pQr3...
3aB4cD5eF6gH7...
4[More Encrypted Stuff]

Only you and the server can read this

Even with HTTPS, the server can still see everything you send. HTTPS protects data in transit, not at the destination. If the server is compromised or malicious, HTTPS won't save you.

See HTTP for Yourself

Theory is nice, but let's get our hands dirty. Here are ways to actually SEE HTTP requests:

1. Browser DevTools (Easiest)

View HTTP in Chrome/Firefox

Press F12 or Ctrl+Shift+I to open DevToolsClick the 'Network' tabRefresh the page (F5)Click any request to see detailsLook at Headers, Response, Timing tabs

2. cURL (Command Line)

cURL is your best friend for manual HTTP requests:

Terminal
1606070;"># Simple GET request
2curl -v https:606070;">//example.com
3 
4606070;"># See just headers
5curl -I https:606070;">//example.com
6 
7606070;"># Send a POST request
8curl -X POST -d 606070;">#a5d6ff;">"name=test" https://example.com/api
9 
10606070;"># Custom headers
11curl -H 606070;">#a5d6ff;">"Authorization: Bearer token123" https://example.com/api
The -v flag shows the full request and response. Use -vvv for even more detail!

3. Burp Suite (The Pro Way)

Burp Suite is an intercepting proxy that sits between your browser and the internet. You can see, modify, and replay any request. It's the essential tool for web pentesting.

Up Next

Burp Suite Basics

Learn to intercept and modify HTTP requests like a pro

Security Implications (The Fun Part)

Now that you understand HTTP, let's talk about why hackers love it:

1. Everything is Modifiable

Any part of an HTTP request can be changed. Headers, body, method - all of it. Developers who trust ANY data from the request are making a mistake.

2. User-Agent Lies

The User-Agent header says what browser you're using. But you can set it to anything:

bash
1606070;"># Pretend to be a iPhone
2curl -A 606070;">#a5d6ff;">"Mozilla/5.0 (iPhone; CPU iPhone OS 14_0 like Mac OS X)" example.com
3 
4606070;"># Pretend to be Googlebot (sometimes bypasses restrictions!)
5curl -A 606070;">#a5d6ff;">"Googlebot/2.1" example.com

3. Hidden Parameters

Just because a parameter isn't in the form doesn't mean it's not checked. Try adding parameters:

1Original: POST /api/user
2Body: name=john
3 
4Try: POST /api/user
5Body: name=john&admin=true&role=superuser

4. Method Tampering

Some servers behave differently with different methods:

bash
1606070;"># Maybe GET is blocked but HEAD isn't?
2curl -X HEAD example.com/admin
3 
4606070;"># Some servers allow X-HTTP-Method-Override
5curl -X POST -H 606070;">#a5d6ff;">"X-HTTP-Method-Override: DELETE" example.com/api/user/1

Test Your Knowledge

Quick Quiz
Question 1 of 5

What does the '200' in 'HTTP/1.1 200 OK' represent?

Hands-On Challenge

Decode This HTTP Request

Challenge
🌱 easy

A suspicious HTTP request was captured. Based on what you learned, analyze it and answer: What is the attacker trying to do? What sensitive information is exposed?

http
1DELETE /api/admin/users/42 HTTP/1.1
2Host: vulnerable-app.com
3Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
4Content-Type: application/json
5Cookie: session=abc123; admin=true
6 
7{
8  606070;">#a5d6ff;">"reason": "User requested deletion",
9  606070;">#a5d6ff;">"admin": true,
10  606070;">#a5d6ff;">"password": "admin123"
11}

Need a hint? (3 available)

Interactive Practice

Build an HTTP Request
text

Complete the HTTP request below to fetch the homepage of example.com. Fill in the blanks with the correct values.

Key Takeaways

  • HTTP is the language browsers and servers use to communicate - every web hack happens here
  • Requests have a method (GET, POST, etc.), headers, and optionally a body
  • Responses have a status code (200, 404, 500, etc.), headers, and a body
  • HTTPS encrypts the communication so eavesdroppers can't read it
  • Every part of an HTTP request can be modified by attackers
  • Status codes can leak information about what exists on a server
  • Learn to use DevTools and cURL - you'll use them constantly

Continue Your Journey