API3:2023Broken Object Property Level Authorization
Slide 17 of 28
Part 3 · Attack ScenariosSlide 17
Slide 17 · The Pattern
The same missing check, every time.
Across every scenario, one question was never asked.
The Missing Question

Every one of these attacks succeeded because the API never asked: "Should the calling user be allowed to read or set this specific property?"

Not "can they access this object?" — API1 covers that. Not "are they logged in?" — API2 covers that. Specifically: this user, this property, this operation.

The Pattern in Each Scenario
Dating app — report endpoint returned fullName + location: should those fields be in this response?
Marketplace — host set total_stay_price: should hosts be able to write this field?
Social media — user set blocked=false: should users be able to write this field?
GitHub — user set user_id on a key: should users be able to write this field?
Peloton — private fields returned in profile response: should these be in this response?
The Fix Pattern
On reads: define exactly what each endpoint returns — not the whole object
On writes: define exactly what each endpoint accepts — not all fields
Use schemas, DTOs, and allowlists at the API layer
Never trust the frontend to filter sensitive fields
Treat every new model property as private by default
← Back How do we fix it? →
📄 View sources