How websites work.
Most attacks on companies today target websites and apps. To understand web attacks in the next lesson, you first need to see what happens when you tap "Login" on any website. It's simpler than you think.
The three layers of a website
Think of ordering food at a restaurant like Shah Ghouse:
| Layer | Restaurant | Website |
|---|---|---|
| Frontend | The menu and the table | What you see in the browser: HTML, CSS, JavaScript |
| Backend | The kitchen | The server code that does the work (Python, PHP, Node.js, Java) |
| Database | The store room | Where data is kept: users, orders, messages (MySQL, PostgreSQL, MongoDB) |
You (the browser) can only talk to the waiter. You never walk into the kitchen. But a clever customer might try to give the waiter a strange order that confuses the kitchen. That's how many web attacks work.
Requests and responses
Every click sends an HTTP request to the server, and the server sends back a response.
POST /login HTTP/1.1
Host: portal.college.edu
Content-Type: application/x-www-form-urlencoded
roll=21CS045&password=MySecretThe server checks the database and answers:
HTTP/1.1 302 Found
Set-Cookie: session=8f2c9a1e77b4; HttpOnly; Secure
Location: /dashboardMethods you'll see: GET (fetch a page), POST (send data, like a login form). Status codes: 200 OK, 301/302 redirect, 403 forbidden, 404 not found, 500 server error.
Cookies and sessions: how a site remembers you
HTTP itself forgets you after every request. So after you log in, the server gives your browser a session cookie, like a token at a coat counter. With every next request, your browser shows that token, and the server knows it's you.
If an attacker steals your session cookie, they can become you without your password, even bypassing 2FA. That's why the HttpOnly and Secure flags matter, and why you should log out on shared computers.
On a cyber café computer you log into your email and just close the tab. What's the risk?
Closing a tab often doesn't end the session. Always click Log out on shared computers, and use incognito mode.
The golden rule of web security
Never trust what comes from the user. Everything the browser sends (form fields, URLs, cookies, hidden fields) can be changed by the user. Look at this:
https://shop.example.in/order?id=1045What if someone changes it to id=1046? If the site shows another customer's order, that's a serious flaw called IDOR (Insecure Direct Object Reference). The backend should check: "Does order 1046 belong to this logged-in user?"
A website checks the price only in JavaScript in the browser, then sends price=499 to the server. What's the problem?
Checks in the browser are for convenience only. The server must check everything, including prices, permissions and IDs.
Tools professionals use
- Browser Developer Tools (press F12): see requests, cookies and page code. Free, built into Chrome.
- Burp Suite (Community Edition is free): sits between your browser and websites so testers can see and modify requests.
- Practise only on legal training sites such as PortSwigger Web Security Academy (free), OWASP Juice Shop and TryHackMe.
Which part of a website must enforce security checks?
Frontend checks can always be bypassed. Real protection is in the backend.
Your task (15 min)
Open any website (for example wikipedia.org), press F12 (on a laptop) and go to the Network tab. Reload the page and click the first request: look at the method, status code and headers. Then open the Application → Cookies section and see which cookies the site set. You've just looked inside HTTP like a web tester.
Lesson 13 complete!
You understand the frontend, backend and database, HTTP requests and responses, cookies and sessions, and where trust goes wrong. Next: the OWASP Top 10.
Next: The OWASP Top 10 →