// docs / baas security / auth0 hardening

Checklist di sicurezza Auth0: 22 elementi

Auth0 è una piattaforma identity-as-a-service con un'enorme superficie — applications, API (resource server), tenant, action, rule (legacy), connection e grant. Una configurazione errata di una qualsiasi è un bypass di auth. Questa checklist è un audit di 22 elementi attraverso applications, allowlist callback / logout, token e rotazione refresh, action personalizzate, RBAC, rilevazione anomalie e monitoraggio continuo. Ogni elemento è verificabile nella dashboard Auth0 in meno di 10 minuti.

Per la checklist equivalente su Clerk, vedi Checklist di sicurezza Clerk. Per il contesto sul perché le configurazioni errate a livello di identità sono punti ciechi degli strumenti IA, vedi Perché gli strumenti di codifica IA lasciano lacune di sicurezza.

Tipo di applicazione e tipi di grant

Il tipo di applicazione e i tipi di grant abilitati sono le impostazioni di massimo impatto in Auth0. Sbagliarle apre classi di attacco che nessuna quantità di codice frontend chiuderà.

Usa Application Type = Single Page Application per app solo-browser e Regular Web Application per app server-rendered. Il tipo sbagliato permette i grant sbagliati — p. es., una Regular Web App con il grant SPA abilita il flow Implicit senza PKCE, che fa trapelare i token via frammenti URL.
Disabilita il tipo di grant Implicit su ogni application. Dashboard → Application → Advanced Settings → Grant Types → deseleziona Implicit. Il flow Implicit restituisce token in frammenti URL, dove vengono loggati nella cronologia del browser e nell'analytics. Usa Authorization Code con PKCE invece.
Disabilita il grant Password a meno che tu non abbia un'esigenza documentata. Il grant Resource Owner Password Credentials (ROPC) richiede che tu gestisca tu stesso le password degli utenti — sconfiggendo la maggior parte di ciò per cui hai comprato Auth0. Disabilitalo a meno che tu non stia integrando un sistema legacy.
Abilita Authorization Code con PKCE su ogni client pubblico. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = abilitato. PKCE è richiesto per app mobile e SPA per prevenire l'intercettazione del codice.

Allowlist di URL callback e logout

I redirect aperti sul percorso callback OAuth sono una primitiva di furto token. L'allowlist di Auth0 è la tua unica difesa.

Imposta Allowed Callback URLs sul tuo esatto percorso callback di produzione — niente wildcard. https://yourapp.com/callback, non https://yourapp.com/*. I callback wildcard permettono agli attaccanti di reindirizzare i token a sottopercorsi arbitrari del tuo dominio.
Imposta Allowed Logout URLs su una lista finita. Stessa regola: solo URL esplicite. Un redirect logout aperto permette agli attaccanti di creare pagine di phishing che assomigliano al tuo stato post-logout.
Imposta Allowed Web Origins solo sulla tua origine di produzione. Usato per autenticazione silenziosa (rinnovo token via iframe nascosto). Un'origine wildcard permette alle pagine attaccanti di eseguire auth silenziosa contro il tuo tenant.
Imposta Allowed CORS origins per gli endpoint API, non per l'application. Tenant Settings → Advanced → Allowed CORS origins. Default è vuoto (limitato); aggiungi solo origini esplicite che controlli.

Token e rotazione refresh

La durata del token, la rotazione refresh e l'algoritmo di firma decidono il raggio di esplosione di qualsiasi leak di token.

Abilita Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Ogni refresh emette un nuovo refresh token e invalida quello vecchio. Combinato con scadenza assoluta, questo contiene il furto di token.
Imposta Refresh Token Reuse Interval a 0 (o quanto basso permetta la tua tolleranza di replay). L'intervallo di riuso permette a un token di essere usato due volte nella stessa finestra — spegnilo a meno che tu non abbia una ragione specifica per tenerlo.
Imposta Absolute Refresh Token Expiry a 14-30 giorni, non infinito. Application → Refresh Token Expiration → Absolute Expiration. Auth0 di default usa solo Inactivity, il che significa che una sessione inattiva può persistere per anni.
Imposta JWT Signature Algorithm a RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 usa firma asimmetrica così il client non può falsificare token. Non usare mai HS256 per applicazioni client-facing.
Verifica i claim aud e iss su ogni JWT che la tua API riceve. Usa l'SDK Auth0 ufficiale lato server — li verifica automaticamente. Il parsing JWT fatto a mano salta solitamente la validazione dell'audience, che è un bypass di auth.

Action e codice personalizzato

Le Auth0 Action (e le legacy Rule) girano lato server al login e altri eventi del ciclo di vita. Hanno accesso all'intero contesto della richiesta. Codice insicuro qui è una vulnerabilità tenant-wide.

Non loggare mai event.user o event.transaction come oggetto intero. Contengono indirizzi email, indirizzi IP e altre PII. Usa solo logging a livello di campo, e logga solo ciò che ti serve.
Usa lo store dei segreti per qualsiasi chiave API o URL webhook. Actions → Edit → Secrets. Non mettere mai inline una chiave API come literal stringa nel codice action — il codice è visibile a chiunque abbia accesso editor Actions sul tenant.
Valida gli input prima di persisterli come user_metadata o app_metadata. Un'action self-service che scrive event.body.name in user.user_metadata.display_name è un vettore di XSS memorizzato se il tuo frontend renderizza quel campo senza escape.

RBAC e resource server

Se usi Auth0 RBAC, il mapping ruolo-a-permesso è il tuo strato di autorizzazione. Sbaglialo e qualsiasi utente autenticato può colpire endpoint admin.

Definisci Resource Server (API) esplicitamente nella dashboard Auth0, non al volo. Ogni API ha un identificatore (l<code>audience</code>), scope e impostazioni di firma. Senza unAPI registrata, tutti i token vengono emessi per l'implicita "Auth0 Management API" — audience sbagliata.
Configura Permessi per API e richiedili nel tuo codice con il claim scope. Non controllare l'appartenenza al ruolo nella logica della tua applicazione; controlla gli scope nell'access token. Gli scope sono il meccanismo di autorizzazione OAuth-native.
Testa che un utente autenticato senza il ruolo / scope richiesto non possa colpire endpoint privilegiati. Accedi come utente normale, prova a chiamare POST /api/admin/users/delete. La risposta deve essere 403.

Rilevazione anomalie e log tenant

Auth0 emette eventi ad alto segnale. Configurali per allertare il tuo team, non per stare solo in un buffer di log.

Abilita Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Ciascuno è spento di default sui piani gratuiti; accendili tutti per la produzione.
Streama i log tenant a un SIEM o ai tuoi log applicativi. Dashboard → Monitoring → Streams. Auth0 conserva i log per 30 giorni sulla maggior parte dei piani; la conservazione a lungo termine richiede uno stream nel tuo sistema.
Allerta sui picchi di fcoa (auth cross-origin fallita) e fp (login fallito). Una raffica di questi in una finestra breve è credential stuffing. Instrada al tuo canale on-call.

Prossimi passi

Esegui una scansione FixVibe contro la tua URL di produzione — il check baas.clerk-auth0 segnala client secret Auth0 nel bundle JavaScript e altre classi di esposizione di provider di identità. Per l'equivalente su Clerk, vedi Checklist di sicurezza Clerk. Per la panoramica sui provider BaaS, leggi Scanner di configurazioni errate BaaS.