Autorizzazione e permessi: fondamenti delle migliori pratiche

Autenticazione è sapere "chi sei". Autorizzazione è sapere "cosa puoi fare".

Molti sviluppatori confondono le due cose. Hai effettuato l'accesso al sistema (Autenticazione ok), ma puoi eliminare il database? O vedere lo stipendio dell'amministratore delegato? Questa è l'autorizzazione.

La gestione delle autorizzazioni è la parte più critica della sicurezza di un'applicazione. Un difetto qui (Broken Access Control) è la vulnerabilità numero 1 nella classifica OWASP.

In questo articolo tratteremo le nozioni di base e le migliori pratiche per implementare un solido sistema di autorizzazioni.

Modelli di controllo degli accessi

Esistono diversi modi per dire "sì" o "no" a un utente.

1. RBAC (controllo degli accessi basato sui ruoli)

Il più comune. Crei "Ruoli".

Amministratore: puoi fare qualsiasi cosa.
Editor: può creare e modificare post.
Lettore: Puoi semplicemente leggere. Assegnate il ruolo all'utente (user.role = 'editor'). Il codice controlla: if (user.role == 'admin').
Pro: Semplice da comprendere e implementare.
Contro: È rigido. Cosa succede se voglio che un editor specifico possa eliminare i post, ma solo i suoi?

2. ABAC (controllo dell'accesso basato sugli attributi)

Più granulare e potente. Si basa sugli attributi.

"Consenti modifica IF (user.id == post.author_id) AND (ora < 18:00)".
Pro: Flessibilità infinita.
Contro: complessità di implementazione.

3. PBAC (controllo degli accessi basato su policy)

Definisce le politiche in linguaggio naturale o codice separato.

Esempio: policy AWS IAM.

Principio del privilegio minimo

Questa è la regola d'oro: Concedere all'utente solo il permesso minimo necessario per svolgere il proprio lavoro. Né più né meno.

Se un servizio deve solo leggere i dati, non concedergli il permesso di scrittura.
Se uno sviluppatore ha bisogno solo di vedere i log, non concedere l'accesso al database di produzione.

Ciò riduce la "superficie di attacco". Se l'account di quell'utente viene violato, il danno è limitato.

Dove controllare l'autorizzazione?

SEMPRE NEL BACKEND. Molte app moderne nascondono il pulsante "Elimina" sul frontend se l'utente non è un amministratore. Questa è solo UX, non sicurezza. Un utente malintenzionato può chiamare direttamente l'API DELETE /users/1. Il backend deve verificare l'autorizzazione su ogni richiesta.

IDOR (riferimenti a oggetti diretti non sicuri)

Un classico fallimento. L'URL è site.com/fatura/100. Vedo la mia fattura. Cambio l'URL in site.com/fatura/101. Vedo la fattura del vicino. Questo è IDOR. Correzione: il backend dovrebbe verificare: "L'utente che ha effettuato l'accesso è il PROPRIETARIO della fattura 101?". In caso contrario, restituisci 403 Proibito.

Conclusione

L'autorizzazione non è qualcosa che viene aggiunto alla fine. Deve essere progettato nell'architettura del database e dell'API. Utilizza librerie mature (come CASL in JS o Pundit) invece di ingombrare il tuo codice con if/else sparsi. La sicurezza è controllo.