HTTP in Detail

/ How The Web Works / By

What Is HTTP and How It Works

If you’re trying to understand how websites actually work, HTTP is a great place to start. Every time you visit a website, click a button, log in, or submit a form, you’re using HTTP. Whether you realize it or not.

As a pentester, you must understand HTTP. It’s the backbone of web communication, and it’s where a huge number of vulnerabilities live: broken authentication, session hijacking, insecure inputs, and more.

Let’s break it down in a way that makes sense.

Why Do We Use HTTP? Wasn’t the Internet Already Working?

Yes, the Internet existed before the web, but it wasn’t very user-friendly.

People used the early internet through services like:

  • Email (SMTP, POP3)
  • File transfers (FTP)
  • Remote access (Telnet)

There were no web browsers or clickable links — just raw protocols and command-line interfaces. It worked, but it wasn’t designed for everyday users or the kind of content-rich, interactive experiences we expect today.

HTTP changed that.

HTTP was designed to let people access and interact with documents — especially hypertext documents — using a web browser. It introduced a standard way for browsers (clients) and servers to talk to each other and made it easy to link documents together. That’s what gave us the World Wide Web.

So instead of typing obscure commands, you could just click a link and load a page. That simple shift exploded into the modern web.

HTTP is still used today because it’s:

  • Simple and universal
  • Flexible enough to support text, images, video, forms, and scripts
  • The foundation for web apps, APIs, and browser-based interactions

In short: the “normal internet” gave us the roads, but HTTP gave us the cars, the signs, and the way to actually go places.

The Flow of an HTTP Request

Here’s what happens, step-by-step:

  1. You type a URL into your browser.
  2. Your browser sends an HTTP request to the server.
  3. The server processes the request and sends back an HTTP response.
  4. Your browser renders the response (usually HTML, CSS, JavaScript).

This entire exchange happens in milliseconds — often dozens or hundreds of times per page load.

Example HTTP Request

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

Let’s break that down:

  • GET — The HTTP method (more on this in a sec)
  • /index.html — The resource you’re asking for
  • Host: — The domain you want to connect to
  • User-Agent: — Info about your browser
  • Accept: — What types of responses you’re willing to receive

Example HTTP Response

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 2048

<html>
  <body>
    <h1>Welcome to the site</h1>
  </body>
</html>

What’s happening here:

  • 200 OK — Status code saying “this worked”
  • Content-Type: — Tells the browser it’s getting HTML
  • Then the actual HTML is sent — that’s what gets displayed in your browser

HTTP Is Stateless (Why That Matters)

HTTP doesn’t remember anything between requests. Each request is independent — the server doesn’t “remember” who you are unless extra systems are in place (like cookies or tokens).

That’s why things like sessions and authentication tokens exist — to give HTTP a way to “remember” you between actions like logging in, clicking buttons, or viewing your profile.

This stateless nature is also where vulnerabilities like session fixation or cookie manipulation can creep in.

Common HTTP Methods (These Matter)

HTTP defines several methods — also called verbs — that describe what kind of action you’re taking.

Here are the most common ones:

  • GET – Ask the server for data (e.g., a web page). Data is sent in the URL.
  • POST – Send data to the server (e.g., submitting a login form). Data is sent in the body of the request.
  • PUT – Replace a resource with new data.
  • DELETE – Remove a resource.
  • HEAD – Like GET, but only asks for the headers (no body).
  • OPTIONS – Ask the server what methods are allowed.

As a pentester, GET and POST are the most important to understand early. You’ll use them in burp, curl, and other tools constantly.

HTTP Status Codes (Read These Carefully)

The server responds to every request with a status code. This tells the browser (and you) what happened.

Here’s a cheat sheet:

  • 200 OK – Everything worked.
  • 301 / 302 – Redirects.
  • 400 Bad Request – Client made a mistake.
  • 401 Unauthorized – You’re not logged in.
  • 403 Forbidden – You’re logged in, but not allowed to access it.
  • 404 Not Found – The thing doesn’t exist.
  • 500 Internal Server Error – The server broke.

When you’re testing or fuzzing, these status codes help you understand what’s going on behind the scenes — especially when you’re trying to enumerate files, directories, or bypass access controls.

Headers Are Where the Secrets Live

HTTP headers are key-value pairs that travel with requests and responses. Think of them as the metadata of your web traffic.

Every time you visit a page:

  • Your browser sends request headers to the server.
  • The server sends back response headers with the content.

These headers are invisible to the user, but they carry important information like:

  • What browser you’re using
  • Whether you’re logged in
  • Which site you’re trying to reach
  • And much more

A few example Headers:

  • Authorization: credentials or tokens
  • Cookie: session identifiers
  • User-Agent: identifies the client
  • Referer: where the request came from
  • Host: the target domain

If you’re getting into web hacking or pentesting, understanding headers is critical. They’re quiet, but they can reveal sensitive information, control how web servers behave, and open the door to real attacks.

In short: headers are a goldmine of information during web application testing.

Here’s what your browser might send when you log into a website:

POST /login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Referer: https://example.com/home
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=12345abcde

What These Mean:

  • Host: The website you’re trying to visit.
  • User-Agent: Your browser and system info.
  • Referer: The page you came from.
  • Content-Type: How you’re sending the login info.
  • Cookie: A session token — if stolen, someone could pretend to be you.

After logging in, the server might reply like this:

HTTP/1.1 302 Found
Location: /dashboard
Set-Cookie: authToken=abcdef123456; HttpOnly; Secure
Server: Apache/2.4.51

What These Mean:

  • Location: Redirecting you to your dashboard.
  • Set-Cookie: The server gives you a new session or auth token.
  • HttpOnly: JavaScript can’t access this cookie (good security).
  • Secure: Only works over HTTPS (also good).
  • Server: Sometimes shows what tech the site uses.

Here are some headers you’ll see often, and why you should care:

Authorization

Authorization: Bearer <token>

Used to prove who you are. You might be able to reuse or modify this to access other accounts or areas.

Cookie

Cookie: sessionid=abc123

Used to keep you logged in. Attackers love stealing these.

User-Agent

User-Agent: Mozilla/5.0...

Tells the server what browser or device you’re using. Some websites show different pages based on this.

Referer

Referer: https://example.com/profile

Shows where a request came from. Can help you find hidden pages or weak protections.

Host

Host: internal.example.com

Shows the website you’re requesting. You can change this to try accessing internal systems.

What You Can Do With Headers

Here’s what you, the hacker-in-training, can try:

1. Steal or Replay Tokens

Look for cookies or auth headers. Use them in your own requests to act as another user.

2. Spoof Headers

Change headers like User-Agent or Referer to trick the server.

3. Discover Hidden Paths

Look at Location and Referer values to find internal URLs.

4. Find Server Info

The Server header might tell you it’s running Apache, Nginx, or something old (and vulnerable).

5. Inject Into Headers

Try adding weird values to headers:

X-Forwarded-For: 127.0.0.1

Maybe the server thinks you’re local. You can also try injecting line breaks to mess with how the server reads your request.

Tools to See and Edit Headers

  • Burp Suite – The best tool for intercepting and modifying HTTP requests.
  • Browser Dev Tools – Open Network tab in Chrome or Firefox.
  • Curl – Command line: curl -H "User-Agent: evil-browser" http://example.com
  • Postman – Great for APIs and crafting custom requests.

HTTPS — Secure Version of HTTP

You’ll also see HTTPS everywhere. It’s just HTTP over TLS/SSL, which encrypts everything so attackers can’t snoop on the contents of the traffic.

That said, HTTPS doesn’t fix vulnerabilities in the app itself — it just protects the data in transit.

Yes — you’ve got the right idea! Let’s break it down in a clear, step-by-step flow to reinforce it:

What Happens When You Type a URL into Your Browser?(Extended)

  1. DNS Resolution:
    You type example.com into your browser. Your system first needs to figure out the IP address behind that domain.
    • It checks your local DNS cache.
    • If not found, it queries your DNS resolver (set by your ISP or manually).
    • Eventually, it gets the IP address, e.g., 93.184.216.34.
  2. TCP Handshake (Establishing Connection):
    Your browser establishes a TCP connection with the IP address of the web server (typically on port 80 for HTTP or 443 for HTTPS).
  3. TLS Handshake (If HTTPS):
    If it’s HTTPS (which most modern websites are), a TLS handshake happens to encrypt the session.
  4. HTTP Request Sent:
    Your browser sends a HTTP(S) GET request to the server for a specific resource: GET / HTTP/1.1 Host: example.com
  5. Server Responds:
    The server receives your request, processes it, and sends back a HTTP response (usually with an HTML page).
  6. Browser Renders the Page:
    Your browser parses the HTML, then fetches other resources like CSS, JS, images, etc., all through additional HTTP requests.

You Are Interacting With the Server

After DNS resolution, your browser connects directly to the server hosting the site, using HTTP(S). You’re talking to that server, requesting data, and getting responses. Think of it like:

“Hey server at this IP, can you give me the homepage of this website?”
“Sure thing, here’s the HTML. Also, you’ll need these stylesheets and scripts too.”

Summary

  • HTTP is the protocol for communication between browsers and web servers.
  • It uses requests and responses, with methods like GET and POST.
  • It’s stateless — which means sessions, cookies, and tokens are used to maintain user state.
  • Headers and status codes are critical to understand — they reveal what’s happening under the hood.
  • As a pentester, you’ll spend a ton of time reading, modifying, and replaying HTTP requests.

Related Posts

Scroll to Top