• Agents
  • Docs
  • Pricing
  • Blog
Log in
Get started

Security for apps built with AI. Paste a URL, get a report, fix what matters.

Product

  • How it works
  • What we find
  • Pricing
  • Agents
  • MCP Server
  • CLI
  • GitHub Action

Resources

  • Blog
  • Docs
  • FAQ
  • Glossary

Security

  • Supabase Security
  • Next.js Security
  • Lovable Security
  • Cursor Security
  • Bolt Security

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • Imprint
© 2026 Flowpatrol. All rights reserved.
Home/What We Find/Data Exposure
CWE-200CWE-209CWE-532OWASP #4

Data Exposure

API Over-Fetching & Information Leakage

AI-generated APIs return everything instead of what the frontend needs. Internal data, stack traces, admin fields — all sitting in the response for anyone who opens DevTools.

What is data exposure?

Data exposure happens when your API sends back more information than the client actually needs. A user profile endpoint that returns the password hash. An error response that includes the full stack trace and database connection string. A list endpoint that includes admin-only fields for every user in the system.

The frontend might only render a name and avatar — but the full response is right there in the network tab. Attackers don't need to break in when your API is already handing them the keys. This is one of the most common issues in AI-built apps because the generated code almost never filters response data.

What it looks like in code

Here's a typical AI-generated user endpoint. The frontend only shows the user's name and email — but the API sends back everything the database has.

Vulnerable — returns full database row
// GET /api/users/:id
const user = await db.query("SELECT * FROM users WHERE id = $1", [id]);
return Response.json(user.rows[0]);

// Response includes everything:
// {
//   id: 42,
//   email: "alice@example.com",
//   name: "Alice",
//   password_hash: "$2b$10$...",
//   internal_notes: "VIP customer, discount approved",
//   created_at: "2025-01-15T...",
//   is_admin: false,
//   stripe_customer_id: "cus_...",
//   reset_token: "a1b2c3..."
// }
Fixed — explicit field selection
// GET /api/users/:id
const user = await db.query(
  "SELECT id, name, email, avatar_url FROM users WHERE id = $1",
  [id]
);
return Response.json(user.rows[0]);

// Response only includes what the frontend needs:
// {
//   id: 42,
//   name: "Alice",
//   email: "alice@example.com",
//   avatar_url: "/avatars/alice.jpg"
// }

Why AI tools generate this

Data exposure is one of the most common patterns in AI-generated code. It happens for a few specific reasons:

  • Training data returns full objects. Most code examples AI learned from use SELECT * or return the entire database row. Filtering down to specific fields is an extra step the model skips.
  • Error handling defaults to verbose. AI tools generate try/catch blocks that send the full error object back to the client — stack traces, file paths, database connection strings, all of it.
  • No concept of "internal" vs "external" data. The model doesn't know which fields are sensitive. It treats password_hash the same as display_name because both are just columns in a table.

The result is APIs that work perfectly from the UI's perspective — the right data shows up on screen. But every response is a treasure trove for anyone who looks at the raw JSON.

Common patterns

Full object returns with sensitive fields

API endpoints that return entire database rows including password hashes, internal IDs, admin flags, and metadata never meant for the frontend.

Stack traces in error responses

Unhandled exceptions that send full stack traces, file paths, and dependency versions to the client — giving attackers a roadmap of your backend.

Unprotected admin/debug endpoints

Routes like /api/debug, /api/admin/users, or /api/health that expose internal state, environment variables, or full user lists without authentication.

Sensitive data in application logs

Console.log and logging middleware that dump request bodies, auth tokens, and user data to logs accessible via exposed endpoints or error pages.

How Flowpatrol detects it

Flowpatrol scans your live app and checks every API response for data that shouldn't be there. Here's how:

  1. 1Map every API endpoint. Flowpatrol crawls your app and catalogs every endpoint it can find — REST routes, GraphQL queries, server actions, and hidden paths.
  2. 2Inspect response payloads. Each response is analyzed for sensitive field patterns: password hashes, internal IDs, email addresses, tokens, and fields that don't match what the UI actually renders.
  3. 3Trigger error conditions. Flowpatrol sends malformed inputs, invalid IDs, and edge-case requests to surface verbose error messages, stack traces, and debug information.
  4. 4Flag over-fetching. When an API returns significantly more data than the frontend consumes, Flowpatrol flags it — because unused fields in a response are fields an attacker can read.

You get a clear report showing exactly which endpoints leak data, what fields are exposed, and how to fix each one.

Check your app for data leaks.

Paste your URL. Flowpatrol checks every API response for sensitive fields, stack traces, and over-fetched data. Five minutes.

Try it free