Excessive Data Exposure

Description

Excessive data exposure occurs when an API returns a full data object to the client and relies on the client-side application to filter out sensitive fields before displaying them to the user. The backend serializes complete database records or internal model instances into API responses, including fields such as password hashes, internal IDs, access tokens, administrative flags, financial data, and personal information that the UI simply chooses not to render.

CWE-213 (Exposure of Sensitive Information Due to Incompatible Policies) captures the mismatch between the API's data-sharing behavior and the expected privacy policy. OWASP API Security's A03:2023 Broken Object Property Level Authorization is the canonical classification for this pattern. The vulnerability arises from a development shortcut: serializing entire ORM model objects is faster than defining explicit response schemas, so developers return full records and add filtering at the presentation layer—leaving the raw data accessible to anyone intercepting or directly calling the API.

Mobile applications are a particularly common source: the API was designed for the mobile client, which may suppress sensitive fields in the UI, but the same endpoints are accessible via a browser proxy like Burp Suite, revealing all returned fields. API versioning compounds the problem—an older API version may return more fields than a newer, hardened version.

How It Works

A mobile application displays only a user's name and profile picture, but the underlying API call returns the full user object:

GET /api/v1/users/12345 HTTP/1.1
Host: api.example.com
Authorization: Bearer <user_token>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 12345,
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "profile_picture": "https://cdn.example.com/pic.jpg",
  "password_hash": "$2b$12$KIXtfaF5...",
  "internal_score": 842,
  "is_admin": false,
  "stripe_customer_id": "cus_NxxxXXXXXXXX",
  "auth_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "phone_number": "+1-555-867-5309",
  "ssn_last4": "5309"
}

The mobile app renders only name and profile_picture, but Burp Suite captures the full JSON response including auth_token, ssn_last4, and stripe_customer_id. An attacker who intercepts or directly calls this endpoint retrieves the complete object.

In a social platform context, a listing endpoint leaks private messages:

# Attacker calls user listing endpoint and retrieves private fields
curl -H "Authorization: Bearer <valid_token>" \
  https://api.example.com/api/v1/users?limit=100 | \
  jq '.[].private_notes'

Testers routinely discover these issues by comparing the JSON response body to what is rendered in the UI, and by examining mobile app traffic with Burp Suite or mitmproxy.

Impact

• Credential exposure — Password hashes, API tokens, and OAuth credentials returned in user object responses enable account takeover.
• PII breach — Social security numbers, phone numbers, addresses, and financial data returned in excess of business need trigger regulatory obligations (GDPR, CCPA, HIPAA).
• Business logic bypass — Internal flags like is_admin, account_tier, or credit_limit returned in responses may be manipulatable if the API also accepts these fields in update requests.
• Competitive intelligence — Internal scoring, pricing, and classification data returned to standard users exposes proprietary business logic.
• Mass enumeration — Listing endpoints that expose excessive fields enable bulk harvesting of PII for all users with a single paginated request.

Detection

1. Proxy all mobile application or web application API traffic through Burp Suite and compare JSON response bodies against what the UI actually renders—identify fields that are returned but never displayed.
2. Make direct API calls to user, order, and resource endpoints using a regular user's authentication token and examine every field in the response for sensitive data.
3. Compare response schemas between different authenticated roles (standard user vs. admin) and between different API versions to identify fields exposed inconsistently.
4. Test list endpoints (GET /users, GET /orders) in addition to individual resource endpoints—list responses often return partial but still excessive data for each item.
5. Use jq to extract and enumerate all unique field names across paginated responses to identify the complete set of properties being returned.

Remediation

Define explicit response schemas. Use serializer classes or response DTOs that explicitly enumerate the fields to include. Never serialize full model objects directly:

# Django REST Framework — use explicit serializer fields
class UserPublicSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = ['id', 'name', 'profile_picture']  # Explicit allowlist only
        # Never use fields = '__all__'

Apply field-level authorization. Implement serializer logic that varies returned fields based on the requester's role and their relationship to the resource.

Adopt a data minimization principle. Return only the data the client needs for the specific operation requested. Design API responses from the consumer's perspective, not the data model's perspective.

Conduct response schema reviews. Include API response schema review as part of code review checklists and pen test scope for every new endpoint.