Web Application Security Basics

Web application security is the discipline of understanding how web apps are attacked and building them so the attacks fail. This guide is the complete on-ramp: the browser and HTTP foundations, the attacker’s method, the three vulnerability classes behind most breaches, and the defensive baseline every application should ship with.

How the web actually works (the security view)#

Every web security concept reduces to one architectural fact: the server can never trust the client. The browser is attacker-controlled territory — anyone can send any request, with any headers, in any order, using tools no fancier than curl.

Requests are forgeable, all of them#

The interface your users see is a convenience, not a boundary. Client-side validation, hidden form fields, disabled buttons, JavaScript checks — all of it is advice that an attacker’s HTTP client politely ignores. Security decisions happen server-side or they do not happen.

The browser enforces the boundaries that exist#

What real boundaries the web has live in the browser: the same-origin policy isolating sites from each other, cookie scoping, and the opt-in mechanisms (CORS, CSP) that manage exceptions. Learn these rules first; every attack in this guide is an attempt to work around one of them.

How attackers read your application#

Attackers do not “hack servers” in the movie sense. They enumerate inputs — every place data crosses from their control into your code — and ask one question per input: what does the application do with this?

1. Map the attack surface: URLs, parameters, headers, cookies, file uploads, APIs, webhooks.
2. Find where each input is interpreted: by the database, the HTML renderer, the shell, the template engine.
3. Test whether data can break out of its role and become instructions.

That is the entire method. It is also, run against your own systems with authorization, the core of penetration testing as a profession.

The three vulnerability classes that matter most#

Decades of breach data keep converging on the same short list. Master these three mechanisms and most of the OWASP Top 10 becomes variations on a theme.

Injection: data becomes code#

The database variant is SQL injection; the browser variant is cross-site scripting. Identical disease: untrusted input reaches an interpreter with its metacharacters intact. Identical cure: keep data on a separate channel — parameterized queries for SQL, context-aware output encoding for HTML.

Broken authentication and session management#

Passwords stored weakly, sessions that never expire, tokens in URLs, missing rate limits on login. The defense is mostly not building it yourself: proven frameworks, phishing-resistant multi-factor authentication, and boring, standard session handling.

Broken access control#

The application authenticates you, then forgets to check authorization: user 4711 requests /invoices/4712 and gets it. Access control failures are the number-one category in the current OWASP Top 10, and they are logic bugs — no scanner reliably finds them. Every endpoint needs an explicit answer to “who may call this, for which objects?”

The defensive baseline you should ship#

A defensible v1, in order of leverage:

1. Parameterized queries everywhere — audit every raw-query escape hatch.
2. Framework auto-escaping left ON; every innerHTML-class sink code-reviewed.
3. Explicit authorization check on every endpoint, tested with a second, less-privileged account.
4. The core HTTP security headers, with CSP in report-only until quiet.
5. Dependencies updated on a schedule, with a lockfile and an audit tool in CI.
6. Logs that can answer “what did this session do?” — you will want them exactly once, badly.

Where to practice, legally#

Deliberately vulnerable applications exist to be attacked: local labs you run in a container, and hosted academies with guided exercises. Build the habit early: you attack what you own or what grants written permission, nothing else. The complete map of legal practice targets, certifications, and the path to paid work lives in the Careers & Practice hub.

Where to go next#

Work through this cluster article by article — the Web Security hub sequences them from beginner to advanced. When a term stops you, the glossary defines it in under eighty words, with a stable anchor you can cite.