None

People often jump straight to tools like Burp Suite, but without understanding HTTP, bug hunting becomes guesswork. This blog explains HTTP end to end, in simple language, with a security perspective.

HTTP Is a Conversation

At its core, HTTP is just a conversation between two parties:

Client (browser / app) → sends a request

Server (website / API) → sends a response

This request–response cycle is the foundation of the web.

HTTP Request — What the Client Is Asking

Whenever you open a page or submit data, your browser sends an HTTP request.

A request contains:

  • A method
  • A path
  • Headers
  • A body (sometimes)

Example:

GET /login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Cookie: session=abc123

From this alone, a lot is revealed:

  • What resource is being accessed
  • Which server is involved
  • Whether the user is logged in
  • What client is making the request

For a bug bounty hunter, this is pure signal.

HTTP Methods — What the Client Wants to Do

HTTP methods define intent. Understanding the method tells you what kind of bug to look for.

GET ⇒ Fetch data from the server (Data often appears in the URL, making it easy to manipulate. IDOR and info leaks are common here.)

POST ⇒ Submit data to the server (Forms, logins, APIs. This is where XSS, SQL injection, and logic bugs usually live.)

PUT ⇒ Completely update existing data (Often abused when authorization checks are missing.)

PATCH ⇒ Partially update existing data (Common source of business logic flaws.)

DELETE ⇒ Remove data from the server (Extremely sensitive. Missing access control here can be critical.)

OPTIONS ⇒ Ask the server what methods are allowed (Useful for API discovery and understanding CORS behavior.)

Request Headers — Client'sIdentity

Headers are metadata, but they control security decisions.

Some headers identify the user:

  • Cookies carry session identifiers
  • Authorization headers carry tokens

Some headers identify the request source:

  • Origin
  • Referer

Some describe the client:

  • User-Agent
  • Accept
  • Content-Type

These headers are powerful because:

  • Applications trust them
  • Attackers can modify them
  • Many vulnerabilities start here

Blind XSS, CORS misconfigurations, host header injection, and auth bypasses often involve headers.

Request Body — Actual User Input

The request body contains real user data.

This usually appears in POST, PUT, or PATCH requests.

The body can be:

  • Form encoded
  • JSON
  • XML

This is where:

  • Input enters the application
  • Validation may fail
  • Injection vulnerabilities originate

If data is mishandled here, it leads to XSS, SQL injection, or logic flaws.

HTTP Response — Server's Answer

After processing the request, the server sends a response.

A response contains:

  • A status code
  • Response headers
  • A body (HTML, JSON, etc.)

Example:

HTTP/1.1 200 OK
Set-Cookie: session=xyz456
Content-Type: text/html

The browser then:

  • Stores cookies
  • Enforces security headers
  • Executes JavaScript
  • Renders the page

This is where client-side vulnerabilities come into play.

Status Codes — Server Ka Mood

Status codes tell you how the server handled your request.

200 ⇒ Request successful 301 / 302 ⇒ Redirect (common in login flows) 400 ⇒ Bad request (input handling issue) 401 ⇒ Authentication required 403 ⇒ Access forbidden 404 ⇒ Resource not found 500 ⇒ Server error (often leaks useful information)

A key bug bounty insight:

Same request, different status codes → something is wrong.