Before you can find and fix security flaws, you need a rock-solid understanding of how web applications actually function. Every vulnerability you will ever encounter exists because of a gap between how developers expect the web to behave and how attackers exploit its actual mechanics. This lesson builds that critical foundation.
At its core, the web operates on a client-server architecture. A client — typically a web browser — sends a request to a server, and the server processes that request and returns a response. This simple exchange is the foundation of every web application, from a basic blog to a complex banking platform.
The client is not limited to browsers. Mobile apps, command-line tools like curl, automated scripts, and even other servers can all act as clients. From a security perspective, this means you cannot trust any client to behave as expected — attackers craft custom requests that no legitimate browser would ever send.
💡 Think of the client-server model like a restaurant: the client is the customer placing an order, and the server is the kitchen preparing the meal. Security flaws arise when the kitchen blindly trusts every order without verifying it came from a legitimate customer.
HTTP (HyperText Transfer Protocol) is the protocol that governs communication between clients and servers. Every interaction — loading a page, submitting a form, uploading a file — happens through HTTP requests and responses. Understanding HTTP in detail is non-negotiable for any security professional.
An HTTP request consists of several key components: the method (GET, POST, PUT, DELETE), the URL path, headers (metadata about the request), and optionally a body (data being sent). The HTTP response contains a status code, headers, and a body (the actual content).
GET /login?user=admin HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Cookie: session=abc123Notice how much information is visible in a plain HTTP request. Every header, every parameter, every cookie is transmitted as text. This is why encryption (HTTPS) is critical — without it, anyone on the network can read and modify these requests.
| Method | Purpose | Security Concern |
|---|---|---|
| GET | Retrieve data from the server | Parameters visible in URL, browser history, and server logs |
| POST | Submit data to the server | Body data can be manipulated; CSRF attacks target POST endpoints |
| PUT | Update/replace a resource | If not properly authenticated, attackers can overwrite data |
| DELETE | Remove a resource | Unauthorized deletion if access controls are missing |
| OPTIONS | Describe communication options | Can reveal allowed methods — information leakage |
⚠️ Never rely on HTTP methods alone for security. A GET request can be turned into a POST request with a simple tool. Server-side validation must enforce authorization regardless of the HTTP method used.
Status codes tell the client what happened with their request. As a security tester, specific status codes reveal information about the server's behavior and potential vulnerabilities.
HTTP is stateless — each request is independent. To maintain user state (like being logged in), web applications use cookies. A cookie is a small piece of data the server sends to the client, which the client automatically includes in subsequent requests.
HTTP/1.1 200 OK
Set-Cookie: session_id=x7k9m2p4; HttpOnly; Secure; Content-Type: text/html
<html>Welcome back, user!</html>The session_id cookie is how the server recognizes you on each request. If an attacker steals this cookie (through XSS, network sniffing, or prediction), they can impersonate you entirely. This is called session hijacking, and it is one of the most common attack vectors in web security.
💡 The HttpOnly flag prevents JavaScript from accessing the cookie (mitigating XSS-based theft). The Secure flag ensures the cookie is only sent over HTTPS. Always look for these flags when assessing cookie security.
Let's trace a complete user login to see all the components working together. This lifecycle is where most vulnerabilities are introduced — at every step where user input is received, processed, or stored.
# Step 1: User requests the login page
GET /login HTTP/1.1
Host: example.com
# Step 2: Server returns the login form (HTML)
HTTP/1.1 200 OK
Content-Type: text/html
<form action="/login" method="POST">
<input name="username" />
<input name="password" type="password" />
<button>Login</button>
</form>
# Step 3: User submits credentials
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=admin&password=secret123
# Step 4: Server validates and creates a session
HTTP/1.1 302 Found
Location: /dashboard
Set-Cookie: session_id=a1b2c3d4; HttpOnly; SecureEvery arrow in this lifecycle is an attack surface. The username and password fields can be injection points. The session cookie can be stolen or forged. The redirect URL can be manipulated. Security professionals think about every single step.
Verify exercises to earn ★ 100 XP and unlock next lab level.