Skip to content

Intermediate · Web application testing: Burp Suite and the basics · topic 18 of 35 · 18 min

How web requests work (and why that matters)

Explanation

Every web action is a request from the browser and a response from the server. A request has a method (GET, POST), a path, headers and sometimes a body. Understanding this exchange is the foundation of all web testing: attacks work by changing the request.

The request/response cycle

When you use a website, your browser sends an HTTP request to the server, and the server sends back an HTTP response. HTTP is the simple text-based language they use. Every click, search and form submission is one or more of these request/response pairs.

A request has a few parts: a method (what you want to do), a path (which resource), headers (extra information), and sometimes a body (data you are sending). The response has a status code (how it went), headers, and usually a body (the page or data).

MethodMeansTypical use
GETFetch somethingLoading a page; data goes in the URL
POSTSend data to create/actSubmitting a form or login
PUT / PATCHUpdate somethingEditing a record via an API
DELETERemove somethingDeleting a record via an API

A request in plain text

output
POST /login HTTP/1.1
Host: shop.example
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123

username=asha&password=secret
A login POST request: the method, path, headers, and a body with the form fields.

Status codes tell you what happened

CodeMeaning
200OK — it worked
301 / 302Redirect — go somewhere else
400Bad request — your input was wrong
401 / 403Not authenticated / not allowed
404Not found
500Server error — something broke on their side

Why this is the key to web testing

The browser is just one way to send requests. A tester can send any request they like, with any values, using a proxy or a command-line tool. Most web attacks are simply sending a request the developer did not expect: a changed ID, an extra quote, a script in a field. If you understand the request, you understand the attack surface.

Think of it like this: Think of the request as a form you post to an office. Normally you fill the blanks politely. A tester tries writing unexpected things in the blanks to see if the office handles them safely. The clerk (the server) should reject anything odd — and the whole game is finding where it does not.
Tip: The best first habit in web testing is to watch the real requests your browser sends (in the browser's developer tools, Network tab, or a proxy). Once you can read them, the attacks make sense.

Need help?

Stuck on a word or an idea? Search this course, or every course, and jump straight to the explanation or a worked question.

Try:

Watch the lesson

How web requests work (and why that matters) · 1/7

Request → Response

Every web action is a request from the browser and a response from the server.

Prefer a video by a teacher? Find free videos on “http request response methods status codes explained beginners” on YouTube ↗

In real life: Seeing a login for what it is

A learner opens the browser's developer tools and logs into a lab app. In the Network tab she sees a POST to /login with username and password in the body, and a Set-Cookie header in the response giving a session cookie. Suddenly the "login" is not magic: it is one request and one response she can read and, with a proxy, change. That shift in understanding is what makes web testing possible.

Practice (0/3 done)

Task 1 · Question

Which HTTP method is normally used to submit a login form?

Task 2 · Question

An HTTP 403 response means…

Task 3 · Code · Python

Write status_meaning(code) returning a short meaning: 200 -> "OK", 404 -> "Not Found", 500 -> "Server Error". For any other code return "Other".

Quick quiz

Question 1

1.HTTP is…

Question 2

2.With a GET request, data usually goes in the…

Question 3

3.A 500 status code means…

Question 4

4.Most web attacks work by…

Read more (free)

Open a question to see the answer and why. The first ones are this topic's own quiz, so try the quiz above before you peek.

HTTP is…

Answer: The text-based language browsers and servers use

HTTP is the request/response protocol of the web.

With a GET request, data usually goes in the…

Answer: URL

GET carries data in the URL (query string).

A 500 status code means…

Answer: A server-side error

5xx codes mean something broke on the server.

Most web attacks work by…

Answer: Sending a request the developer did not expect

Unexpected input in a request is the core of web attacks.

Which part of an HTTP request carries the JSON data you send?Related

Answer: The body

The body comes after the headers and the empty line, and holds the data.

From HTTP requests, responses and methods

Hundreds of 404 responses for paths like /backup.zip, /.git/config and /admin.php from one IP suggest…Related

Answer: Someone probing for hidden files

Automated scanners try many common hidden paths, producing many 404s.

From HTTP, HTTPS and TLS

How does net/http handle many requests at once?Related

Answer: Each request runs in its own goroutine

The server starts a goroutine per connection/request.

From An HTTP server with net/http

What must the body of a JSON POST be?Related

Answer: A string made with JSON.stringify

fetch sends text; stringify the object.

From fetch: talking to servers

Pass the quiz (60% or more) or mark this topic as done when you are ready.

Your progress is saved on this device only.

Next: Burp Suite basics: the intercepting proxy →

Next steps

  1. 2 more topics in “Web application testing: Burp Suite and the basics” before its exam: Burp Suite basics: the intercepting proxy, The OWASP approach to web testing.
  2. Module 6 exam: web testing and Burp · 12 questions · 20 min, without help. 3 topics of this module still to finish first.
  3. Then the next module, Web attacks and their fixes. 35 topics left in the course before the final exam.

← Previous: Vulnerability scanners: OpenVAS and Nessus (concepts)