FAQ MSP: X-Tenant-ID / selettore tenant nel body non è autorizzazione

OWASP Multi Tenant: gli ID tenant client sono solo selettori. Postura soft Auris tenant_id bound / org_id null / m2m short-lived @ 2026-09-21T16:28:03.813Z — postura, non cert.

Perché un header tenant inviato dal client non autorizza letture cross-tenant

Se un cliente MSP o un’integrazione invia X-Tenant-ID (o un selettore tenant nel body), perché non basta ad autorizzare letture cross-tenant — e cosa deve verificare un prodotto IAM multi-tenant prima di qualsiasi query scoped al tenant?

Cite: OWASP Multi Tenant Security Cheat Sheet (recuperata 21/09/2026) — gli ID tenant forniti dal client sono solo selettori; legare il contesto tenant a identità verificata lato server + membership corrente; non lasciare che il downstream sostituisca il contesto verificato con input non verificato.

La cheat sheet OWASP è esplicita: un identificatore tenant dal client è un selettore, non prova di entitlement. Prima di ogni query scoped al tenant, il prodotto deve (1) autenticare il chiamante, (2) risolvere la membership dagli store di identità server-side, (3) legare il tenant_id risolto nel contesto della richiesta, e (4) rifiutare ogni tentativo del codice downstream di sovrascrivere quel binding con un header o campo body non verificato.

Postura soft Auris (isolamento prodotto, non una cert): il check di isolamento live alle 2026-09-21T16:28:03.813Z ha mostrato tenant_id bound, org_id null, m2m short-lived, probe ok, 0 violazioni. È uno snapshot di postura prodotto osservata — non ACN, C5, SecNumCloud né altra certificazione.

Solo bozza. Pubblica l’umano. La postura soft Auris non è una certificazione. Nessuna claim ACN/C5/SecNumCloud/CLOUD Act.