Sensitive data shipped to the browser: config, internal fields, and bulk PII
Server config, internal-only fields, and large dumps of personal data sometimes get baked into the frontend. Here is why that is an access-control problem and how to fix it.
Beyond secret keys, AI-built apps sometimes ship data to the browser that should have stayed on the server: internal configuration, fields meant only for admins, or large amounts of customer PII embedded in the page or an over-broad API response.
What gets flagged
- Server config in client — internal hostnames, infra settings, or feature flags revealing how your backend is built.
- Sensitive fields in client — columns like
is_admin,password_hash, internal notes returned to every user. - Bulk PII in client — many users' emails/names rendered into the page, a sign an API returns more than the current user should see.
The fix
- Return only the fields and rows the current user is allowed to see — enforce it server-side (RLS or API checks), not in the UI.
- Keep internal config out of client bundles and public API responses.
- Shape API responses to the minimum the screen needs.
FAQ
Why is data (not a key) in my frontend a security issue?
Because anything sent to the browser is visible to the user. Internal fields, admin-only columns, or other users’ PII in the page mean your access control is being done in the UI instead of on the server.
How do I fix an API that returns too much?
Enforce row- and field-level access on the server (RLS or explicit checks) and shape responses to the minimum the current screen needs, rather than filtering in client code.
Related questions
- An outdated frontend library with a known vulnerability
- Is Shipshape legit? What it does and doesn’t do
- Supabase anon key vs service_role key: which is safe to expose?
- Is the Firebase apiKey a secret? (No — and here’s why)