Autorización y permisos: fundamentos de mejores prácticas

Autenticación es saber "quién eres". Autorización es saber "lo que puedes hacer".

Muchos desarrolladores confunden los dos. Ha iniciado sesión en el sistema (Autenticación correcta), pero ¿puede eliminar la base de datos? ¿O ver el salario del director ejecutivo? Esta es la Autorización.

La gestión de permisos es la parte más crítica de la seguridad de una aplicación. Un defecto aquí (Control de acceso roto) es la vulnerabilidad número 1 en el ranking OWASP.

En este artículo, cubriremos los conceptos básicos y las mejores prácticas para implementar un sistema de permisos sólido.

Modelos de control de acceso

Hay varias formas de decir "sí" o "no" a un usuario.

1. RBAC (control de acceso basado en roles)

El más común. Creas "Roles".

Administrador: Puedes hacer cualquier cosa.
Editor: Puede crear y editar publicaciones.
Lector: Puedes simplemente leer. El rol lo asignas al usuario (user.role = 'editor'). El código marca: if (user.role == 'admin').
Pros: Fácil de entender e implementar.
Contras: Es rígido. ¿Qué pasa si quiero que un editor específico pueda eliminar publicaciones, pero solo las suyas?

2. ABAC (Control de acceso basado en atributos)

Más granular y potente. Se basa en atributos.

"Permitir editar IF (user.id == post.author_id) AND (hora < 18:00)".
Pros: Flexibilidad infinita.
Contras: Complejidad de implementación.

3. PBAC (Control de acceso basado en políticas)

Define políticas en lenguaje natural o código separado.

Ejemplo: Políticas de AWS IAM.

Principio de privilegio mínimo

Esta es la regla de oro: ** Otorgue al usuario solo el permiso mínimo necesario para realizar su trabajo. Ni más ni menos.**

Si un servicio sólo necesita leer datos, no le dé permiso de escritura.
Si un desarrollador solo necesita ver los registros, no le dé acceso a la base de datos de producción.

Esto reduce la "superficie de ataque". Si la cuenta de ese usuario es pirateada, el daño es limitado.

¿Dónde verificar la autorización?

SIEMPRE EN EL BACKEND. Muchas aplicaciones modernas ocultan el botón "Eliminar" en la interfaz si el usuario no es administrador. Esto es solo UX, no seguridad. Un atacante puede llamar a la API DELETE /users/1 directamente. El backend debe verificar el permiso en cada solicitud.

IDOR (referencias directas a objetos inseguros)

Un fracaso clásico. La URL es site.com/fatura/100. Veo mi factura. Cambio la URL a site.com/fatura/101. Veo la factura del vecino. Este es IDOR. Corrección: El backend debe verificar: "¿El usuario que inició sesión es el PROPIETARIO de la factura 101?". Si no, devuelva 403 Prohibido.

Conclusión

La autorización no es algo que se añade al final. Debe estar diseñado en la arquitectura de la base de datos y la API. Utilice bibliotecas maduras (como CASL en JS o Pundit) en lugar de saturar su código con if/else dispersos. La seguridad es control.