Broken access control, auth and other web flaws

Broken access control (OWASP A01)

Access control is enforcing what an authenticated user is allowed to do. It tops the OWASP list because it fails constantly and the fixes are easy to forget on any one endpoint.

IDOR (Insecure Direct Object Reference) is the signature example: the app exposes a reference to an object (a record ID, a filename) and fails to check that this user is allowed that object.

GET /api/invoices/1001   → your invoice
GET /api/invoices/1002   → someone else's invoice, served without complaint

The attacker simply increments the ID. The fix is an authorisation check on every object access, server-side, scoped to the current user, per the complete mediation principle. Using unguessable IDs (UUIDs) reduces discovery but is not a fix; the access check is the fix. Obscurity is not access control.

Related failures: vertical privilege escalation (a normal user reaching admin functions because the admin URL isn't protected, only hidden from the menu), horizontal escalation (accessing a peer's data), and forced browsing (visiting URLs the UI never linked).

Broken authentication (OWASP A07)

Weaknesses in proving who you are:

• Credential stuffing: replaying username/password pairs leaked from other breaches; works because people reuse passwords. Defended by MFA, breached-password screening, and rate limiting.
• Brute force: guessing passwords; defended by throttling, lockouts, and (per NIST 800-63-4) length over complexity plus blocklists.
• Weak session management: predictable session IDs, IDs that don't change after login (session fixation), sessions that never expire, or IDs exposed in URLs (which leak via logs and Referer headers).
• Missing MFA: a single stolen password is enough.

Session IDs must be long, random (from a CSPRNG), rotated on privilege change, transmitted only in Secure; HttpOnly cookies, and expired on logout and after inactivity.

CSRF (Cross-Site Request Forgery)

CSRF abuses the fact (from the how-the-web-works chapter) that the browser automatically attaches cookies to requests, even ones triggered by another site. The attacker lures a logged-in victim to a malicious page that quietly fires a state-changing request to the target:

<!-- On the attacker's page; the victim's bank cookie rides along -->
<img src="https://bank.example/transfer?to=attacker&amount=1000">

The bank sees a properly authenticated request and acts on it. The attacker never sees the response (same-origin policy); they don't need to, because the side effect is the goal.

Defences:

• SameSite cookies (Lax/Strict): the modern baseline; the cookie simply isn't sent on the cross-site request.
• Anti-CSRF tokens: a random per-session/per-request token the legitimate form includes and the server verifies; the attacker's site can't read or guess it (SOP again).
• Don't use GET for state changes; require re-authentication for sensitive actions.

XSS vs CSRF (commonly confused): XSS runs the attacker's script in your session (it can read responses and do almost anything). CSRF blindly triggers a single authenticated action without reading anything. XSS is the more dangerous, and notably XSS defeats CSRF tokens: a script in the page can just read the token, which is why XSS is treated as so severe.

SSRF (Server-Side Request Forgery)

In SSRF, the attacker makes the server issue requests on their behalf. An app that fetches a URL the user supplies (a webhook, an image-from-URL feature) is the classic vector. The attacker points it at internal addresses the server can reach but they can't:

url=http://169.254.169.254/latest/meta-data/   # cloud metadata service
url=http://localhost:6379/                       # internal Redis

Cloud metadata endpoints are the classic target because they can leak credentials; SSRF was central to the 2019 Capital One breach. Defences: allowlist permitted destinations, block requests to internal/link-local ranges, and disable unneeded URL schemes. SSRF's promotion to its own concern reflects how much it matters in cloud environments.

File upload and other flaws

• Unrestricted file upload: uploading a script (e.g. a web shell) that the server then executes. Validate type by content not extension, store outside the web root, and never execute uploaded files.
• Insecure deserialisation (OWASP A08): feeding crafted serialized objects that execute code or tamper with logic when the app reconstructs them.
• Open redirect: a redirect that trusts a user-supplied URL, used to make phishing links look legitimate.
• Security misconfiguration (A02): verbose errors, directory listing, default credentials, missing security headers.

Security headers worth knowing

A compact set of response headers that harden a site:

Header	Protects against
Strict-Transport-Security (HSTS)	Protocol downgrade / SSL stripping: forces HTTPS
Content-Security-Policy	XSS: restricts which scripts can run
X-Content-Type-Options: nosniff	MIME-sniffing attacks
X-Frame-Options / CSP frame-ancestors	Clickjacking: stops the site being framed

Quick recall

• Broken access control (A01): IDOR = changing an ID to reach another's object. Fix = per-object server-side authorisation (complete mediation); UUIDs are not a fix.
• Broken auth (A07): credential stuffing, brute force, weak/fixated sessions. Fix with MFA, throttling, strong random session IDs in Secure/HttpOnly cookies.
• CSRF rides the browser's automatic cookies to trigger one authenticated action; defend with SameSite cookies and anti-CSRF tokens. XSS is stronger and defeats CSRF tokens.
• SSRF makes the server fetch attacker-chosen internal URLs (cloud metadata is the prize); allowlist destinations, block internal ranges.
• Validate uploads by content and store outside web root; know HSTS, CSP, nosniff, X-Frame-Options.