API3:2023 — Broken Object Property Level Authorization

Slide 10 · Excessive Data Exposure

The frontend hides it. The API still sends it.

Filtering in the UI is not access control. The attacker doesn't use the UI.

How it happens

A developer builds a user profile endpoint. The database has a full user record: id, name, email, passwordHash, resetToken, isAdmin, role, internalNotes, createdAt, lastLogin, balance.

The developer serializes the whole object and returns it from the API — it's fast and simple. The frontend only displays: name, email, and bio. The developer thinks, "the sensitive fields aren't shown, so we're fine."

An attacker opens their browser's dev tools, looks at the Network tab, and reads the raw API response. They see every field.

# GET /api/users/1042 — what the attacker actually receives: { "id": 1042, "name": "Jane Smith", "email": "jane@example.com", "passwordHash": "$2b$10$N9qo8uLOickgx2ZMRZoMye...", "resetToken": "a1b2c3d4e5f6", ← active reset token "isAdmin": false, "role": "user", "internalScore": 23, "balance": 0.00, "stripeCustomerId": "cus_ABC123" ← payment processor ID }

The resetToken problem

If the API returns an active password reset token in the profile response, an attacker who can read it can immediately take over the account — without triggering a reset request themselves. No email. No notification. Silent takeover.

← Back Real incident: Peloton →