Mappare soggetto, azione, risorsa e punto di controllo

Descrivere una singola operazione sensibile in modo verificabile

Usa questa pratica quando una review si chiude con formule generiche come «c'è il Single Sign-On» o «la pagina è riservata ai manager». Il risultato deve essere una scheda per un'operazione concreta che renda espliciti soggetto, azione, risorsa, condizioni, fonti dei fatti e punto server che applica la decisione.

Campi della scheda

1. Soggetto autenticato e identità effettivamente usata.
2. Azione richiesta.
3. Risorsa specifica su cui l'azione opera.
4. Condizioni di autorizzazione.
5. Fatti necessari e relativa fonte autorevole.
6. Componente che decide la policy.
7. Punto server che applica l'esito.
8. Invarianti di dominio distinte dalla policy di accesso.
9. Comportamento quando un fatto necessario non è verificabile.

Esempio: autorizzare un rimborso

Trasformare la scheda in evidenze

• Test positivo con tutte le condizioni soddisfatte.
• Stesso ruolo ma risorsa fuori perimetro.
• Risorsa corretta ma permesso assente.
• Importo oltre il limite personale.
• Permesso valido ma violazione dell'invariante di dominio.
• Richiesta diretta all'API senza passare dall'interfaccia.
• Fonte dei permessi indisponibile: nessun effetto collaterale deve partire.

Il valore è rendere visibili le dipendenze della decisione

La scheda non richiede microservizi o una piattaforma centralizzata di policy. Serve a identificare quali fatti cambiano la decisione, chi li possiede e dove l'esito viene realmente applicato. I controlli generali al gateway non sostituiscono automaticamente quelli specifici dell'oggetto o del dominio.

Riferimenti

Riferimenti utili: OWASP Authorization Cheat Sheet; OWASP API1:2023 Broken Object Level Authorization; OWASP Microservices Security Cheat Sheet; OWASP Business Logic Security Cheat Sheet.