Before you can secure or test web applications, you need to understand how they actually work. Every web application is built on a client-server model: a client (usually a browser) sends requests to a server, and the server sends back responses. This simple exchange powers everything from a personal blog to a global banking platform.
In this lesson, we'll trace the full journey of a web request — from the moment you type a URL into your browser to the moment a fully rendered page appears on your screen. Understanding this flow is the single most important foundation for everything else in this course.
The web operates on a client-server architecture. The client is typically a web browser (Chrome, Firefox, Edge), but it can also be a mobile app, a command-line tool like cURL, or any software that speaks HTTP. The server is a powerful computer — often running software like Apache, Nginx, or IIS — that listens for incoming requests and responds with resources.
💡 As a security professional, you'll interact with both sides of this model. You'll use browser DevTools to inspect client-side behavior and tools like Burp Suite to intercept and manipulate requests between client and server.
A URL (Uniform Resource Locator) is the address you type into your browser. Every URL has distinct parts, and understanding them is critical for security testing. Let's break one down:
https://www.example.com:443/api/users?id=42#profile
|______| |_____________|___|________|______|______|
scheme host port path query fragment| Component | Example | Purpose |
|---|---|---|
| Scheme | https:// | Protocol to use (HTTP or HTTPS) |
| Host | www.example.com | Domain name or IP of the server |
| Port | :443 | Network port (default 443 for HTTPS, 80 for HTTP) |
| Path | /api/users | Resource location on the server |
| Query | ?id=42 | Parameters sent to the server |
| Fragment | #profile | Client-side only — never sent to server |
⚠️ The URL fragment (after #) is NEVER sent to the server. This is a common misconception. If you're testing for injection vulnerabilities, the fragment is processed only by the client's browser.
Before your browser can connect to a server, it needs to translate the human-readable domain name (like www.example.com) into an IP address (like 93.184.216.34). This translation is handled by the Domain Name System (DNS). Think of DNS as the phone book of the internet.
The DNS resolution process involves several steps: the browser checks its cache, then the OS cache, then queries a recursive resolver (usually provided by your ISP), which in turn queries root servers, TLD servers, and finally the authoritative name server for the domain.
Here's the complete sequence when you type a URL and press Enter:
This entire process typically happens in under a second. As a security tester, you can intercept and modify the request at step 5 using a proxy tool like Burp Suite or OWASP ZAP — this is the foundation of web application penetration testing.
Web servers deliver two broad categories of content. Static content — like images, CSS files, and pre-written HTML — is served directly from the file system without modification. Dynamic content — like a user's dashboard or search results — is generated on-the-fly by server-side code (PHP, Python, Node.js, etc.) often with data pulled from a database.
From a security perspective, dynamic content is where most vulnerabilities live. Any point where user input influences server-side logic is a potential attack surface.
Verify exercises to earn ★ 100 XP and unlock next lab level.