Slide 14 of 28
Part 3 · Attack ScenariosSlide 14
PART 3
Attack Scenarios
Slides 14–17 · OWASP examples in plain English
Slide 14 · Scenario 1
You report a user. You get their home address.
OWASP Scenario #1 — a report function returns sensitive fields it never should.
📄 OWASP API Security Top 10 · 2023 · API3 · Scenario 1
SETUP
A dating app's "report user" feature.

A dating app lets users report inappropriate behavior. When you submit a report, the app calls an internal API endpoint to log the report and fetch details about the reported user.

The developer built the endpoint to return a summary of the reported user — but used the same full object serialization as the admin dashboard. The response includes: fullName, dateOfBirth, phone, and recentLocation.

The reporting user is supposed to see: username, report status. That's it.

The exploit: Any user can trigger the report endpoint against any other user's ID. They don't actually submit the report — they just call the endpoint and read the response. They now have the victim's full name, phone number, and recent GPS location. The attacker didn't bypass authentication. They used an intended feature that returned too much data.
Why this is especially dangerous

Dating apps attract stalkers. Combining fullName + recentLocation data for any user — on demand, via a report endpoint — is a serious physical safety risk, not just a data privacy issue.

← Back Scenario 2 →