Authorization and Permissions - Best Practices Fundamentals

Authentication is knowing "who you are". Authorization is knowing "what you can do".

Many developers confuse the two. You have logged into the system (Authentication ok), but can you delete the database? Or see the CEO's salary? This is Authorization.

Managing permissions is the most critical part of an application's security. One flaw here (Broken Access Control) is the number 1 vulnerability in the OWASP ranking.

In this article, we'll cover the basics and best practices for implementing a robust permissions system.

Access Control Models

There are several ways to say "yes" or "no" to a user.

1. RBAC (Role-Based Access Control)

The most common. You create "Roles".

Admin: You can do anything.
Editor: Can create and edit posts.
Reader: You can just read. You assign the role to the user (user.role = 'editor'). The code checks: if (user.role == 'admin').
Pros: Simple to understand and implement.
Cons: It is rigid. What if I want a specific Editor to be able to delete posts, but only his own?

2. ABAC (Attribute-Based Access Control)

More granular and powerful. It is based on attributes.

"Allow edit IF (user.id == post.author_id) AND (time < 18:00)".
Pros: Infinite flexibility.
Cons: Implementation complexity.

3. PBAC (Policy-Based Access Control)

Defines policies in natural language or separate code.

Example: AWS IAM Policies.

Principle of Least Privilege

This is the golden rule: Give the user only the minimum permission necessary for them to do their job. No more, no less.

If a service only needs to read data, do not give it write permission.
If a developer only needs to see the logs, do not give access to the production database.

This reduces the "attack surface". If that user's account is hacked, the damage is limited.

Where to Check Authorization?

ALWAYS IN THE BACKEND. Many modern apps hide the "Delete" button on the frontend if the user is not an Admin. This is just UX, not security. An attacker can call API DELETE /users/1 directly. The Backend must check permission on each request.

IDOR (Insecure Direct Object References)

A classic fail. The URL is site.com/fatura/100. I see my invoice. I change the URL to site.com/fatura/101. I see the neighbor's bill. This is IDOR. Correction: The backend should check: "Is the logged in user the OWNER of invoice 101?". If not, return 403 Forbidden.

Conclusion

Authorization is not something that is added at the end. It must be designed in the architecture of the database and the API. Use mature libraries (like CASL in JS or Pundit) instead of cluttering your code with scattered if/else. Security is control.