Web Application & API Security

01 How web apps & APIs work

Every interaction is a request from a client (browser, mobile app, script) to a server, which returns a response. HTTP is stateless — each request stands alone — so apps bolt state on top using cookies, sessions and tokens. The security of the whole thing lives in how the server trusts and handles what the client sends.

The anatomy of a request

REST vs GraphQL

Most APIs are REST — resources at URLs (/api/users/5), actions via HTTP verbs. GraphQL exposes a single endpoint where the client specifies exactly what it wants. GraphQL's flexibility is also its risk: deeply nested queries can exhaust the server, and introspection often leaks the entire schema.

02 The OWASP Top 10

The OWASP Top 10 is the reference list of the most critical web application risks, rebuilt every few years from real-world data. The 2021 edition is the current stable release — know it cold:

03 Injection & Cross-Site Scripting

Injection happens whenever untrusted input is mixed into something that gets interpreted — a database query, a shell command, an HTML page. The root cause is always the same: data and code aren't separated.

SQL injection

If a query is built by string concatenation, input becomes query logic:

the flaw vs the fix
# VULNERABLE — input is concatenated into the query
query = "SELECT * FROM users WHERE name = '" + name + "'"
# input:  name = ' OR '1'='1  →  returns every row

# SAFE — parameterised query; the driver keeps data ≠ code
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

Cross-Site Scripting (XSS)

XSS is injection into the browser: attacker-controlled input is reflected into a page and runs as JavaScript in the victim's session — stealing cookies, keylogging, or acting as them. Three flavours:

Fix: context-aware output encoding (HTML-encode on output), a strong Content-Security-Policy header, and framework auto-escaping. Never build HTML by concatenating user input.

04 Broken Access Control & SSRF

IDOR — Insecure Direct Object Reference

The textbook access-control flaw, and the #1 risk overall. The app trusts an ID in the request without checking whether you are allowed that object:

IDOR — change the number, read someone else's data
GET /api/invoices/1043   →  your invoice   ✓
GET /api/invoices/1044   →  someone else's  ← no ownership check = IDOR

The fix is server-side authorisation on every object access — "does the current user own / have rights to this specific record?" — checked on the back end, every time. Never rely on the client hiding the option.

Server-Side Request Forgery (SSRF)

SSRF tricks the server into making a request the attacker chooses. Because that request originates from inside the network, it can reach things the attacker never could directly — internal services, admin panels, and most dangerously cloud metadata endpoints:

SSRF to cloud credentials
# app fetches a user-supplied URL for a "preview" feature
POST /api/fetch   { "url": "http://169.254.169.254/latest/meta-data/" }
# → returns the cloud instance's IAM credentials. Full compromise.

05 Authentication, sessions & JWT

Two distinct problems, often confused: authentication (are you who you claim?) and authorisation (are you allowed this?). Most breaches exploit a gap in one or the other.

Session management

• Session cookies must be HttpOnly (no JS access, blunts XSS theft), Secure (HTTPS only) and SameSite (blunts CSRF).
• Session fixation — regenerate the session ID on login, or an attacker can pre-set it.
• CSRF — a logged-in victim's browser is tricked into firing a state-changing request. Defend with anti-CSRF tokens and SameSite cookies.

JSON Web Tokens (JWT)

JWTs are self-contained, signed tokens widely used for API auth — and widely misimplemented:

Defend with MFA, strong password policy + rate limiting (against credential stuffing), proper token expiry/rotation, and pinning the signing algorithm server-side. jwt_tool is the standard tester.

06 API security — why APIs break differently

APIs expose logic and data directly, usually without a browser's protections, and often with thin or missing authorisation. OWASP maintains a separate Top 10 for them because the failure modes differ from classic web apps — authorisation dominates the list.

PUT /api/users/me  { "name": "stew", "role": "admin" }
# the app blindly sets role → privilege escalation

07 Testing methodology

1. Recon — identify the tech stack, frameworks, hosts and exposed endpoints. Wappalyzer, nuclei, subdomain enumeration.
2. Map — spider the app, catalogue every parameter, form and hidden API route. Burp Suite's proxy + target map is the core tool here.
3. Test — work the OWASP classes systematically against each input: access control, injection, XSS, auth, SSRF. ffuf for fuzzing, sqlmap for SQLi.
4. Exploit — prove real impact safely; chain flaws (e.g. IDOR + mass assignment → account takeover). Never destroy data.
5. Report — evidence, reproducible steps, risk rating (CVSS), and clear remediation. The report is the deliverable, not the exploit.

08 Defence in depth