Authorization and permissions: best practices that prevent unauthorized access

Most people confuse authentication with authorization, and this confusion is costly. Authentication is proving who you are, login, password, token, biometrics. Authorizing is deciding what you, already identified, have the right to do. These are different problems, and the second is where most internal leaks and fraud live.

It is common to see systems with flawless login and lax authorization. The front door has a biometric lock, but once inside, anyone can open any drawer. The attacker does not need to break your authentication if, after logging in with a regular account, he can access data he shouldn't.

This text brings together the essential steps and best authorization practices. The objective is practical: to ensure that each user, system or service accesses exactly what it needs, no more, no less.

The principle that underpins it all: least privilege

If you only take one idea from this text, take this: give each user the minimum access necessary to do their job, and nothing more. It is the principle of least privilege, and it solves, in practice, most authorization problems.

The opposite temptation is strong. It's easier to give broad access "so as not to stop anyone" and deal with the consequences later. But each additional permission is one more door. When an account is compromised, the damage is proportional to what that account could do. Accounts with too much power turn a small incident into a catastrophe.

Lesser privilege is not distrust of people. It's recognizing that accounts are compromised, mistakes happen and the damage must be contained by design.

Step 1: Model roles before distributing permissions

Distributing permission user by user does not scale and becomes a mess in a short time. Mature practice is to organize access by roles, the model known as RBAC (role-based access control).

Instead of saying "John can see financial reports", you define the "financial analyst" role with a set of permissions, and assign that role to John. When John leaves and Mary joins, you just swap who occupies the role. Permissions are described in one place, auditable and consistent.

For more complex scenarios, there is attribute-based control (ABAC), where the decision considers context, time, location, data sensitivity. But start simple. Well-done RBAC solves the overwhelming majority of cases, and premature complexity here only generates error.

Step 2: Centralize the authorization decision

A common architectural mistake is to scatter permission rules throughout the code, an "if" here, a check there. Over time, no one knows for sure who can do what, and the rules differ between parts of the system.

Good practice is to treat authorization as a central responsibility, with a clear point where decisions are made. It doesn't matter if it's a library, a service or a module, the important thing is that the question "can this user do this?" be answered consistently, in a place that can be audited and changed.

This also makes life easier when it comes to proving compliance. When an auditor, or the LGPD itself, in the case of personal data, asks who has access to what, you can answer by looking in one place, not searching through the entire code.

Step 3: never trust just what the customer says

Here is one of the most dangerous and common faults. The frontend hides a button that the user shouldn't see, and the team considers the problem resolved. It is not. Hiding the button is experience, not security.

Authorization needs to be checked in the backend, on every request, every time. An attacker doesn't use your interface, he calls the API directly. If the only barrier is visual, there is no barrier. The rule is simple and non-negotiable: the client can suggest, the server decides.

The same goes for identifiers. If the system lets the user access a resource just by changing the number in the URL, without checking whether that resource belongs to them, you have one of the most exploited vulnerabilities in existence, improper access to an object by direct reference, cataloged for years by OWASP. Check possession, not just existence.

Step 4: Make access revocable and auditable

Access granted must be able to be taken away, and quickly. When someone leaves the organization, changes roles, or has their account compromised, you need to cut off access immediately, not in the next sprint.

This assumes two things. First, knowing who has access to what, which goes back to the point of centralizing and role modeling. Second, record who accessed what and when. Access logging doesn't prevent the problem, but it is what allows you to investigate, respond, and learn after an incident. A system without an audit trail is a system that does not know what happened to it.

Critical reflection: the silent accumulation of privileges

There is a problem that grows without anyone noticing: the accumulation of permissions over time. The person changes areas, gains new access and keeps the old ones. Years later, she accumulates permissions from three roles she once held. Nobody reviewed it, because reviewing is work and doesn't give you a trophy.

This accumulation is a time bomb. When one of these accounts is compromised, access is disproportionate. Defense is uncomfortable but necessary: periodic review of access. Look from time to time and ask “does this person still need this?” Almost always the answer, for some permissions, is no.

The other challenge is cultural. Restrictive authorization generates friction, and friction generates complaints. The user wants broad access, the manager wants agility, and security becomes the villain that stops everyone. Sustaining the least privilege requires leadership conviction, and the clarity that today's friction is cheaper than tomorrow's leak.

What remains

Authorization done well is invisible when it works and devastating when it fails. It doesn't appear in a product demonstration, it doesn't impress in a meeting, and yet it is one of the most consequential decisions of any system that deals with sensitive data.

The steps are clear: least privilege as a principle, roles instead of loose permissions, centralized decision-making, server-side verification, and revocable and auditable access. None of them are sophisticated. All are often ignored.

If your organization handles sensitive data and you're not sure who can access what, now is a good time to review. On the blog there are other texts about security, access control and compliance that delve deeper into the topic.