# Doing authorization the wrong way: Common authz anti-patterns to avoid

## Introduction

Authorization is an important process in building secure applications. It is the process of determining which users can gain access and what actions they can perform within an application.

That's where understanding common anti-patterns comes in. There are pitfalls you want to avoid when building a secure application. By recognizing and avoiding them, you can build an authorization system that stands strong against unauthorized access.

In this article, we'll look at authorization, highlighting the anti-patterns to watch out for and the best practices to keep your application secure.

For a deeper understanding of authorization and its foundational concepts, check out Cerbos's detailed article on the subject [What is Authorization?](https://www.cerbos.dev/blog/what-is-authorization)

## Implications of poor authorization

When authorization isn't done right, a system can have far-reaching consequences like data breaches and loss of customer trust affecting not only the security of your application but also your reputation and bottom line.

### Poorly secured applications

Imagine a small e-commerce company that recently launched its new online platform. They’re excited about the potential growth and the ability to serve customers 24/7. However, in the rush to go live, the team overlooked the important part of implementing a secure authorization flow. This then leads to a malicious attacker discovering a loophole in the system and somehow gaining unauthorized access to the admin panel, a section meant only for a handful of trusted employees. With this access, the attacker retrieves sensitive customer data, including addresses and payment details. The company soon faces a massive data breach.

This scenario illustrates the risks of poorly secured applications. Without solid authorization set in place, your application becomes a target for unauthorized access, leading to data breaches and system disruptions. It’s a strong warning that securing your application is not optional.

### Lack of trust

Customers that once trusted the ecommerce platform with their personal and payment information will begin to feel exposed and vulnerable. They'll start questioning the company's ability to protect their data, resulting in a flood of negative reviews and social media backlash. Trust, once built through positive shopping experiences, will now be replaced with doubt and fear.

Restoring customer trust will become an uphill battle, requiring extensive investment in cybersecurity measures, transparent communication and so much time to rebuild trust for the business.

### Financial implications

The risks involved in poor authorization are too much to be taken for granted. The financial cost can be very hefty. The legal landscape for data protection is strict, with regulations such as the General Data Protection Regulation (GDPR) imposing heavy fines for non-compliance. The breach the ecommerce store has faced can expose the company to legal scrutiny, and soon, they will be dealing with lawsuits and regulatory investigations. The penalties imposed can be very severe and draining of the companies financials.

## Common authorization anti-patterns

Even with the best intentions, authorization systems can sometimes fall prey to common mistakes that leave applications vulnerable. These anti-patterns not only compromise security but also create maintenance challenges. Below, we’ll discuss some of the most prevalent authorization anti-patterns that developers should avoid:

* Over-privileged permissions
* Hardcoding access control logic
* Inconsistent authorization logic
* Role explosion

Each of these anti-patterns can weaken your application’s security framework. Let’s get into them in detail to understand their implications and how to avoid them.

### Over-permissions

When a user is granted more permissions than required,it increases the chances of them misusing these permissions,be it accidental or malicious. For example, a gamestore website where a customer support personnel can delete user accounts instead of just viewing or modifying customer details, this is an over-privileged permission and shouldn't happen.

const permissions = ['view', 'edit', 'delete']; // Too much access! Don't do this!
if (user.role === 'support') {
    performAction(permissions);
}

Instead, lowercase 'a'dopt the principle of least privilege. This principle ensures users only have access to the resources and actions necessary for their roles, minimizing the risk of accidental or malicious misuse.

const permissions = ['view', 'edit']; // Restrict to essentials
if (user.role === 'support') {
    performAction(permissions);
}

### Hardcoding access control logic

Never hardcode authorization rules directly into your application. Such logic is difficult to maintain and requires manual updates, increasing the chance of introducing bugs.

if (user.role === 'admin') {
    // Grant access
} else {
    // Deny access
}

Instead, use centralized access control systems or frameworks like OAuth, or RBAC that separates business logic from authorization logic. For example, using a centralized RBAC service allows you to modify permissions in one place without changing code across the app. Cerbos has covered more on RBAC with the topic [RBAC in Javascript](https://www.cerbos.dev/blog/role-based-access-control-in-javascript ) you should check it out.

### Inconsistent authorization logic

Not following a consistent authorization method all through your apps can lead to exploitable gaps. For example, an API endpoint (`/getUserDetails`) might require a `user` role, while the front-end assumes it is restricted to an admin role. Attackers can bypass the front-end and directly exploit the API. To ensure consistency, implement middleware or centralized authorization policies shared across all layers.

### Role explosion

Overloading RBAC with too many small, similar roles can create unmanageable systems. For example, with the game store website, they create a separate role for each store worker instead of grouping permissions. This can lead to anincrease in complexity and make it difficult to manage. You should always use hierarchical roles.

Hierarchical roles allow you to define broader categories like 'Manager' or 'Staff' and grant permissions based on these categories, rather than creating individual roles for each worker. You can also combine RBAC with ABAC to handle complex permission requirements without excessive roles.

## Best practices for proper authorization

### Use access control tools
Always use tools and frameworks that are easy to maintain and scale for your authorization. A good example will be the use of Cerbos you can define, manage, and update fine-grained access control policies without touching your core application code.

### Monitor for authorization weaknesses
Continuously review and monitor your systems for potential authorization weaknesses by regularly conducting penetration tests to identify and patch weak authorization points. For example, you can consider using tools like OWASP ZAP or Burp Suite for regular penetration testing.

### Limiting permissions: Zero-trust
Adopt a zero-trust model where no user or system is trusted by default. The zero-trust model operates under the principle of 'never trust, always verify,' requiring strict access verification for every action.
Always verify permissions before granting access. For example, you can require re-authentication for sensitive actions like fund transfers or admin-level changes

### Conclusion

Authorization is more than a best practice, it's the cornerstone of application security. By avoiding common anti-patterns and taking steps like using access control tools, monitoring weaknesses, and adopting a Zero-Trust Model, you can build secure and trustworthy applications.

Secure your applications right, because doing authorization wrong is not an option.