Look for three things: frontend-recoverable secrets, public routes that reveal backend structure, and database policies that do not enforce per-user row boundaries. Read-only crawling and replay testing are useful because they show what an unauthenticated or low-privilege user can actually reach, not just what the platform claims to protect.
What access-control gaps usually show up first in low-code and vibe-coded apps?
In these apps, the earliest gaps are usually not subtle privilege escalations, but basic boundary failures: secrets that can be recovered from the client, routes that expose internal structure, and data policies that assume the platform will enforce user separation for you. Security teams should treat the app as suspect until they have tested what an unauthenticated user, a logged-in user, and a low-privilege user can actually reach.
That matters because low-code builders often hide implementation detail, which makes it easy to miss that a front end is still carrying sensitive configuration, a route is still callable directly, or a database query is still returning rows without a per-user constraint. The gap is not the UI itself, it is the mismatch between the intended business rule and the effective enforcement point.
How do frontend secrets and public routes reveal a real access-control problem?
Frontend-recoverable secrets are a strong indicator that the application trusts the browser with material it should not expose. If an API key, token, project identifier, backend URL, or feature flag can be pulled from shipped code or network calls, the next question is whether that value is only informational or whether it helps reach privileged backend operations. A secret that enables direct API access is an access-control failure, not just a confidentiality issue.
Public routes are just as revealing when they expose object IDs, admin-like functions, or internal workflow names that should not be guessable by outsiders. Even if the route itself is unauthenticated, the deeper test is whether it discloses enough structure for a caller to enumerate records, replay requests, or infer hidden permissions. That is why read-only crawling is useful: it shows the attack surface as a real user would see it, without assuming the platform’s declared protections are sufficient.
Why do row-level policies and replay testing matter so much?
Database policies are where many low-code apps fail most visibly, especially when the builder assumes the platform or generated app logic will enforce tenancy boundaries. If the policy does not bind every query to the current user, tenant, or ownership rule, then the database can return data that the front end never intended to display. In practice, the easiest check is whether the same request, replayed as another user, returns the same rows or only the rows that user should own.
Replay testing exposes the difference between “the screen hides it” and “the policy denies it.” That distinction is crucial in low-code environments because UI filters, client-side checks, and convenience abstractions often create a false sense of control. Security teams should verify that the enforcement point is server-side and that the rule survives direct API calls, modified identifiers, and repeated requests from lower-privilege accounts.
Risk and Threat Considerations
These gaps create a fast path from mild exposure to full data disclosure, because attackers do not need to break cryptography or defeat the platform if the app already leaks enough structure to enumerate routes, reuse secrets, or bypass row boundaries. The practical risk is horizontal access: one user or tenant can reach another user’s data simply by changing an identifier, calling a public endpoint, or replaying a request with a different account.
Failure mechanism: Client-visible configuration, weak route hygiene, or missing server-side row filters allows direct object access, enumeration, or unauthorized query results. Once one of those conditions exists, the rest of the app often becomes a matter of discovery rather than exploitation.
Impact: Sensitive records, operational data, and internal functions can be exposed without a clear intrusion signal, which makes the issue difficult to spot until a user reports unexpected data or a review finds cross-account access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Access-control gaps in app routes and row boundaries map directly to authorization checks. |
| V4 — API and Web Service | Public routes and replay testing focus on API exposure and backend request handling. | |
| V14 — Data Protection | Row-boundary failures can expose sensitive records even when the UI hides them. | |
| Recommendation — Test every route and data object for server-side authorization before trusting the UI. Validate direct API calls and replayed requests against the same access rules as the front end. Enforce per-user and per-tenant data access at the data layer, not only in the client. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Low-privilege testing is about whether users can exceed the access they should have. |
| IA-5 — Authenticator Management | Frontend-recoverable secrets and replayable credentials implicate secret and authenticator handling. | |
| Recommendation — Limit user and app permissions to the minimum required and verify enforcement with low-privilege tests. Protect, rotate, and restrict secrets that can be recovered from client code or exposed endpoints. | ||
| CIS Controls v8 | 5 — Account Management | Testing what a low-privilege user can reach depends on accurate account and permission management. |
| 6 — Access Control Management | The subject is about finding where access checks fail across routes, data, and accounts. | |
| Recommendation — Review accounts and permissions so each role can be tested against its true effective access. Verify that access controls are enforced consistently across the application and data path. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The core problem is whether access boundaries are enforced consistently. |
| A.8.3 — Information access restriction | Row-level leakage and route exposure are failures to restrict information access appropriately. | |
| Recommendation — Define and verify access rules so they apply across all app paths and data stores. Restrict information exposure at the system and data layer, not just in the interface. | ||
Practitioner Guidance
What to verify: Test three states separately, unauthenticated, standard user, and low-privilege user. For each state, confirm whether the app leaks secrets, reveals hidden routes, or returns rows outside the actor’s scope. If any one state can read another user’s data, treat the control as broken even if the UI appears normal.
Decision rule: If a control only exists in the front end, assume it can be bypassed. If a control exists in the database, confirm it is enforced for every query path, including direct API calls and replayed requests. If the same check depends on both, fix the server-side boundary first and use the client only as a convenience layer.
Practitioner takeaway: The fastest way to find these flaws is to test effective access, not intended design, because low-code tooling often makes the app look safer than it really is.
Related resources from NHI Mgmt Group
- How should security teams find conditional access gaps in practice?
- What do security teams get wrong about low-code apps in industrial IT?
- How should security teams control self-adopted AI apps before they become trusted access paths?
- How should security teams govern authentication in low-code web apps?