Contents
Role-based access control gives each user a role (sales rep, manager, accountant, customer) that defines what they can see and change. Permissions must be enforced on the server and down to the database, not just hidden on screen. In my rate card, the accounts and roles component costs $1,700 (€1,500)excl. VAT.
In a business tool, not everyone should see everything. A sales rep has no reason to view salaries, a customer should only see their own orders, and an intern should not be able to delete an invoice. Role-based access control organizes this. Done well, it protects your data and simplifies administration. Done badly, it is the most widespread security flaw in web applications. Here is how I design it.
Why it is the top security issue
The OWASP Top 10, the reference list of web application security risks, ranks “Broken Access Control” (A01:2025) first in its 2025 edition (checked October 27, 2026). In practice, that covers situations such as:
- a user changes a number in the page address and opens another customer’s record;
- a button is hidden on screen, but its action still works when the server is called directly;
- an admin page is protected only by the fact that no link points to it.
The GDPR also requires that access to personal data be limited to the people who need it (Article 32 of Regulation (EU) 2016/679). The French data protection authority covers access management in its practice guide for the security of personal data.
Designing the role matrix
It all starts with a table, drawn up during scoping with the business managers. Roles go in rows; actions on each type of data go in columns. An illustrative example for a sales tool:
| Action | Sales rep | Team manager | Accounting | Administrator | Customer (client portal) |
|---|---|---|---|---|---|
| View customer records | Their own | Their team’s | All, read-only | All | Their own |
| Create a quote | Yes | Yes | No | Yes | No |
| Approve a discount above the threshold | No | Yes | No | Yes | No |
| Issue an invoice | No | No | Yes | Yes | No |
| View overall revenue | No | Their team | Yes | Yes | No |
| Manage users and permissions | No | No | No | Yes | No |
Three principles shape the table:
- Least privilege. Each role gets the minimum needed for the job. A permission is added when the need is shown, not “just in case.”
- Role and scope. “Team manager” is a role; “West team” is a scope. Combining the two avoids creating one role per branch.
- Separation of duties. The person who creates an exceptional discount is not the one who approves it.
Enforcing permissions in the right place
Hiding a button protects nothing. Permissions must be checked at three levels:
- the interface: only show what the user can do, for convenience;
- the server: every request checks the user’s identity and role before acting, and this is where security actually happens;
- the database: with PostgreSQL, row security policies (Row Level Security) filter data directly in the database. Once enabled on a table with no policy defined, no rows are accessible by default.
This third level is the one I use with Supabase. It acts as a safety net: even if a bug slips into the app’s code, the database refuses to return another customer’s or another team’s data.
Classic mistakes to check for
These are the points I check first when taking over or auditing an application:
- permissions checked only in the browser, common in quickly generated prototypes;
- sequential IDs in page addresses, which make it easy to guess neighboring records;
- a shared administrator account used by several people, with no audit trail;
- accounts never disabled after someone leaves;
- permissions piling up as people change jobs.
Other common flaws are covered in the most common security flaws in SMB applications.
What it costs
In my rate card, access rights are added to the app’s base price as components (amounts excl. VAT):
| Component | What it covers | Price |
|---|---|---|
| Accounts and roles | Sign-in, roles, permissions, user administration | $1,700 (€1,500)excl. VAT |
| Back office | Full administration interface | $2,300 (€2,000)excl. VAT |
| Client or partner portal | Isolated external access, everyone sees only their own data | $2,800 (€2,500)excl. VAT |
| Connection to other tools | For example, single sign-on with Microsoft 365 or Google | $2,300 (€2,000)excl. VAT |
A tool with several isolated spaces illustrates this: O’GYM brings together a member app, coach and partner spaces and an administration area, each with its own permissions. Connecting to your company directory is covered in single sign-on (SSO) with Microsoft 365 or Google.
When fine-grained permissions are not needed
I will be straightforward: for a tool used by five people who all need to see everything, two roles are enough (user and administrator). A detailed matrix adds design and administration costs with no benefit. How fine-grained the permissions are should follow how sensitive the data is and how many teams there are, not the other way around.
How I set it up
- During scoping: the role matrix, approved by the business managers, and the list of administrators.
- In the mockups: each role tests its own screens.
- During development: server-side checks and database-level policies, plus automated tests that verify one role cannot reach another’s data.
- At go-live: a log of permission changes and a periodic review procedure.
Access rights are part of every business app I build. To estimate your project, select the components you need in the estimator.
Frequently asked questions
How many roles should we plan for?
As few as possible. Four to six roles cover most business tools. Beyond that, combine a role with a scope (branch, region, customer) instead of adding more roles. A matrix that is too granular becomes impossible to administer and ends up being bypassed.
Can people sign in with their company Microsoft 365 or Google accounts?
Yes, through single sign-on (SSO). Identity comes from your directory, while permissions are still managed in the app. When an employee leaves, disabling their main account also removes their access to the tool.
Who should be able to change permissions?
A small number of named administrators. Every permission change should be logged: who granted which access, to whom, and when. It is the first thing you check after an incident.
What happens when an employee changes jobs?
Their role is changed, not added to. The classic mistake is to add new permissions without removing the old ones: after a few years, the longest-serving employees can access everything. Reviewing permissions once or twice a year prevents that drift.