█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Cybersecurity/Application Security/OWASP A01: Broken Access Control
45 minIntermediate

OWASP A01: Broken Access Control

After this lesson, you will be able to: Recognize, find, and fix Broken Access Control (OWASP A01): the most common web vulnerability, where users reach data or actions they should not.

Broken Access Control is the number-one item on the OWASP Top 10. It happens when the app fails to enforce what an authenticated user is allowed to do, letting them read other users' data, escalate privileges, or hit admin functions directly.

Prerequisites:OWASP Top 10

What it is

Access control decides who can do what. It breaks when the server trusts the client to enforce permissions, or checks them inconsistently. The classic form is IDOR (Insecure Direct Object Reference): the URL or request body names a resource id (/orders/1003) and the server returns it without checking that it belongs to the requesting user. Change the id to 1004 and you read someone else's order. Other forms: missing function-level checks (an admin endpoint reachable by a normal user), forced browsing to authenticated pages, and trusting a hidden form field or a client-side role flag.

💡 Real-world breach

First American Financial Corporation (2019) exposed about 885 million records of mortgage documents (bank account numbers, SSNs, wire-transfer receipts) through a textbook IDOR: document URLs were sequential, and anyone with a valid link could increment the number to view any other customer's documents. No authentication was required at all. It is one of the largest access-control failures on record.

How to find it

Access control is found by testing, not scanning, because the server may respond normally; only the data is wrong.

  1. 1

    Log in as a low-privilege user and capture a request that fetches your own resource (e.g. GET /api/orders/1003) in Burp Suite.

  2. 2

    Change the id to one you do not own and resend. If you get someone else's data, that is an IDOR.

  3. 3

    Try reaching admin-only endpoints (/admin, /api/users) as a normal user.

  4. 4

    Look for permission decisions made in the client (hidden fields, disabled buttons, role flags in the response) and bypass them by calling the API directly.

  5. 5

    Test both horizontal (other users' data at the same level) and vertical (privilege escalation to admin) access.

How to fix it

Enforce ownership and role on the server for every request.

tsx
// VULNERABLE: returns the order by id with no ownership check
app.get('/api/orders/:id', requireAuth, async (req, res) => {
const order = await db.order.findUnique({ where: { id: req.params.id } });
res.json(order); // any logged-in user can read any order
});
// FIXED: scope every query to the authenticated user (deny by default)
app.get('/api/orders/:id', requireAuth, async (req, res) => {
const order = await db.order.findFirst({
where: { id: req.params.id, userId: req.user.id },
});
if (!order) return res.status(404).json({ error: 'not found' });
res.json(order);
});
// Rules: deny by default; check ownership AND role server-side on every
// request; never trust client-supplied role/permission fields.
Quick Check

Why is Broken Access Control hard to catch with an automated scanner?

Pick the best answer.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Hands-on: OWASP Top 10 in DVWA and WebGoat
Back to Application Security
OWASP A02: Cryptographic Failures and Password Hashing→