How the Web Works

3.1 · The request and the response

Every time you open a web page, your browser (the client, from Module 2) sends a request to a web server, and the server sends back a response. That is the entire model — everything else is detail. The language the two speak is HTTP, the HyperText Transfer Protocol. HTTPS is the same conversation wrapped in encryption, so nobody in between can read it.

The important realisation is that a request is just text:

GET /profile HTTP/1.1
Host: bank.example.com
Cookie: session=8f3a1b...

The first line says what the client wants (GET) and which resource (/profile). The lines below are headers — extra details. The server replies with a status line, its own headers, and usually a body. From this one fact grows the most important habit in web testing: the page you see is only the response. A tester works at the request/response level, because that is where you can change things the page never intended.

3.2 · Anatomy of a URL

Every request in the last section began with a URL — the address in your browser bar. You have typed thousands of them without ever being shown how they are put together. That is worth fixing now, because a URL is not one thing: it is five or six separate parts, and a tester reads each of them differently.

Here is a full one, with every part present:

Reading a URL as a tester

Once the parts separate, a URL stops being an address and becomes a list of questions. Look again at ?id=42. Nothing stops you changing it to ?id=43 and pressing Enter — and if the server hands back somebody else's statement, you have found a real and very common flaw. You will meet it properly by name in the Beginner course; for now, simply notice that the number was sitting in plain sight, editable, and the application trusted it.

The fragment deserves its own note for the same reason in reverse. Because #summary never leaves the browser, anything built from it can only ever be attacked in the browser — which is why one family of web flaws is described as living purely on the client side.

Finally, a loop back to Module 1. A URL may only contain a restricted set of characters, so anything else is URL-encoded into a % and two hex digits — a space becomes %20 and a slash becomes %2F. When a URL in a report is full of percent signs, that is all it is: ordinary characters wearing a travel disguise.

3.3 · Methods, status codes and headers

The first word of a request is its method — the kind of action. Two cover most traffic: GET (fetch something) and POST (send data, e.g. submit a form). You will also meet PUT and DELETE, which typically update and remove data. Rough rule: reading is usually a GET; sending or changing is usually a POST.

Status codes

The reply begins with a three-digit status code. Learn what each opening digit means, plus a few specifics:

These are signals to a tester. A 403 where you expected a page hints something exists but you are not allowed to see it. A 500 after you sent an odd value hints your input broke something server-side — often the first sign of a deeper flaw.

Headers

Headers are the name-value lines carrying extra detail on both requests and responses. Host names the site; User-Agent describes your browser; Content-Type says whether a body is HTML, JSON, and so on; Cookie and Authorization carry your identity. Much security-relevant behaviour hides in headers, so testers read them closely.

3.4 · Cookies and sessions

HTTP has a quirk that shapes a huge amount of web security: it is stateless. Each request stands alone; the server does not automatically remember the one before. So how does a site remember you are logged in as you click around? With cookies.

When you log in, the server creates a session — a record on its side saying "this visitor is Priya, logged in" — and hands your browser a small session cookie that works like a cloakroom ticket. Your browser attaches that cookie to every later request, and the server matches the ticket to its record.

That cookie is your identity for the visit. If someone steals it, they can present your ticket and the server treats them as you — no password needed. This is why so much web security protects cookies, and why you will hear flags like HttpOnly (stops page scripts reading the cookie) and Secure (only send over HTTPS). Hold the core idea: a session lives on the server, and a cookie is the ticket that points to it — so a stolen cookie is a stolen identity. (APIs, later in this module, often carry identity as a token instead of a cookie — same idea, different wrapper.)

3.5 · Authentication vs Authorization

These two words sound alike and are constantly confused, but they name two different checks — and the difference is central to web (and API) security.

• Authentication (authn) answers "who are you?" — proving identity, usually with a password, one-time code, or fingerprint. Logging in is authentication.
• Authorization (authz) answers "what are you allowed to do?" — deciding, once you are known, which pages and actions you may reach. A normal user blocked from the admin panel is authorization.

Many real, high-impact findings are authorization failures. Picture a logged-in customer (authenticated correctly) who changes a number in the URL — account?id=1007 to id=1008 — and suddenly sees another customer's statement. The system knew who they were; it failed to check what they were allowed to see. When you later study "access control" and the bug called IDOR, this is the exact gap — and as you will see next, it is often the API that fails to check. Keep the two questions apart: who are you versus what may you do.

3.6 · Two shapes of web app — traditional and single-page

Not all web apps are built the same way, and you will meet both shapes on real engagements. Knowing which one you are looking at tells you where the interesting requests are.

Traditional (server-rendered) apps

The older, still-common style: every click asks the server for a whole new HTML page. You click a link, the browser sends a request, the server builds a complete page and sends it back, and the browser throws away the old page and shows the new one. You see a full reload — a flash, a fresh page — on each action. Here the interesting requests are page loads and form submissions.

Single-page applications (SPAs)

The modern style. A single-page application loads once — the browser downloads a bundle of JavaScript, and after that the JavaScript running in your browser updates the page in place, with no full reloads. It feels like a desktop app. When it needs fresh data, it does not fetch a whole new page; it quietly calls the server's API in the background and receives just the data (usually JSON, from Module 4), then redraws the relevant part of the page. Apps built with React, Angular or Vue are SPAs.

Why this matters to a tester: in a traditional app, the action is in page loads and form posts. In a SPA, the page you see is almost empty of logic — the real work happens in the background API calls. If you only look at the visible page, you miss where the security actually lives. The tell, in the DevTools Network tab, is a stream of small background calls to paths like /api/... returning JSON. That API is the subject of the next two sections.

3.7 · APIs — the frontend/backend split

Modern apps are split in two. The frontend is what runs where you can see it — the SPA in your browser, or a mobile app. The backend is the server that actually holds the data and makes the decisions (can this user transfer money? does this account exist?). The two talk through an API.

The three tiers behind a page

Stand back from a single request and almost every web application has the same three-part shape. Take one ordinary action — a customer taps Check balance:

Follow the tap through. The frontend sends an API call such as GET /api/accounts/42/balance, carrying whatever proves who you are. The backend checks that the session is valid, checks that this customer is allowed to see that account, and only then asks the database for the number. The database knows nothing about customers or permissions; it answers whatever it is asked. The backend formats the reply, and the frontend draws it on screen.

Notice where the judgement happens. Only the middle tier decides anything. The frontend is a display, the database is a filing cabinet, and every question of "may this person do this?" is answered in between. That is why the middle tier gets the attention — and why, if it forgets to ask, nothing else in the picture will catch the mistake.

What an API is

API stands for Application Programming Interface — a defined set of requests the backend agrees to accept. For the web it is usually a REST API: a list of URLs called endpoints, each doing one job, exchanging JSON (Module 4). For example:

GET    /api/accounts/42      // fetch account 42 → returns JSON
POST   /api/transfer         // send money (JSON body)
DELETE /api/users/5          // delete user 5

The frontend is, in a sense, just a pretty shell around these calls. Every button you press turns into an API request behind the scenes.

Types of API you will meet

REST is the common case, not the only one. You do not need to work with these yet — you need to recognise the names when a client says which one they run, because the testing approach changes with the shape.

Two of those carry a practical warning. A SOAP service takes XML, and XML brings its own family of flaws that JSON simply does not have. GraphQL lets the caller compose the request, so an endpoint that looks like one harmless query can often be persuaded to return far more. Both are taught properly later — here, the point is only that "it is an API" does not mean "it is a REST API".

Why the API is the real attack surface

Here is the point that reshapes how you test. Because the backend does the real work, an attacker can call the API directly and ignore your frontend entirely. The pretty page might hide the "delete user" button from a normal user — but if the endpoint DELETE /api/users/5 does not itself check authorization (Module 3.5), anyone who knows the URL can call it and it will work. The frontend's hiding was never a real control. This is why so much modern testing is API testing: the security must live in the backend, because the frontend can always be bypassed.

One more practical note on identity: APIs often carry it as a token — a long string sent in an Authorization: Bearer … header (frequently a JWT) — rather than a cookie. Same idea as the session ticket from 3.4, delivered in a header instead.

3.8 · One backend, many clients — and the API gateway

Now the piece that surprises freshers most. The same backend API usually serves several clients at once. Your bank's website (a SPA) and your bank's mobile app (on iOS and Android) are not two separate systems — they are two frontends talking to the same backend API. Partner integrations may use it too.

The consequence is important: a flaw in the API affects every client. It also means a mobile app is not a separate mystery — it usually just calls the same endpoints your web SPA does, so testing the API covers the shared surface behind both.

The API gateway

As backends grow, they are often split into many small services (accounts, payments, login…). Rather than expose each one, organisations put an API gateway in front — a single "front door" that every API call passes through. The gateway routes each request to the right service behind it, and commonly handles the cross-cutting jobs in one place: authentication, rate limiting (blocking floods of requests), TLS/HTTPS, and logging. You will hear product names like AWS API Gateway, Apigee or Kong. For a consultant, the gateway is frequently the main entry point you are pointed at — so recognise the term and what sits behind it.

3.9 · Browser DevTools

Every modern browser ships with Developer Tools ("DevTools"), opened with F12 or right-click → Inspect. It is free, already installed, and the first window into how a site really behaves — including the API calls you just learned about.

Three tabs matter early:

• The Elements tab shows the live HTML of the page — the DOM (Module 4).
• The Network tab records every request and response — page loads and, on a SPA, the background API calls (often filtered as "Fetch/XHR"). This is where you catch the JSON traffic behind a modern app.
• The Console tab shows JavaScript messages and lets you run snippets — where you ran atob() in Module 1.

You will eventually add a dedicated tool such as Burp Suite, which sits between browser and server so you can pause and edit requests — including API requests — before they are sent. But DevTools is where the habit starts.

Module 3 glossary

HTTP / HTTPS

The web's request/response protocol; HTTPS is the encrypted version.

Request / Response

The client's ask and the server's answer — both plain text with headers.

Method

The action: GET (fetch), POST (send), PUT/DELETE (update/remove).

Status code

2xx success, 3xx redirect, 4xx your fault, 5xx server's fault.

Header

A name-value line carrying extra detail (Host, Cookie, Authorization, Content-Type).

URL

Scheme, host, optional port, path, query string and fragment — e.g. https://host/path?id=42#top.

Query string

Everything after the ? — name=value pairs joined by &. User-editable input.

Fragment

Everything after the #. Stays in the browser and is never sent to the server.

Session / Cookie

A server-side "logged-in" record, and the ticket the browser sends to point to it.

Authentication / Authorization

Who you are (login) / what you may do (access).

Traditional app

Server-rendered — each click loads a whole new HTML page.

SPA (single-page app)

Loads once, then updates in place by fetching data from an API (React/Angular/Vue).

Frontend / Backend

What runs where you see it (browser/mobile) / the server holding data and logic.

API / REST / endpoint

The interface to the backend; REST endpoints (URLs) exchanging JSON.

Three tiers

Frontend displays, backend decides, database stores. All authorisation belongs in the middle tier.

SOAP / GraphQL / gRPC

Other API shapes: XML envelopes (older BFSI systems) / one endpoint the client queries by field / compact binary between internal services.

Token / Bearer / JWT

Identity carried in an Authorization header, common for APIs (instead of a cookie).

API gateway

The single front door in front of backend services — routing, auth, rate limiting, TLS.

DevTools

The browser's built-in inspector (F12): Elements, Network (incl. Fetch/XHR), Console.