Skip to content
Lesson 1 of 8

The Web Application Attack Surface

4 min read

How a Web Application Works

A web application is, in essence, a conversation between a client (the browser) and a server over the HTTP protocol. The browser sends a request and the server replies with a response. Each request includes a method (GET, POST, PUT, DELETE), a URL, a set of headers, and optionally a body with data. The response includes a status code (200, 404, 500), headers, and usually a body of HTML, JSON, or other content.

The key fact for security is that HTTP is a stateless protocol: the server remembers nothing between one request and the next. Each request is independent. This means that any information an attacker wants to manipulate travels somewhere in the request: the URL, the parameters, the headers, or the body. If your application blindly trusts any of that data, a vulnerability is born right there.

Cookies, Sessions and State

Since HTTP is stateless, applications need a mechanism to recognize a user across requests. The most common solution is session cookies. After logging in, the server generates a random session identifier, stores it, and sends it to the browser via the Set-Cookie header. On every subsequent request the browser returns that cookie, and the server uses it to recover the user's state.

A huge attack surface appears here. If the session identifier is predictable, an attacker can guess it. If it travels unencrypted, it can be intercepted. If the cookie lacks the HttpOnly, Secure, and SameSite attributes, it becomes exposed to theft through malicious JavaScript or to CSRF attacks. Understanding the session lifecycle well is the foundation for reasoning about vulnerabilities like session hijacking or session fixation, which we will cover in the authentication lesson.

The Client-Server Trust Model

One of the most important security principles is: never trust the client. Everything that happens in the browser is under the user's control. JavaScript validations, hidden form fields, prices displayed on a page, or disabled menus can be trivially modified with tools like Burp Suite or the browser DevTools.

This implies that any security control must be enforced on the server. Client-side validation is useful for user experience, but it is not a security measure. An attacker can bypass the browser entirely and send hand-crafted requests straight to the server. All authorization logic, data validation, and business rules must live in the backend, where the user cannot tamper with them.

Mapping the Attack Surface

The attack surface is the set of all points where an attacker can attempt to introduce or extract data. In a typical web application it includes every URL parameter, every form field, every HTTP header, every cookie, every API endpoint, every file that can be uploaded, and every integration with external services.

To understand an application's security posture it is essential to enumerate this surface systematically. Professionals use an intercepting proxy like Burp Suite or OWASP ZAP, which sits between the browser and the server and lets you view and modify every request and response. This reveals hidden parameters, undocumented endpoints, and data flows that are not visible from the interface. The larger the attack surface, the more care you must take to protect every input.

Defense in Depth as a Framework

No single defense is enough. The principle of defense in depth consists of applying multiple layers of security control, so that if one fails, another stops the attack. In practice this means combining input validation, output encoding, robust authentication, strict access control, secure configuration, and monitoring.

Throughout this course we will use the OWASP Top 10 as a map of the most critical risks. It is a community-maintained list that compiles the most frequent and impactful vulnerability categories in web applications. Each vulnerability we study also maps to a CWE (Common Weakness Enumeration) identifier, the standard catalog of software weaknesses. Having this mental framework clear will let you reason in a structured way about any application you need to protect.