Post cover image

August 14, 2026

I Thought I Understood HTTP — Then I Opened Burp Suite

A hands-on journey into HTTP requests, responses, headers, cookies, and web application security.

By Taoqui

6 min read

A hands-on journey into HTTP requests, responses, headers, cookies, and web application security.

Introduction

When I started learning web security, I knew the basic idea behind HTTP.

A browser sends a request. A server sends a response. The browser displays the result.

I knew what GET, POST, status codes, cookies, and headers were supposed to mean.

But knowing the definitions is very different from actually seeing them.

I wanted to understand what was happening behind the browser whenever I opened a website, submitted a form, or interacted with a web application.

That's where Burp Suite became useful.

Instead of looking at a website as just a collection of pages, I could intercept the traffic between the browser and the server and see what was actually being sent.

And that changed how I looked at web applications.

I stopped seeing websites as pages and started seeing them as conversations made up of HTTP requests and responses.

Setting Up Burp Suite

For this experiment, I used Burp Suite Community Edition along with PortSwigger's Web Security Academy environment.

I used an authorized learning environment rather than testing arbitrary public websites.

The basic flow looked like this:

Browser
   |
   | HTTP Request
   v
Burp Suite Proxy
   |
   | Inspect / Modify
   v
Web Server
   |
   | HTTP Response
   v
Burp Suite Proxy
   |
   v
Browser

Burp Suite acts as an intermediary, allowing me to inspect requests before they reach the server and examine the responses coming back.

Intercepting My First HTTP Request

The first thing I wanted to see was a normal request generated when visiting a web page.

I opened the target in Burp's browser and enabled interception in:

Proxy → Intercept

When the browser requested the page, Burp paused the request.

This was the first moment where HTTP stopped being something abstract that I had only read about.

None

The request looked similar to:

GET /web-security HTTP/2
Host: portswigger.net
Cookie: session=[REDACTED]
User-Agent: Mozilla/5.0 ...
Accept: text/html,...

At first glance, this might look like a lot of text. But every part of it has a purpose.

Breaking Down the Request

Let's take the request apart.

1. The HTTP Method

GET /web-security HTTP/2

The first part is the HTTP method:

GET

GET is generally used when the client wants to retrieve a resource from the server.

In this case, the browser is requesting:

/web-security

The important thing I learned here was that the browser isn't simply "opening a page."

It's explicitly asking the server for a particular resource.

2. The Requested Path

/web-security

This is the path of the requested resource.

So the request can be thought of as:

GET → Give me the resource at /web-security

This seems simple, but looking at actual traffic made it easier to understand how URLs map to server-side resources and application functionality.

3. The HTTP Version

HTTP/2

The request was using HTTP/2.

Before working with Burp, I mostly thought about HTTP as a single protocol version.

Seeing the protocol version directly in the request made me realize that the browser and server also negotiate how that communication takes place.

For this article, I won't go deep into HTTP/2 internals. The important takeaway is simply that the HTTP version is part of the request and can be observed directly.

4. The Host Header

Host: portswigger.net

The Host header tells the server which host the request is intended for.

This becomes particularly interesting when working with servers that host multiple websites or applications.

Instead of thinking only about:

IP address → website

I started thinking about:

Client
   ↓
HTTP request
   ↓
Host header
   ↓
Specific web application

5. The User-Agent Header

The request also contained:

User-Agent: Mozilla/5.0 ...

The User-Agent provides information about the client making the request.

In this case, the request came from a browser running on my Linux environment.

This was another reminder that HTTP requests contain much more information than just the URL being requested.

What Happens After the Request?

After inspecting the request, I forwarded it to the server.

Burp then allowed me to see the response.

None None

The response started with:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8

This introduced the other half of the conversation:

the HTTP response.

The request is what the client sends.

The response is what the server sends back.

CLIENT                         SERVER
GET /web-security  ──────────>
                  <──────────  HTTP/2 200 OK

The 200 OK status tells the client that the server successfully processed the request.

Understanding the Response

The response contained several headers before the actual HTML content.

One of the most obvious was:

Content-Type: text/html; charset=utf-8

This tells the client what type of content is being returned.

In this case, the response contains HTML.

There were also security-related headers visible in the response, including headers such as:

Strict-Transport-Security
X-Content-Type-Options
X-Frame-Options
Content-Security-Policy

This was particularly interesting from a cybersecurity perspective.

These aren't just random pieces of metadata. HTTP headers can provide important information about how a web application handles security.

For example, a Content Security Policy can help control which resources a browser is allowed to load, while X-Frame-Options can help protect against certain framing-based attacks.

This was one of the first moments where I started looking at HTTP headers not just as technical details, but as part of a web application's security posture.

One Page Doesn't Mean One Request

After understanding the basic request and response, I opened:

Proxy → HTTP history

This was probably one of the most useful views in Burp Suite for understanding how modern websites work.

None

I initially expected to see one request corresponding to the page I opened.

Instead, I saw many requests.

The browser was requesting different resources such as:

HTML
CSS
JavaScript
Images
Fonts
API endpoints

This changed the way I thought about a webpage.

A modern web application isn't necessarily:

Open page
    ↓
One HTTP request
    ↓
One response

It can look more like:

┌── HTML
                    │
                    ├── CSS
Browser ────────────┼── JavaScript
                    │
                    ├── Images
                    │
                    ├── Fonts
                    │
                    └── API requests

Each of these interactions can generate its own HTTP request and response.

Burp Suite made all of those interactions visible.

Then I Found an API Request

While examining the traffic, I encountered something more interesting than a simple page request.

Burp captured a request like:

POST /api/widgets? HTTP/2
Host: portswigger.net
Cookie: [REDACTED]
User-Agent: Mozilla/5.0 ...
Accept: */*
Content-Type: application/json
Content-Length: 277
Origin: https://portswigger.net
Referer: https://portswigger.net/web-security
None

This was an important point in my learning process. I had started with the idea that:

"I am visiting a webpage."

But Burp was showing me that the browser was also communicating with API endpoints behind the scenes. The page itself was only part of the application.

GET vs POST in Practice

This also gave me a more practical understanding of HTTP methods.

A GET request might look like:

GET /web-security HTTP/2

The browser is requesting a resource.

A POST request might look like:

POST /api/widgets HTTP/2

The client is sending data to an endpoint.

The request also contained:

Content-Type: application/json

That tells the server that the request body contains JSON data.

This is where HTTP started becoming much more interesting to me.

Instead of memorizing:

GET retrieves data. POST sends data.

I could actually see applications using these methods in real traffic.

What Burp Suite Changed for Me

The biggest thing I learned wasn't a particular Burp Suite feature.

It was a change in perspective.

Before this exercise, I thought about a website mostly in terms of:

Pages
Buttons
Forms
Links

After intercepting the traffic, I started thinking about:

Requests
Responses
Endpoints
Methods
Headers
Cookies
Parameters
API calls
Sessions

That shift is important when learning web security.

A vulnerability doesn't exist simply because a page looks unusual.

It exists because somewhere underneath that interface, an application is processing requests and making decisions based on data supplied by a client.

Burp Suite gives me a way to observe those interactions.

What I Learned

Here are the biggest lessons I took away from this exercise:

1. Websites are conversations

The browser and server constantly exchange HTTP messages.

2. The browser hides a lot

A single page load can generate many requests that aren't obvious from the browser interface.

3. Headers matter

Headers can reveal information about how an application communicates and what security controls it has configured.

4. APIs are everywhere

Modern web applications frequently rely on API endpoints to exchange data in the background.

5. Burp makes HTTP visible

Tools like Burp Suite helped me move from theoretical HTTP knowledge to actually analyzing web application traffic.

6. Security testing starts with understanding normal behaviour

Before looking for vulnerabilities, I need to understand what normal requests and responses look like.

That baseline makes unusual behaviour much easier to recognize.