Issue 10082
Il login non basta
Essere autenticati non significa poter eseguire ogni azione: l’autorizzazione deve considerare soggetto, risorsa e contesto.
· 5 min
Obiettivo
Distinguere identità autenticata e autorizzazione applicativa, e individuare quale componente decide e fa rispettare il permesso di un soggetto a eseguire un'azione su una specifica risorsa.
Dopo il login inizia la vera decisione
L’autenticazione verifica l’identità dichiarata; l’autorizzazione decide se quel soggetto può eseguire una determinata azione su una specifica risorsa, in quel contesto. In review, non considerare conclusa la discussione dicendo «abbiamo il Single Sign-On» o «la funzione è riservata ai manager». Per ogni operazione sensibile, descrivi soggetto, azione, risorsa e condizioni. Poi identifica i fatti necessari, le relative fonti autorevoli, il componente che prende la decisione e il punto server che la applica. Se un fatto indispensabile non è verificabile, l’operazione deve fermarsi con un errore controllato. Nascondere un pulsante può migliorare l’esperienza, ma non sostituisce il controllo server su una richiesta diretta.
Un rimborso oltre il ruolo generale
Immagina un’operatrice del customer service autenticata tramite Single Sign-On. Può disporre rimborsi fino a 500 euro, ma soltanto per gli ordini della società italiana. Una richiesta da 120 euro per un ordine francese deve essere negata: identità, ruolo e importo sono validi, ma la risorsa è fuori dal suo perimetro. Considera poi un ordine italiano con 200 euro incassati e 150 già rimborsati. L’operatrice è autorizzata, ma può essere restituito al massimo il residuo di 50 euro. Il limite personale è una condizione di autorizzazione; non rimborsare più dell’incassato è invece un’invariante del dominioGlossarioDominioLa parte del mondo reale, del business o dell’organizzazione che un sistema deve supportare.Apri la voce completa. Il percorso server del comandoGlossarioComandoUna richiesta rivolta a uno specifico owner perché tenti di eseguire un’azione.Apri la voce completa deve verificare entrambe prima di avviare il rimborso, proteggendo il residuo anche da richieste concorrenti.
Più contesto, più responsabilità da rendere esplicite
Controllare soltanto il ruolo è semplice ed economico, ma non rappresenta perimetri societari, singole risorse o condizioni operative. Aggiungere questi elementi rende la decisione più precisa e verificabile, al costo di mantenere dati affidabili, gestire indisponibilità e creare testGlossarioTestUna verifica deliberata che produce evidenze su una specifica aspettativa o rischio.Apri la voce completa negativi mirati. Un gateway può applicare controlli generali, ma spesso non conosce la società dell’ordine o il residuo rimborsabile. Spostare tutta la logica al gateway riduce la duplicazione apparente, ma rischia di separare la decisione dai fatti di dominio. Tenere il controllo nel percorso applicativo del rimborso migliora la coerenza, purché ogni ingresso che può eseguire il comando attraversi quel punto. Non serve introdurre subito un motore di policy o separare servizi: decisione e applicazione sono responsabilità distinguibili anche nello stesso monolite.
Una scheda operativa per la prossima review
Scegli un solo comando sensibile e compila una scheda con: soggetto, azione, risorsa, condizioni di autorizzazione, invarianti di dominio, fatti necessari e loro fonti, componente che decide, punto server che applica l’esito e comportamento in caso di dati mancanti. Trasforma poi ogni condizione in evidenza. Per il rimborso, prova il caso consentito e cambia una variabile alla volta: società errata, permesso assente, limite personale superato, residuo insufficiente o fonte dei permessi indisponibile. Ripeti le prove anche con richieste dirette all’API, senza passare dall’interfaccia: a parità di identità verificata e condizioni, i casi autorizzati devono restare consentiti e quelli non autorizzati devono essere bloccati. Una chiamata diretta non è, da sola, una ragione di diniego. Per ogni diniego verifica che nessun rimborso venga avviato. La scheda è utile quando un altro team sa dire quale fatto cambia la decisione, chi lo fornisce e quale test dimostra il blocco.
Per approfondire
Fonti OWASP per approfondire autorizzazione per richiesta e per oggetto, collocazione dei controlli e vincoli della logica applicativa. • Authorization Cheat Sheet — OWASP — https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html • API1:2023 Broken Object Level Authorization — OWASP — https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ • Microservices Security Cheat Sheet — OWASP — https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html • Business Logic Security Cheat Sheet — OWASP — https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html
Tag