Why do generated apps expose data even when the backend key is public by design?

Why a public backend key still exposes data

A public key is only safe when the backend enforces the right authorisation checks behind it. The key identifies the application, but it does not by itself decide which rows, records, or functions are allowed. If policy defaults are too broad, the backend will happily serve data to any request that presents the expected key, which is why “public” can still mean exposed.

The important distinction is between authentication and authorisation. A public key may be an accepted credential for the app layer, but access control has to be enforced at the data layer. In practice, that means the backend must still verify what the caller can read, write, or invoke, rather than assuming the presence of a valid public key is sufficient proof of trust.

This is why generated apps often fail in a predictable way: the frontend looks correctly wired, the key is visible by design, and the real control point is easy to overlook. The security outcome depends on whether policies, permissions, and row-level restrictions are actually configured for the data you are exposing, not on whether the key itself is secret.

Where exposure usually starts

The usual failure is not that the public key is inherently dangerous, but that it is paired with missing or permissive access rules. When a backend treats every request as effectively authorised, the application can leak records, metadata, or entire collections even though the key was meant to be non-sensitive. That is an access-control failure, not a secret-management failure.

Generated apps can make this easier to miss because they produce a working experience first and leave hardening for later. If table permissions, API policies, or tenant filters are absent, the app may appear functional in testing while quietly returning more data than intended. For background on how this pattern shows up in real compromise and secret-abuse scenarios, see The State of NHI & AI Agent Breach Report 2026, which tracks exposed API keys and stolen tokens as access paths rather than root causes.

A second failure mode is over-trusting client-side configuration. Developers sometimes assume that because the key is public, the backend must be designed to allow broad access. In reality, the public key is only one part of the trust model. The protected asset is the data itself, and the backend has to enforce the boundaries that the key is not meant to express.

What good control looks like in practice

Good design separates public connectivity from authorised data access. The application can hold a public identifier or publishable key, but the database or API should still enforce least-privilege rules, tenant scoping, and row-level restrictions. If the access policy is removed, the answer should change immediately from “data is available” to “data is denied.”

That same principle applies to lifecycle and credential hygiene when generated apps rely on machine-facing credentials or certificates. For identity material that must stay valid over time, lifecycle discipline matters because exposure often comes from stale, reused, or over-broad access paths. Machine Identity, PKI and Certificate Lifecycle Guide is useful background when the trust model depends on more than a single application key.

For teams building on platform APIs, the practical test is simple: remove or weaken the backend policy and see whether the application still returns data. If it does, the security boundary is in the wrong place. The key may be public by design, but the authorisation model is still supposed to be private by enforcement.

Practitioner Guidance

What to verify: Confirm that every data path used by the generated app is covered by server-side authorisation, not just by frontend logic or a public key. If the backend can return tenant data, user records, or sensitive objects without policy evaluation, treat that as a control defect.

Decision rule: If the key is public and the data is sensitive, the deciding factor is whether the backend enforces row, object, or function-level restrictions for each request. If the answer is unclear, assume exposure until you can prove the policy is active and correctly scoped.

What to measure: Look for requests that succeed across unauthorised tenants, return more rows than expected, or bypass expected filters. Those are the strongest signals that the issue is not key secrecy but missing or ineffective authorisation.

Practitioner takeaway: Public keys are acceptable only when the backend still enforces the real trust boundary. If access control is weak, the application is effectively publishing data and relying on obscurity to hide the mistake.

Related resources from NHI Mgmt Group

• What breaks when generated apps rely on public backend keys without row-level security?
• Why do privileged cloud permissions create risk even when they do not expose data directly?
• Why do AI data services create extra risk when they expose credentials or backend access?
• How should teams secure Shiny apps that expose internal data?