Authentication and authorization in AI-generated apps: why login is not enough

An AI-generated app can have a perfect login and still remain vulnerable. The user logs in via Google, GitHub, email/password, Auth0, Supabase Auth, or Firebase Authentication; the session is created; the dashboard shows only the expected buttons. But all of this proves only one thing: the app knows who the user is. It does not prove what that user can read, modify, delete, export, or administer.

The risk arises when AI-generated code confuses authentication with authorization. Authentication answers the question “who are you?”, while authorization answers the question “what can you do on this object, in this tenant, with this role, in this workflow state?”. In web apps, SaaS, and internal tools created quickly with AI, this second part is often the most fragile.

The decisive check before go-live is simple to describe but difficult to improvise: an authenticated user must only be able to access the data, files, functions, reports, orders, projects, workspaces, and actions that truly belong to them. If changing an ID in a request is enough to obtain someone else’s data, the login is not protecting the product.

AuthN and AuthZ: the distinction that decides security

AuthN (authentication) means identifying the user; AuthZ (authorization) means applying permissions. Many AI-generated projects implement the first part well because providers and frameworks make it fast: social login, magic links, sessions, refresh tokens, basic middleware. The second part, however, requires domain knowledge: roles, ownership, tenants, states, permitted actions, and boundaries between customers.

AI can generate a dashboard that shows only the current user’s records, but this is not enough if the actual query accepts a user_id from the client. It can hide the “delete” button from standard users, but this is not enough if the DELETE /api/users/123 endpoint does not verify the role on the server. It can create a separate admin page, but this is not enough if the route is reachable with any session.

The basic rule is that authorization must reside in the backend, in policies and server-side checks, not just in the UI. Every request that reads or modifies data must verify identity, role, ownership, tenant, and object state.

BOLA and IDOR in AI-generated apps

Broken Object Level Authorization (BOLA) is one of the most common problems in modern APIs: an authenticated user manipulates an identifier and gains access to an object that does not belong to them. IDOR (Insecure Direct Object Reference) describes the same problem from the perspective of the exposed and modifiable identifier.

Typical examples are URLs and bodies containing user_id, account_id, tenant_id, organization_id, project_id, document_id, order_id, invoice_id, ticket_id, message_id, or workspace_id. If the API uses that ID without verifying that it belongs to the user or the tenant, an authenticated attacker can read or modify others’ data.

AI-generated apps are particularly exposed to this risk because the code tends to follow the most direct path: take an ID from the route, perform a query, return the result. It works in the demo and passes the happy-path test, but it lacks the check that binds that object to the user’s real identity.

The simplest test: changing IDs

Before going live, create two users and at least two similar sets of data. If the app is B2B, create two tenants or workspaces. Log in as the first user, intercept a request, and replace the ID with that of the second user, testing reading, updating, deleting, exporting, and downloading.

This test must be performed on the APIs, not just the UI. Use browser DevTools, proxies, curl, or API clients and test detail endpoints, lists, searches, attachments, reports, CSV exports, admin functions, invitations, payments, orders, notifications, and webhooks. The most serious vulnerabilities are often found in routes that the interface does not show directly.

The expected result is always the same: 403, a controlled 404, or a denied response. If the app returns data, updates a record, deletes a file, or produces an export, the authorization is broken.

Tenant isolation: the most underestimated B2B problem

In SaaS apps and multi-tenant internal tools, the most important boundary is not just between users, but between organizations. A user belongs to a tenant, workspace, company, team, project, or customer account, and every query must respect that boundary.

The risk arises when the code filters by user_id but forgets tenant_id, or when it accepts the tenant_id from the frontend instead of deriving it from the session or a verified membership. An export endpoint, an admin dashboard, a search function, or an aggregate query can expose cross-tenant data even if the main pages seem correct.

To test tenant isolation, create two organizations with similar data and roles, then try to read documents, orders, reports, users, files, invoices, and logs of the wrong tenant. Also test modification actions: inviting users, changing roles, deleting data, exporting reports, creating API keys, and viewing audit logs. A single forgotten endpoint can compromise the entire B2B model.

Client-side only checks: clean UI, open API

AI app builders are good at creating convincing interfaces: they show different components based on the role, hide buttons, disable fields, protect pages with route guards, and generate separate menus for admins and standard users. These checks improve the user experience, but they do not protect the app if the backend remains permissive.

A user should not be authorized because the button does not appear, but because the server rejects the action when permissions, roles, ownership, or tenants do not match. Every client-side check should be considered a convenience, not a security barrier.

The practical test consists of calling the APIs directly behind the UI: if a standard user doesn’t see “export”, try the export endpoint anyway; if they don’t see “delete”, try a DELETE request; if they don’t see the admin panel, try the route; if a field is disabled in the form, modify the request body.

Broken Function Level Authorization

BOLA concerns objects; broken function level authorization concerns functions. A user may fail to read others’ data but still succeed in performing actions reserved for a higher role: inviting users, changing roles, approving requests, issuing refunds, publishing content, deleting workspaces, generating exports, or impersonating an account.

In AI-generated apps, this happens when roles are implemented in the UI but not in the routes: the code checks that the user is logged in, but not that they are an admin, owner, billing manager, support agent, or authorized member. Or it uses a role field sent by the client instead of reading permissions from a verified token or the database.

For every sensitive function, define the minimum matrix: who can execute it, on which objects, in which state, and with what limits. Then try the action with a lower role. Admin functions must fail by default, not remain available until someone notices the problem.

Roles, permissions, and claims: where to trust and where not to

Roles and permissions can come from Auth0, Supabase, Firebase custom claims, an internal database, or corporate systems. The critical part is where they are verified: the backend must validate tokens, signatures, expiration, issuers, and audiences when using JWTs or access tokens, then translate roles and permissions into application decisions.

Do not trust role, isAdmin, user_id, tenant_id, or permissions sent in the body by the frontend. Do not trust local storage or a hidden field in a form: a user can modify requests and headers, so if a security decision depends on a value controllable by the client, that decision is fragile.

In an AI-generated app, verify where the role is calculated. If the code shows if (user.role === "admin") in the frontend, also look for the equivalent check on the server side. If it doesn’t exist, the role is protecting the interface, not the action.

Middleware and new routes generated by AI

A common problem is incomplete middleware coverage. The project has an auth middleware for some routes, but the AI adds a new API, a server action, an Edge function, a Cloud Function, or an export endpoint without hooking it into the same check, and the route works but is forgotten.

This risk increases when the agent performs multi-file refactoring or creates entire features: new pages, new handlers, new models, new endpoints, and new tests. If the authorization pattern is not centralized, every new route becomes a manual decision.

Before go-live, inventory the routes and for each one ask: does it require login? Does it require a role? Does it require ownership? Does it require a tenant? Does it accept an ID from the client? Does it return data? Does it modify state? Does it produce an export? If you cannot answer, that route must be tested.

Out-of-sequence workflows

Authorization vulnerabilities do not only concern objects and roles, but also the workflow state. An invitation can be reused, a password reset link can remain valid, an order can be modified after payment, a request can be approved twice, a refund can be called without the correct state, a document can be published before review.

AI-generated code can implement individual steps without protecting the sequence: the UI guides the user through the right flow, but the API accepts calls out of order. This is a business logic abuse problem, where the attacker does not break the login but uses legitimate functions at the wrong time.

For critical flows, verify state and permissions together: it is not enough to know that the user is the owner, you need to know if the object is in a state that allows that action. Invitations, payments, approvals, exports, publications, deletions, and role changes all deserve negative testing.

Routes that often escape review

Authorization vulnerabilities are often found in secondary routes, not on the main screen. A detail page may be protected, but the export endpoint may return more data than expected; a dashboard may filter by tenant, but a global search function may query the entire database; an upload may be linked to the user, but the download may depend only on the file path.

Carefully check autocomplete endpoints, searches, CSV exports, reports, aggregate dashboards, webhooks, callbacks, notifications, uploads, downloads, previews, batch functions, cron jobs, impersonation, invitations, password resets, billing, refunds, and role changes. These are functions often added to complete the MVP and are less tested against abuse.

AI-generated apps can create these routes as support for the main feature: the prompt asks to “add export”, “add admin dashboard”, “add user invitations”, “add document upload”. The resulting code may be functionally correct, but it does not always inherit the same policies as existing routes.

Practical examples of abuse to test

In a SaaS with workspaces, a standard user should try to read /api/workspaces/{id}/members of another workspace, export orders of a different tenant, modify a colleague’s role, regenerate an API key that isn’t theirs, or download files uploaded by another customer. If any of these cases work, the problem is not in the login: it is in the authorization model.

In an e-commerce or marketplace app, try changing order_id, seller_id, customer_id, payment_id, and refund_id. A user should not see others’ orders, modify prices, access other customers’ receipts, or call refund functions outside their role. Webhooks must also be verified: a callback must not update an order status without validating the signature, state, and ownership.

In a quickly generated internal tool, try functions that seem harmless: exports, advanced filters, search, record duplication, changing assignees, accessing comments, downloading attachments, and viewing audit logs. Internal tools often handle sensitive corporate data and have less hardening because they are not perceived as public products.

RLS and Security Rules help, but are not enough on their own

Supabase Row Level Security, Firebase Security Rules, and similar controls are important defenses and can block direct access to the database or storage when the app uses client-side SDKs. However, they do not replace application authorization logic on APIs, server-side functions, exports, aggregations, roles, and workflows.

If a server-side API uses a service key or a privileged role, it must apply authorization before executing queries or returning data. If a function produces an aggregate report, it must respect tenants and permissions. If an endpoint exports data, it must have controls at least as strong as those of the screens it displays.

The most solid model combines multiple layers: database policies where needed, centralized server-side controls, manual testing on APIs and roles, logging of sensitive actions, and code review of access control areas.

How to fix without multiplying fragile patches

When you find a BOLA or a function accessible to the wrong role, avoid fixing only the specific endpoint with a local condition. If the problem arises from a recurring pattern, you need to centralize the control: middleware, authorization helpers, shared policies, secure query builders, or service layers can reduce the risk that the next route generated by the AI repeats the same error.

Remediation should start from the model: which roles exist, which objects they protect, which tenants they separate, which actions are allowed, and which workflow states are valid. Then the code must apply that model uniformly, because if every route decides independently what “admin” or “owner” means, security depends on the individual developer’s memory or the prompt used by the agent.

For every bug fixed, add a negative test. If a user could read a document from another tenant, the test must prove that they now receive a denied response. If a low-level role could call an admin endpoint, the test must remain in the pipeline. The fix becomes reliable only when the wrong behavior cannot return without failing a check.

Negative tests that cannot be missing

AI-generated tests often cover the happy path: successful login, correct user, existing data, expected role. For authorizations, you need opposite tests, where every critical function proves that the wrong user cannot execute the action.

Prepare cases for unauthenticated users, expired tokens, insufficient roles, different tenants, another user’s objects, non-existent IDs, different HTTP methods, manipulated bodies, invalid states, already-used invitations, expired links, unauthorized exports, out-of-path uploads, and disallowed deletes.

These tests should not remain only manual: after finding a problem, turn it into a regression test. AI-generated apps change quickly, so if an agent modifies middleware or queries, a negative test must catch it.

When an independent verification is needed

An internal review may be enough for prototypes without real data, without external users, and with few routes. However, an independent verification is needed when the app is exposed online, handles real data, has different roles, uses tenants or workspaces, exposes APIs, produces exports, handles payments, uses admin functions, or stems from extensive changes generated by AI.

WAPT is particularly useful because it tests real behavior from the outside and as an authenticated user: it doesn’t just read the code, but tests manipulated IDs, hidden routes, insufficient roles, cross-tenant access, and out-of-sequence flows. Code Review is useful when you need to understand why the control is missing: unapplied middleware, wrong queries, roles read from the client, incomplete policies, duplicated logic. The two approaches are often complementary: one proves the abuse, the other identifies the cause.

How ISGroup can verify auth, roles, and APIs

ISGroup can test the authorizations of an AI-generated app starting from real behavior: users, roles, APIs, tenants, objects, admin functions, exports, uploads, and critical workflows. The goal is to prove whether an authenticated user can step out of their perimeter before go-live.

If the AI-generated app has…	Main risk	Recommended check
Web apps, APIs, logins, roles, tenants, or uploads exposed online	BOLA, IDOR, auth bypass, role abuse	Web Application Penetration Testing
Middleware, queries, controllers, server actions, or code policies	Incomplete server-side controls	Code Review
Supabase, Firebase, Auth0, RLS, Security Rules, or callbacks	Policies and configurations inconsistent with application logic	Cloud Security Assessment
Multiple AI-generated releases on auth and APIs	Repeated regressions on access control	Software Assurance Lifecycle

Do you have an AI-generated web app with logins, roles, tenants, or exposed APIs? ISGroup can verify if authenticated users can access data or functions outside their perimeter before go-live.

Evidence to prepare

Prepare environment URLs, repositories, lists of routes and APIs, roles, tenants or workspaces, auth providers, data schemas, database policies, middleware, admin functions, exports, uploads, payments, and parts generated or modified with AI.

Realistic test accounts are needed: at least two standard users, one admin, two tenants or workspaces if present, similar data between users, and objects with known IDs. For each role, indicate which actions they should be able to perform and which must be denied.

If there are uncertain areas, bring them immediately to the review: routes added by AI, duplicated controls, non-centralized middleware, unverified RLS, claims used on the frontend, exports created for demos, undocumented admin functions.

Decision before go-live

Block the go-live if:

• An authenticated user can read, modify, delete, or export data of other users or tenants.
• A low-level role can access admin functions.
• The API trusts IDs or roles sent by the client.
• A sensitive route does not verify sessions and permissions.
• A critical workflow can be executed out of sequence.

You can plan improvements that do not expose data or functions after the release: refactoring the RBAC model, documenting roles, increasing test coverage, progressive centralization of middleware. Findings on BOLA, IDOR, tenant isolation, and unauthorized admin functions must be corrected before real data and external users are involved.

Auth and authorization checklist

• List all routes that read, modify, delete, or export data.
• Associate each route with the required role, ownership, tenant, and state.
• Try manipulated IDs: user_id, tenant_id, project_id, order_id, document_id, invoice_id.
• Test different users, different tenants, missing tokens, expired tokens, and low-level roles.
• Call APIs directly, without going through the UI.
• Verify admin functions: invite, export, delete, change role, impersonate, refund, approve.
• Check that the backend does not read roles or user IDs from the client.
• Verify middleware on new routes, server actions, functions, and webhooks.
• Add negative tests for every bug found.
• Do not publish if a user can step out of their perimeter.

Frequently Asked Questions

• If I use Auth0, Supabase Auth, or Firebase Authentication, am I protected?
• No. These tools authenticate the user, but your app must still authorize access to data, objects, roles, and functions.
• How do I know if I have a BOLA?
• Log in as user A, intercept a request with an object ID, and replace it with an ID belonging to user B. If you receive data or manage to modify the object, you have a problem.
• Is hiding a button in the UI enough?
• No. The API behind that button must reject the request even if it is called directly, regardless of what the interface shows.
• Are RLS or Firebase Security Rules enough?
• They are important controls, but you must also verify server-side APIs, exports, admin functions, storage, workflows, and middleware.
• When is WAPT needed?
• When apps and APIs are exposed online or are about to be. WAPT tests roles, objects, tenants, and routes as an authenticated attacker would.
• When is Code Review needed?
• When you need to understand if server-side controls, middleware, queries, roles, and policies are implemented correctly in the code generated or modified by AI.

Useful sources and references

• OWASP API Security Top 10: https://owasp.org/www-project-api-security/
• OWASP Broken Access Control: https://owasp.org/Top10/en/A01_2021-Broken_Access_Control/
• OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
• OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html