OWASP API Security - Excessive Data Exposure

• OWASP
• Excessive Data Exposure

If you’re even remotely into web security, you’ve definitely heard of the OWASP Top 10. Think of it as the hall of fame for the worst security disasters haunting web applications. But here’s the catch—APIs got their own horror show, and that’s where the OWASP API Security Top 10 steps in. This bad boy lays out the biggest threats lurking in API-driven systems, like:

• Broken Object Level Authorization
• Broken User Authentication
• Excessive Data Exposure
• Lack of Resources & Rate Limiting
• Broken Function Level Authorization
• Mass Assignment
• Security Misconfiguration
• Injection
• Improper Asset Management
• Insufficient Logging & Monitoring

Some of these threats aren’t exclusive to APIs, but trust me, they hit different when APIs are involved. Today, we’re shining the spotlight on OWASP API #3, Excessive Data Exposure—a sneaky little menace that devs often overlook, but for attackers? It’s a freaking goldmine.

OWASP API Security #3 - Excessive Data Exposure

Excessive Data Exposure is what happens when an API spills way more tea than it should, handing out sensitive info like it’s a clearance sale. I see this slip-up all the time when bug hunting, and honestly, not enough devs take it seriously. Let’s break it down—how it happens, how I spot it, and how you can lock it down before it turns into a disaster.

Imagine this: a web app pings an API for user data, and the API fires back a response. That response gets displayed in the user’s browser. Simple, right?

user <----------------- application -------------------> API service
         (browser)                (API client)

Here’s the problem—most API clients don’t get to cherry-pick which data fields they receive. Let’s say an app calls an API for user profile info:

https://api.example.com/v1.1/users/show?user_id=12

And instead of keeping it minimal, the API straight-up dumps the entire user object:

{
  "id": 6253282,
  "username": "z0rs",
  "screen_name": "Eno",
  "location": "Blk 335 Smith Street",
  "bio": "Hacker.",
  "api_token": "8a48c14b04d94d81ca484e8f32daf6dc",
  "phone_number": "123-456-7890",
  "address": "Blk 335 Smith Street, SG"
}

See the issue? This API is serving up sensitive data (API token, phone number, address) like it’s on an all-you-can-eat buffet. Devs assume that since the frontend doesn’t show those fields, it’s all good. But nah—if that full API response hits the browser, it’s open season. Anyone with basic dev tools or an interception tool can snatch that data straight out of the response.

And if an attacker gets spicy with MITM (Man-in-the-Middle) attacks, they can lift sensitive data from other users too. That’s nightmare fuel right there.

How to Stop Your API from Snitching

So, how do you keep your API from spilling secrets like a messy gossip column? Here’s what you gotta do:

1. Frontend Filters Are Cute, But Don’t Rely on Them – Sure, the client app should only display what’s needed, but don’t think for a second that this makes you safe. Attackers don’t play by UI rules.

2. Trim the Fat on the Backend – The API server should only return what’s absolutely necessary. If you’re working with GraphQL, use precise queries to keep responses tight. Less data sent = less risk.

3. Encrypt Everything – Lock down sensitive data with proper encryption (think HTTPS/TLS). That way, even if someone sniffs your traffic, all they get is a bunch of useless gibberish.

Bug Hunting 101: Catching Excessive Data Exposure

When I’m on the hunt, I’m always on the lookout for anything that screams “sensitive info.” Keywords like key, token, and secret in API responses? Huge red flags. Most of the time, these leaks happen because APIs lazily dump entire objects instead of scrubbing out private data.

Excessive Data Exposure is everywhere. And if you mix it with OWASP API #4 (Lack of Resources & Rate Limiting), you’re looking at a full-scale disaster. Attackers can automate scraping of exposed data, turning a simple oversight into a catastrophic breach. Not exactly a flex.

So yeah, don’t sleep on this. Audit your API responses, lock down your sensitive fields, and keep your data exposure to a bare minimum. Because once it’s out there, there’s no hitting undo.