The web stack

01 Client and server, and who you can trust

Every web interaction has two halves. The client is your browser, running on your machine. The server is someone else's computer, running their code.

The split matters enormously, and it produces the single most important rule in web security.

02 The three languages in every page

You do not need to build websites. You need to recognise what each part does, because attacks target them differently.

That last row is cross-site scripting, usually written XSS, and it is one of the most common web vulnerabilities in the world. The attacker's goal is to get their JavaScript to run inside someone else's session, at which point they can read the page, submit forms, and steal the session token.

03 The anatomy of a request

Lesson 00.4 showed you a request in outline. Now look at the parts properly.

POST /login HTTP/1.1
Host: shop.example.com
User-Agent: Mozilla/5.0
Cookie: session=a3f9b2c8d1
Content-Type: application/x-www-form-urlencoded

username=alice&password=hunter2

Four things are worth naming, because you will manipulate all of them later.

• The method says what kind of action this is. GET asks for something, POST submits something. Others exist, including PUT and DELETE.
• The path says which resource is wanted. Attackers manipulate this to reach things they should not, which is called path traversal.
• The headers carry metadata, including the all-important cookie.
• The body carries submitted data, here the login form.

Send some requests and read the replies. Notice how much a status code gives away.

04 Sessions: how a website remembers you

HTTP is stateless. Each request arrives with no memory of the last one. The server genuinely does not know that the request asking for your inbox came from the same person who logged in a moment ago.

Cookies solve this. When you log in successfully, the server generates a random session identifier, stores it, and sends it back. Your browser then attaches it to every subsequent request automatically.

Notice what that means. After login, the token is the identity. Anyone holding it is you, as far as the server is concerned. No password required, and in most cases no second factor either.

The flags that protect a cookie

A missing flag on a session cookie is a genuine, reportable finding on a penetration test. You will check for exactly this in Phase 02.4.

05 The same-origin policy

Here is the rule that stops the web from being completely broken. A page from one origin cannot read data from a different origin.

An origin is the combination of scheme, domain and port. All three must match.

Without this rule, a malicious page you opened in one tab could quietly read your bank account in another. The same-origin policy is why it cannot.

06 APIs, where the real data lives

Modern sites often serve a nearly empty page and then fetch the actual data separately, as JSON, from an API. That means the interesting traffic is frequently invisible in the page source and only shows up in the network panel.

GET /api/v1/users/1042/orders HTTP/1.1
Host: shop.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Look at that path. It contains 1042, a user ID. The obvious question, and it is the right question, is what happens if you change it to 1043.

If the server returns someone else's orders, that is insecure direct object reference, usually shortened to IDOR. It is one of the most common and most damaging web flaws precisely because it is so simple. The server authenticated you, but forgot to check whether you are authorised for this specific record.

07 Do it on your real machine

Your browser contains a full inspection toolkit. Open developer tools in Safari or Chrome with Command + Option + I. In Safari you may first need to enable the Develop menu in Settings under Advanced.

Try this on this very page, which is served from your own machine so there is nothing to worry about:

1. Open the Network tab, then reload. Every file the page requested is listed, with its status code and size.
2. Click any request and look at the headers, matching them to section 03 above.
3. Open the Console tab and type document.title, then press Enter. You just ran JavaScript inside the page, which is exactly what an XSS attacker wants to achieve.
4. Open the Storage or Application tab and find Local Storage. Your lesson progress is stored there.

Now from the terminal. Fetch only the response headers:

curl -I https://example.com

See the full request and response including the TLS negotiation:

curl -v https://example.com -o /dev/null

Send a request with a custom header, the way a tool would:

curl -H "User-Agent: MidorCyber-Learning" -I https://example.com

Fetch some JSON from a public test API and look at the structure:

curl -s https://api.github.com/zen

Your checklist

• Can explain why client-side checks are not security controls
• Can name the four parts of an HTTP request
• Understand why a secret in a URL leaks even under HTTPS
• Know what the HttpOnly, Secure and SameSite flags each prevent
• Can decide whether two URLs share an origin
• Opened dev tools and inspected the network panel on this page
• Ran JavaScript in the console and saw local storage
• Can describe IDOR in one sentence

08 Final check

✓ Key takeaways

The things from this lesson worth carrying into the next one. If you remember nothing else, remember these.