What breaks when generated apps rely on public backend keys without row-level security?

Why This Matters for Security Teams

Public backend keys are often misunderstood as the primary risk, when the real failure is the missing authorisation boundary. If a generated app can call backend APIs directly and the database does not enforce row-level security, then the client becomes a convenient front end for unrestricted data access. That shifts trust from the server to the browser, which is rarely defensible in production. NIST’s control baseline for access enforcement and system integrity in NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reminder that enforcement must exist where the data is actually processed.

The practical risk is not limited to read exposure. If the same key can reach write paths, an attacker can tamper with records, poison workflows, or delete operational data while appearing to use normal application traffic. This is especially dangerous in low-code and AI-generated applications, where teams may assume the platform has already inserted secure defaults. In practice, many security teams encounter this only after data exposure has already occurred, rather than through intentional access design.

How It Works in Practice

Row-level security changes the database from a shared table store into a policy-enforced access layer. Instead of relying on the client to request only its own records, the database checks every query against the authenticated identity, tenant, or session context. Public keys may still exist, but they are treated as low-risk identifiers, not secrets that confer privilege. The security boundary is the combination of authentication, session claims, and server-side policy enforcement.

In generated apps, the danger usually appears in three places: unrestricted table access, overly broad service roles, and missing policy constraints on inserts or updates. A secure design should ensure that each request is evaluated against the caller’s identity and scoped permissions before any row is returned or modified. That typically means:

• Enforcing row-level security at the database layer, not only in application logic.
• Separating anonymous client access from privileged service accounts.
• Binding session claims to tenant, user, or object ownership rules.
• Testing both read and write paths, including bulk queries and edge-case filters.
• Logging policy failures so unsafe access attempts are visible in monitoring and review.

For identity-centric implementations, this is where application design intersects with privileged access discipline. The backend should treat the client as untrusted, even if the app was generated by an internal tool or AI workflow. That aligns with zero trust thinking and with control families in the NIST Cybersecurity Framework, where access enforcement is a control objective rather than an assumed property. These controls tend to break down when a shared service account bypasses user context because every request then inherits the same broad privilege.

Common Variations and Edge Cases

Tighter row-level enforcement often increases implementation overhead, requiring organisations to balance developer speed against stronger data segregation. That tradeoff becomes more visible in multi-tenant SaaS, internal admin tools, and prototype apps that later become production systems. Best practice is evolving, but current guidance suggests treating public keys as exposure-tolerant identifiers only when database policy is provably in place.

Some teams rely on API gateways, application filters, or frontend checks and assume those controls are sufficient. They are not. Those measures can improve usability and reduce noise, but they do not replace enforcement at the data layer. Likewise, a visible backend key may be acceptable in architectures designed for public access, but only when the backend is constrained to unauthenticated, non-sensitive operations with strict server-side validation. For sensitive data, the safer pattern is authenticated access with database-backed policy checks and explicit tenant separation.

This issue also overlaps with identity governance when generated apps use service principals, non-human identities, or delegated automation to reach backend resources. In those cases, access reviews should confirm that the identity used by the app has only the minimum privileges required, and that any privileged bypass is isolated and monitored. The CISA Secure by Design guidance reinforces the operational expectation that secure defaults should reduce, not shift, responsibility onto end users or frontend code. The pattern fails most often in fast-moving environments where a prototype is promoted without revisiting the database policy model, because the original trust assumptions no longer match production use.

Related resources from NHI Mgmt Group

• What breaks when AI-generated mobile apps are shipped without security review?
• What breaks when row-level security is bypassed by a privileged agent?
• What breaks when AI-generated code is reviewed without security gates?
• What breaks when REST APIs rely on authentication without object-level authorisation?