Authentication, database and permissions in AI-built apps
Hiding a button does not protect data: identity and authorisation must be verified where reads and writes actually happen.
How to design authentication, database access and permissions for an AI-built app without exposing data or relying on frontend-only security checks.
Step-by-step procedure
Separate three questions: who is the person, which data may they see and which actions may they perform. Login answers only the first. The backend must decide and enforce the other two.
- 01
List roles and actions
Create a simple matrix: customer, collaborator and administrator on the rows; read, create, update and delete on the columns. Avoid implicit roles.
- 02
Assign data ownership
For every collection, define the owner, optional organisation and authorised subjects. A record without an explicit boundary is difficult to protect.
- 03
Enforce checks on the backend
Verify token, account state and permission for every sensitive operation. The browser may improve the experience, but it must not grant access.
- 04
Test permissions and lifecycle
Test both allowed and denied operations. Include email verification, password recovery, session revocation, export and account deletion.
Never send passwords, tokens, .env files or private API keys through public forms, chats or screenshots.
Authentication is not authorisation
Login identifies a person; permissions decide what they can read or change. Every sensitive operation must verify both on the backend.
What to check
- Verify tokens and account status.
- Never trust an email or user ID sent by the browser.
- Separate owner, collaborator and administrator roles.
Design data around ownership
Every record should have a clear owner or access boundary. Queries and rules must prevent one user from guessing the identifier of another user’s data.
What to check
- Deny access by default.
- Validate fields and sizes on the server.
- Test denied access explicitly.
Handle the account lifecycle
Password recovery, email verification, logout, data deletion and session revocation are not future details: they belong to the operational product.
What to check
- Provide understandable errors.
- Record security events without sensitive content.
- Document export and deletion.
How to decide the next step
The model is correct when an ordinary user can access only their own boundary, administrators receive explicit privileges and every out-of-scope request is denied even when the backend is called directly.
Do you have an app that stops at the demo stage?
Describe what works, what is missing and the outcome you need. The request is reviewed personally by Giambattista.