Web Application Security Fundamentals

The core idea

A web application receives data from users that it cannot trust. Security bugs appear when that data is treated as trusted instructions or when the server forgets to check who is allowed to do what.

Injection (SQL injection)

If a query is built by joining strings, attacker-controlled text can change its meaning.

// Vulnerable
$q = "SELECT * FROM users WHERE name = '" . $_GET['name'] . "'";
// Safer: parameterised query
$stmt = $pdo->prepare('SELECT * FROM users WHERE name = ?');
$stmt->execute([$_GET['name']]);

Defence: parameterised queries / ORM, least-privilege database accounts.

Cross-site scripting (XSS)

When user content is placed into a page without encoding, a script can run in other users' browsers. Defence: output encoding for the correct context, a strict Content-Security-Policy, and avoiding unsafe DOM sinks.

Broken access control

Changing an ID in a URL (/invoice/1001 → /invoice/1002) must not reveal another user's data. Defence: check authorisation on every request on the server, never rely on hidden buttons.

Cross-site request forgery (CSRF)

A malicious site makes your browser send a state-changing request. Defence: anti-CSRF tokens and SameSite cookies.

Authentication and sessions

Use strong password hashing (for example Argon2id or bcrypt), rate-limit logins, offer MFA, regenerate session IDs after login and mark cookies Secure and HttpOnly.

Dependencies and configuration

Outdated libraries and default settings are common causes of breaches. Keep a software inventory and scan dependencies.

Learn and test safely

Read the OWASP Top 10 explained, run a local vulnerable app and try OWASP ZAP or Burp Suite. Never test sites you do not own. The secure coding fundamentals article covers fixes in more depth.