Client-Server Model: Browsers, Servers, and Databases

The Two Sides of the Web: Clients and Servers

At its heart, almost every interaction you have online follows a simple pattern: you ask for something, and something else provides it. This is the client-server model. The client is the part that does the asking—your web browser, your mobile app, or even a specialized script. The server is the part that does the providing—a powerful computer somewhere on the internet that holds the data and logic for the website or service you're using.

Let's get a formal definition for these core components.

As the video explained, the client initiates communication, and the server responds. The client doesn't need to know how the server gets the information; it just needs to know how to ask. This separation of concerns is what allows the web to function at a global scale.

The Three Key Players in Web Architecture

While we talk about "client" and "server" as two entities, in a typical web application, the "server" side is often composed of two distinct parts: the application server itself and a database. This gives us three main components to understand.

1. The Web Browser (Client): This is your gateway to the web. When you type an address like https://example.com and press Enter, your browser (like Chrome, Firefox, or Safari) is responsible for creating a formal request (an HTTP request, which we'll cover in detail later) and sending it across the internet to the correct server. When the server sends something back, the browser's job is to interpret the code (like HTML, CSS, and JavaScript) and render a visual webpage that you can interact with.

   • From a Hacker's Perspective: The client is where user-facing vulnerabilities like Cross-Site Scripting (XSS) happen. If you can make the server send malicious code to a client, the victim's browser will execute it, trusting it came from a legitimate source.

2. The Web Server (Server-Side Logic): This is the application's brain. It's a program running on a remote computer that is always on, listening for incoming requests from clients. When a request arrives, the server executes code—the "business logic"—to decide what to do. This could be anything from "fetch the latest 10 blog posts" to "verify this user's password and log them in."

   • From a Hacker's Perspective: The server is a primary target. Flaws in its logic can lead to critical vulnerabilities. For example, if the server code doesn't properly check who is making a request, you might be able to access another user's data (IDOR) or perform administrative actions (Privilege Escalation).

3. The Database (Data Store): Most web applications need to remember things: user accounts, product inventories, posts, comments, etc. This data isn't stored in the application server's code itself; it's kept in a separate, highly organized system called a database. The web server talks to the database to retrieve, create, update, or delete information as needed to fulfill a client's request.

   • From a Hacker's Perspective: The database is often the "crown jewels." It contains all the sensitive user data, financial records, and intellectual property. A successful SQL Injection attack, for example, could allow an attacker to bypass the web server's logic and communicate directly with the database, potentially dumping all of its contents.

These three components are often deployed on separate physical or virtual machines, a setup known as a three-tier architecture.

The Request-Response Lifecycle: A Complete Picture

Let's tie it all together with a simple example: logging into a website.

1. You (the user) type your username and password into a form on example.com and click "Login".
2. Your Browser (Client) packages this information into an HTTP request and sends it to the server associated with example.com.
3. The Web Server (Server) receives the request. Its application code is triggered. It sees that this is a login attempt.
4. The server's code takes the username and password you sent and sends a query to the Database. The query asks, "Does a user with this username and a matching password exist?"
5. The Database searches its records and sends a response back to the web server: "Yes, a matching record was found."
6. The Web Server receives the "Yes" from the database. It now knows the login was successful. It prepares an HTTP response containing your account dashboard page and includes a special piece of data called a session cookie to remember that you're logged in.
7. Your Browser (Client) receives this response. It renders the dashboard page for you to see and stores the session cookie for future requests to example.com.

This constant back-and-forth between client, server, and database is happening millions of times per second across the internet. As a bug bounty hunter, your job is to find weak points in this chain of communication and logic.

Conclusion

In this lesson, we've established the foundational model for all web applications. You now have a mental map of how the internet works on a technical level.

Here are the key takeaways:

• The web operates on a client-server model, where clients request information and servers provide it.
• The three core components of a modern web application are the client (usually a web browser), the web server (which runs the application logic), and the database (which stores the data).
• These components are constantly communicating in a request-response cycle to deliver the interactive experiences we use every day.
• Each component and the communication between them represents a potential attack surface that you will learn to probe and secure.

The responses that servers send back to browsers are typically documents written in a language called HTML. To find bugs, you need to be able to read and understand these documents. In our next lesson, we will begin our journey into HTML, learning how to construct a basic page. This will be our first step toward understanding how to manipulate these pages to find vulnerabilities.