Web security: a guide to understanding the attack surface

Web security does not start with looking for a flaw. It starts with understanding what happens when someone opens a page, submits a form, or accesses an authenticated area. An application consists of people, a browser, a network, a server, data, and access rules. Every transition between these parts is a security decision.

This guide shows how to see those transitions — and why this perspective finds more problems than memorizing vulnerability names.

Start with the path of a request

When a browser makes an HTTP request, it sends a method, an address, headers, and sometimes a body containing data. The server decides how to handle it and returns a response.

A real request looks like this:

POST /api/pedidos/1042/cancelar HTTP/1.1
Host: loja.exemplo.com
Cookie: sessao=a1b2c3d4...
Content-Type: application/json

{"motivo": "desistencia"}

To study methodically, ask four questions about it:

1. Who can send this request?
2. What data goes into it, and how is it validated?
3. What authorization is needed to perform the action?
4. What appears in the response, logs, and browser?

Applying these to the request above: the cookie says who is authenticated, but nothing in it guarantees that this person owns order 1042. If the server cancels the order simply because it received a valid session, changing the number to 1043 cancels someone else’s order.

That is the entire reasoning behind the most frequent category in the OWASP Top 10 — and you reached it without memorizing a name, simply by asking who can do what.

Authentication is not authorization

Authentication answers “who is trying to get in?” Authorization answers “what can this identity do?”

Confusing the two causes many access problems. A person can be perfectly authenticated and still lack permission to see another user’s data, change a setting, or perform an administrative action.

When reviewing a feature, look for the authorization check near the sensitive action, on the server. Two warning signs:

• permission is checked only when building the screen, not when executing the action;
• the decision uses an identifier supplied by the client without checking it again.

Invisible buttons do not replace a server-side rule. The interface hides the option; the request can still be sent manually.

Understand the session’s role

After login, the application must recognize the person in subsequent requests. This usually happens through a session identifier or token. That identifier is the authenticated session: whoever holds it acts as that person.

For developers, the minimum protections are:

Changing the identifier immediately after login deserves emphasis: without this, an identifier an attacker managed to plant beforehand remains valid after the victim authenticates.

For students, observe how the application maintains state in a training environment — without reusing techniques against third-party systems.

Use the OWASP Top 10 as a map, not a blind checklist

The OWASP Top 10 brings together recurring web application risks and is an excellent study index. The current edition is 2025:

Two useful observations for beginners. First: broken access control leads the list — it is the category found by asking “who can send this request?” Second: the list is not a severity ranking for your situation. The same category has very different impacts depending on the data, architecture, and existing controls.

Choose one topic at a time. Understand which security property it affects, which development decision reduces it, and how a team would confirm the fix. The objective is learning to build and review better systems, beyond recognizing vulnerability names.

Ask architecture questions before testing

Draw a feature’s path: browser, route, service, database, and response. At each transition, ask which data is trusted, which identity is acting, which authorization is checked, and what evidence is logged.

The rule organizing all this: data that has crossed the client boundary is untrusted, regardless of interface validation. Browser validation exists for the person’s experience; server validation exists for security. They seem redundant but are not — only the second is mandatory.

Consider what entered the 2025 list: software supply chain failures now occupy third place. For developers, this means an installed dependency is part of the attack surface. Knowing what a project uses, where it comes from, and how often it is updated is no longer a secondary task.

For developers, security also appears throughout the change cycle: code review, tests, dependency updates, useful logs, and a way to deliver fixes quickly. For students, the focus is understanding controls and validating hypotheses in educational applications or ones they own.

A safe next step

Set up a local lab with a deliberately vulnerable educational application — OWASP WebGoat and Juice Shop exist specifically for this. Before you start, document the objective, isolate the network, and record what you expect to observe.

A concrete first exercise: open the browser’s developer tools, use any feature in the training application, and observe the request it generates. Then answer the first section’s four questions about it. This is the cheapest exercise available and teaches more than any list of commands.

Then compare this guide with the article about a safe lab and move on to authentication and account protection.

Study only applications you own, educational applications, or ones you have explicit authorization to test. Finding a problem in a third-party system does not authorize testing it: use the organization’s responsible disclosure channel.