OWASP Top 10, the attacker mindset and access control

OWASP (Open Worldwide Application Security Project) is an open community that publishes free security guides. The best known of them, the OWASP Top 10, is a list of the most common and most dangerous categories of web application vulnerabilities. It is built from data on hundreds of thousands of real applications and surveys of practitioners. This course follows the 2021 edition, which is still the one most often cited in requirements and in interviews.

OWASP Top 10:2021

• A01 Broken Access Control: a user sees or changes someone else's data. This lesson.
• A02 Cryptographic Failures: unencrypted data, weak algorithms, plaintext passwords. Lesson 4.
• A03 Injection: SQL, OS commands, and also XSS, which was merged into this category in 2021. Lessons 2 and 3.
• A04 Insecure Design: the flaw is in the logic itself, not in the code. The cure is threat modeling, covered below.
• A05 Security Misconfiguration: default passwords, debug mode left on, open buckets, missing headers. Lesson 5.
• A06 Vulnerable and Outdated Components: old dependencies with known CVEs. Lesson 5.
• A07 Identification and Authentication Failures: password guessing, weak sessions, no MFA. Lesson 4.
• A08 Software and Data Integrity Failures: unverified updates, CI/CD and packages trusted blindly. Lesson 5.
• A09 Security Logging and Monitoring Failures: an attack runs for weeks and nobody notices. Lesson 4.
• A10 Server-Side Request Forgery (SSRF): the server fetches a URL supplied by the user. Lesson 5.

Course plan

The attacker mindset

A developer thinks: "how do I make this work". An attacker thinks: "what happens if I send something unexpected". Everything that comes from the client is fully under their control: the URL, parameters, request body, headers, cookies, file name, even a role field in the JSON that the form does not have. The frontend is not a defense: a browser side check is bypassed with a single curl request.

Threat modeling

Threat modeling is the habit of asking four questions before writing code: what are we building, what can go wrong, what are we going to do about it, and did we do a good job. It is enough to draw a data flow diagram (browser, API, database, third party services) and walk through every arrow. For "what can go wrong" the STRIDE acronym is handy:

Broken Access Control and IDOR

IDOR (Insecure Direct Object Reference): the server takes an identifier from the request and returns the object without checking whether it belongs to the current user. The user sees /api/invoices/1042, changes it to 1043 and reads someone else's invoice. Authentication works perfectly here: the user is real, the object just is not theirs.

Even more reliable: build the owner right into the database query. Then forgetting the check is impossible, because someone else's row simply will not be found.

Other forms of broken access

• Privilege escalation through the request body (mass assignment): PATCH /me with a field role: admin, and the server saves the whole object. Fixed with an allowlist of fields.
• Admin routes without a role check: there is no button in the UI, but DELETE /api/users/7 works for everyone.
• Trusting hidden fields: price or userId from the form instead of values from the session and the database.
• Resources open by default: a new page or endpoint without middleware is automatically available to everyone.