Behind Every Website: 10 Web Security Concepts Explained

A website can look like a simple collection of text, images, and buttons. Behind the interface, however, an entire system is communicating with your browser. Servers process requests, cookies maintain state, authentication identifies users, and authorization determines what they can access. The visible website is only the surface.

For an ethical hacker, understanding this exchange is essential.

A website is not simply a page displayed in a browser. It is a collection of clients, servers, protocols, requests, responses, identities, permissions, and security controls working together. A weakness in any of these areas can affect the security of the entire application.

The Big Picture

A useful way to understand web security is to imagine a conversation between two sides.

1. Client and Server

The client is the system making a request. In web security, this is often a browser such as Chrome or Firefox, although mobile applications and other programs can also act as clients.

The server receives those requests and performs the necessary processing.

For example, when you open an online store, your browser acts as the client. The store's web server receives the request, retrieves the appropriate information, and sends a response back.

The important security distinction is that the client and server operate in different environments.

A client is generally under the user's control. A server is controlled by the organization running the application.

This means the server cannot safely assume that information coming from the client is trustworthy. A browser may normally display a button only to an administrator, but an attacker can potentially construct a request without using that interface.

2. HTTP and HTTPS

HTTP, or Hypertext Transfer Protocol, defines how web clients and servers communicate. It provides the basic structure for sending requests and receiving responses.

HTTPS is HTTP transmitted through a secure TLS connection. TLS helps protect the communication from interception and tampering while the connection is being established securely.

This distinction matters because HTTP by itself does not provide the same confidentiality and integrity protections.

HTTPS protects the connection, but it does not automatically make the application secure. A web application can still contain authentication flaws, authorization problems, injection vulnerabilities, or other weaknesses while using HTTPS correctly.

3. Request and Response

Web communication is largely built around requests and responses. A browser sends a request to a server. The server processes it and returns a response.

For example, a browser might request a user's profile page, and the server might return the corresponding HTML or application data.

This model is particularly important in ethical hacking because the browser may provide a convenient interface, but the request itself is what the server ultimately receives.

A simplified request might contain information such as the requested URL, HTTP method, headers, cookies, and sometimes data supplied by the user. The response may contain a status code, headers, cookies, and the requested content.

4. Cookies

A cookie is a small piece of information that a website can store in a user's browser. Cookies allow websites to remember information between requests. Cookies are not inherently dangerous. Their security depends on what they contain, how they are generated, and how the application uses them.

For example, a website might use a cookie to remember a user's preferences or associate the browser with a particular session.

Cookies are therefore an important part of web applications, but they also become security-sensitive when they contain or reference authentication information.

Security-related cookie attributes can help reduce risks. For example, Secure can restrict transmission to HTTPS connections, while HttpOnly can prevent ordinary JavaScript from directly reading a cookie.

5. Sessions

HTTP is fundamentally stateless. A server does not automatically remember previous requests simply because they came from the same browser. Sessions provide a way for an application to maintain a user's state across multiple requests.

After logging in, for example, the application may create a session associated with that user. Subsequent requests can contain a session identifier that allows the server to recognize the user. This makes sessions central to account security.

However, if a session identifier is stolen, exposed, or improperly managed, an attacker may be able to impersonate the associated user without knowing their password.

6. Headers

HTTP headers provide additional information about requests and responses.

They can describe the type of content being sent, provide authentication-related information, control caching, indicate security policies, and communicate other instructions between clients and servers.

For example, a response may include security-related headers that instruct a browser how certain content should be handled. Headers can therefore influence both application behavior and browser security.

From a testing perspective, they are also valuable because they reveal how an application communicates and what assumptions it makes about incoming or outgoing traffic.

7. Authentication

Authentication establishes a user's identity.

Logging in with a username and password is a common example. Other methods include authentication tokens, certificates, or multifactor authentication. The important principle is that authentication answers who the user is.

Weak authentication can allow an attacker to gain access to another user's account. Problems can occur in password handling, login mechanisms, account recovery, session management, or other parts of the identity system.

8. Authorization

Once an application knows who a user is, it must determine what that user is allowed to do. This is authorization.

A normal user might be allowed to view their own profile but not another user's private information. An administrator might have access to additional management functions. Authentication and authorization are therefore different security decisions.

An application can correctly identify a user while still incorrectly allowing that user to access something they should not. This is the foundation of broken access control, one of the most important categories of web application vulnerabilities.

9. APIs

An API, or Application Programming Interface, provides a structured way for software to communicate with another system. A web application may use APIs to retrieve account information, submit orders, update profiles, communicate with mobile applications, or connect different services.

The important point is that an API is still an application interface, even when it does not look like a traditional webpage.

10. Web Application Firewall

A Web Application Firewall, or WAF, is a security control designed to inspect and filter web traffic. A WAF sits between clients and a web application and can examine requests for patterns associated with malicious or unwanted activity.

A WAF can provide an additional layer of protection, but it should not be treated as a replacement for secure application design. For example, it may identify suspicious input that resembles an injection attack and block or flag the request.

If the underlying application contains a vulnerability, the vulnerability still exists even when a WAF blocks some attempts to exploit it.

Putting It All Together

Web security becomes much clearer when these concepts are viewed as parts of one interaction.

A user opens a browser and communicates with a server using HTTP or HTTPS. The browser sends a request, and the server returns a response. Headers provide additional instructions and information, while cookies can help maintain state.

After authentication, the application may associate the browser with a session. The server then uses that identity when making authorization decisions about what the user can access.

Behind the visible website, APIs may provide additional ways to interact with the application. A Web Application Firewall may inspect traffic before it reaches the application itself.

For an ethical hacker, this is the central idea behind web security: understand the communication, understand the identity, understand the permissions, and understand what the application trusts.

Congratulations. You made it all the way here. 😄