On this page
What a permission actually is
A permission is a yes-or-no answer to a very narrow question, asked about one account and one thing. Not "is Maria trustworthy", but "may this account read this invoice". The system asks it every single time. It does not remember being told once that Maria seems fine.
Most tools break permissions into four actions:
- See — may this account read the record at all
- Create — may it add a new one
- Change — may it edit an existing one
- Delete — may it remove one
Those four cover most of what goes wrong. A client who may see their own invoices probably should not be able to edit them. A staff member who may add a new job probably should not be able to delete last year's.
The important part is where the answer lives. A permission is a rule stored with the data and checked by the thing that holds the data. It is not a note in your handover document, not an agreement made on a kick-off call, and not the layout of a screen.
What a role actually is
A role is a bundle of permissions with a name on it. Instead of setting dozens of switches for every person, you set them once for "Client", once for "Staff", once for "Admin", and then you give people a role.
Two reasons this matters. Consistency: when a new staff member joins, they get the same rules as the last one, and nobody has to remember what was ticked back in March. And review: a client can read three role definitions and tell you whether they are right. Nobody can review four hundred individual switches.
Roles go wrong in predictable ways:
- The god role. One "Admin" that can do everything, handed out to anyone who complains about being blocked. Within a month, everyone is an admin.
- Temporary access that never ends. Someone needed one report, once. They still have the role.
- Roles named after job titles. "Manager" tells you about the org chart. "Can see every job at their own branch" tells you about the data. Name roles after what they may touch and a wrong assignment becomes obvious to everyone.
Hiding something is not preventing it
Every app you build has two layers. The interface, which is what a person sees on a screen. And the data, which is what the system will actually hand over when something asks for it.
Hiding a button changes the first layer only. It removes the invitation. It does not remove the ability.
Think of a door with a sign on it. Take the sign down and people stop noticing the door. The door is not locked. Anyone who already knows it is there, or who leans on it by accident, still walks through.
And people find the door constantly, without trying:
- An old bookmark, saved before you rearranged the menu
- A link in an email, forwarded to a colleague who has since left
- The browser back button, landing on a page they no longer should have
- The address bar
None of that is hacking. It is an ordinary Tuesday.
The rule to remember: the interface decides what is easy, and the data layer decides what is possible. Security lives in the second one. If the only thing stopping someone is that they cannot see the option, nothing is stopping them.
Row-level access, in plain terms
Picture a filing cabinet in a shared office.
The cabinet is a table: all the invoices, or all the patients, or all the job applications. Each folder inside it is a row, meaning one invoice, one patient, one application. Each line written inside a folder is a column: the amount, the date, the salary.
Access works at all three levels, and beginners usually only think about the first:
- Cabinet level — may this person open the cabinet at all
- Folder level — which folders inside it are theirs
- Line level — which lines inside a folder they may read
Row-level access is the folder level, and it is where client portals live or die. The wrong approach is to let everybody into the cabinet and then trust the app to show each person only their own folder. That is a filter on somebody's eyes. The right approach is that the cabinet itself hands over folders with that person's name on them and nothing else. Ask for folder 1043 and you are told there is no such folder.
Column rules sit on top. A staff member may need to open a personnel folder without reading the salary line: same folder, different lines. Tools like Softr Database let you set these rules on the data itself, which is exactly where you want them. Getting the underlying structure right first is what makes access rules writable at all, which is a large part of what an AI business app actually is.
The URL problem, and why it is a catastrophe
Here is the scene. You have built a client portal for an accountancy firm. A client logs in and opens their own invoice. The address bar ends in something like "/invoice/1042". They notice the number. They change it to 1043. Another company's invoice loads.
Nobody attacked anything. A curious person typed a different number, the way you would try the next page of a document.
This is not a bug in the ordinary sense, and it is worth being precise about why:
- It is not one wrong screen. Every record in that table is now reachable by every logged-in account. The problem is the size of the whole table.
- You cannot prove it has not already happened. Unless every view was logged, nobody can tell the client whether anyone looked.
- The damage is not yours to repair. Your client made promises to their own customers about who sees their data, and you broke those promises on their behalf.
A bug is something a client waits for you to fix. This is something a client may have to tell other people about. That is a different category of event, and it is the one that ends working relationships. More on where your duty starts and stops in client data, and what you are responsible for.
Be honest about the limits here. This guide helps you find the obvious holes, which is far more checking than a portal often gets. It does not make you a security professional, and it is not legal advice about your obligations. If a client handles medical records, payroll or anything comparable, say so out loud and agree with them in writing who is checking the work.
Why somebody should try to break in first
Every portal gets tested eventually. The only question is by whom. Somebody logs in with an ordinary account, changes a number in the address bar, and reaches a record that account had no business reaching. Do that to your own build first, or ask somebody else to do it, while there is still time to fix what it turns up.
It feels adversarial, and it is meant to. It is the closest thing to what happens after a real handover. Someone will change a number in a URL, or open a stale bookmark, or stay logged in as the wrong account. Better that the someone is you on a quiet Tuesday than your client's largest customer on a Monday morning.
Being strict about this is worth the effort for a plain reason. Work that AI can already do on its own, such as data entry, rewriting, copy-pasting between systems and formatting, sits in the $4–7 an hour band. Deciding who is allowed to see what has never been on that list, and it is one of the reasons the work is built as a system rather than a stack of prompts. That distinction is covered in from prompts to systems. Each foundation course ends in a quiz scored automatically against a fixed answer key; each specialisation ends in a live assessment call with a person, billed separately at ₱1,000, and none is open to book yet. The detail is on the exam section of the Academy page.
Your pre-handover checklist
Work through this before you show a client anything. One rule beats all the others: do not test as yourself. Your own account is an admin account, an admin sees everything by design, and it will tell you nothing. Create one real test account per role and log in as each of them in a private window, side by side with your own session.
- Swap a record ID. Copy an ID out of one account's URL, log in as another account, paste it in. Repeat for every screen that shows one record at a time. This is the most valuable test on the list.
- Try admin pages directly. Open the direct link to an admin or settings page while logged in as a client. Blocked, or merely missing from the menu?
- Test signed out. Paste a record link into a browser with no session at all. You should get a login screen, not the record.
- Check exports. A CSV export often ignores the filter the on-screen list respects. Export as a limited user and count the rows.
- Check search. Search for something belonging to another account. Results that appear and then refuse to open are still a leak, because they confirm the record exists.
- Check hidden form fields. Many forms carry a field saying which client a record belongs to. If a user can change it, they can write into somebody else's data.
- Check automations. Automations usually run with elevated rights. Follow every email, notification and generated document and confirm nobody receives a line they are not entitled to.
- Check file links. Uploads and images often sit on addresses that bypass the app's rules entirely. Open one in a signed-out browser.
- Remove a user, then try again. Deactivate a test account and retry its old links and old login. Removed from a list is not the same as revoked.
- Write the rules on one page. Plain sentences: "A client sees their own invoices and nothing else." Have the client read it and say yes. An access mistake is often a misunderstanding rather than a technical failure.
Anything you cannot make safe, say so in writing before handover rather than after.