Web application security starts with a clear understanding of how browsers, servers, and networks communicate. Every request and response cycle is a potential attack surface, and knowing the mechanics gives you a concrete foundation for evaluating risk.
When a user types a URL into a browser, the browser performs a DNS lookup to resolve the domain name to an IP address, then opens a TCP connection to the server, typically on port 80 for HTTP or port 443 for HTTPS. A TLS handshake occurs on secure connections, establishing encrypted communication before any application data is exchanged.
The browser then sends an HTTP request. This request includes a method such as GET, POST, PUT, or DELETE, a path, headers carrying metadata like cookies and content types, and optionally a request body. The server processes this request, applies application logic, queries databases or other services, and returns an HTTP response with a status code, headers, and a body containing HTML, JSON, or other content.
Each component in this chain is a candidate for attack. DNS can be poisoned to redirect traffic. TLS can be misconfigured to allow weak ciphers. HTTP headers can leak sensitive server information. Request bodies carry user input, which is the most common entry point for injection attacks. Response bodies may include JavaScript that executes in the browser, making client-side security just as critical as server-side defenses.
Understanding the stateless nature of HTTP is equally important. HTTP itself does not remember previous requests, so web applications use mechanisms like cookies, session tokens, and local storage to maintain state between requests. These mechanisms introduce their own attack vectors, including session hijacking and cookie theft, which are explored in later modules.
Web application firewalls, load balancers, content delivery networks, and reverse proxies all sit between the client and the application server. Each of these components may process, modify, or cache requests and responses, and each introduces configuration choices that affect security posture.
Consider a regional e-commerce platform. A customer's browser sends a POST request to /checkout carrying order data in the request body. A load balancer routes that request to one of several application servers. The server reads a session cookie from the request header to identify the logged-in user, queries a database for cart contents, charges a payment processor, and returns a 200 OK response. From a security standpoint, the session cookie must be protected from theft, the request body must be validated against injection, the database query must be parameterized, and the response must not expose internal error details. Each step is a security decision point.
- HTTP requests and responses form the core communication model of web applications, and every field in them is a potential attack surface.
- TLS encrypts traffic in transit, but misconfiguration can undermine its protections.
- HTTP is stateless; cookies and session tokens maintain state, making them high-value targets.
- Intermediary components like proxies, load balancers, and CDNs all affect the security posture of a web application.
- Understanding request and response structure is the first step toward identifying where attacks can occur.