Roles and permissions in a SaaS before the code

Access control decides what each user is allowed to do after signing in. Signing in says who the user is. Access control says what they can see, change or delete. These are two different jobs, and the second needs its own design.

OWASP, the open community for application security, puts Broken Access Control in first place in its Top 10 list of 2021. Compared with the previous list, it moved up from fifth place to first. This shows how often applications send users where they should not go.

A role is a name for a group of permissions. NIST describes RBAC (role-based access control) as a model where users are assigned to roles, and each role has one or more permissions. Administrators define which actions each job needs and put people in the matching role.

NIST notes that without roles, administrators often set up access lists for each user, which is costly and prone to mistakes. With roles, management follows the structure of the organisation. When an employee changes position, they change role, not dozens of separate settings.

The permissions table is written with one row per action and one column per role. We make it at the requirements stage, together with the people who will use the system. Each cell answers yes or no.

The above is an example, not a ready recipe. In every project the roles differ. The value of the table is that you reach agreement before anything is built, and that the code and the tests follow exactly what was approved.

We follow three rules from the OWASP Authorization Cheat Sheet. The first is least privilege: the user gets only what they need for their job. The second is deny by default, meaning whatever has not been explicitly allowed is forbidden. The third is a check on every request.

The third rule has a practical consequence. OWASP stresses that the check is done at the server and not only in the browser, because the browser is controlled by the user. A button hidden from the screen protects nothing if the server accepts the request. For the same reason, a check missing in a single place can expose a whole resource.

The role is not always enough. In the table above, the customer can edit requests, but only their own. That is a rule about the record and not about the role. The OWASP Top 10 lists it as a prevention: access models must enforce record ownership, so that a user cannot read, change or delete the records of others.

The OWASP Cheat Sheet itself recommends, for applications, models that look at attributes or relationships (ABAC, ReBAC), because roles struggle when the decision depends on the record itself. That is why we start from roles, which are easy to explain to the whole team, and add ownership rules where the table asks for it. In a platform with many customers there is one more level, the separation of data per tenant, described in the article on customer data in a SaaS.

It is checked with automated tests that are written before the code. OWASP recommends tests for the permission logic, which confirm that access is denied by default and that the rules are applied. It adds that automated tests do not replace a manual security review.

In our own work, the test is written first for each function, and for each feature that handles data a test for the wrong user is written too: what the system answers to another role, to a visitor who is not signed in, to a user of another customer. For the method, see the article test first, then code. A team of agents also reviews the finished project, as we explain in the case study on quality and security agents.