// docs / baas security / auth0 hardening

Auth0 biztonsági checklist: 22 pont

Az Auth0 egy identity-as-a-service platform hatalmas felülettel — alkalmazások, API-k (resource serverek), tenantok, action-ök, szabályok (legacy), connection-ök és grant-ek. Bármelyik hibás konfigurációja auth-megkerülés. Ez a checklist egy 22-pontos audit az alkalmazásokon, callback / logout allowlistokon, tokeneken és refresh-rotáción, custom action-ökön, RBAC-on, anomália-detekción és folyamatos monitorozáson keresztül. Minden pont az Auth0 Dashboardon 10 perc alatt ellenőrizhető.

A Clerk párhuzamos checklistjéért lásd Clerk biztonsági checklist. Háttérinformációért arról, hogy az identity-rétegbeli hibás konfigurációk miért MI-tool-vakfoltok, lásd Miért hagynak biztonsági réseket az MI-kódoló eszközök.

Alkalmazástípus és grant-típusok

Az alkalmazástípus és az engedélyezett grant-típusok az Auth0 legnagyobb hatású beállításai. Ezek elrontása olyan támadási osztályokat nyit meg, amelyeket semennyi frontend kód nem zár le.

Használj Application Type = Single Page Application-t csak böngésző-alkalmazásokhoz, és Regular Web Application-t szerver-renderelt alkalmazásokhoz. A rossz típus engedélyezi a rossz grant-típusokat — pl. egy Regular Web App az SPA-granttel engedélyezi a PKCE nélküli Implicit flow-t, ami URL-fragmenteken keresztül szivárogtatja a tokeneket.
Tiltsd le az Implicit grant-típust minden alkalmazáson. Dashboard → Application → Advanced Settings → Grant Types → vedd ki az Implicit-et. Az Implicit flow URL-fragmentekben adja vissza a tokeneket, ahol naplózódnak a böngésző-történetben és az analitikában. Helyette használj Authorization Code-ot PKCE-vel.
Tiltsd le a Password grant-et, hacsak nincs dokumentált szükséged. A Resource Owner Password Credentials (ROPC) grant megköveteli, hogy te magad kezeld a felhasználói jelszavakat — legyőzve a legtöbbet abból, amiért az Auth0-t megvetted. Tiltsd le, hacsak nem integrálsz legacy rendszert.
Engedélyezd az Authorization Code-ot PKCE-vel minden publikus klienseken. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = engedélyezve. A PKCE kötelező a mobil alkalmazásokhoz és SPA-khoz a kód-elfogás megakadályozásához.

Callback és logout URL-allowlistok

A nyitott redirectek az OAuth callback-útvonalon tokenlopási primitívek. Az Auth0 allowlistje az egyetlen védelmed.

Állítsd az Allowed Callback URLs-t a pontos produkciós callback-útvonalra — wildcardok nélkül. https://yourapp.com/callback, nem https://yourapp.com/*. A wildcard callbackok lehetővé teszik a támadóknak, hogy a tokeneket a doménod tetszőleges alútvonalaira irányítsák át.
Állítsd az Allowed Logout URLs-t véges listára. Ugyanaz a szabály: csak explicit URL-ek. Egy nyitott logout-redirect lehetővé teszi a támadóknak, hogy adathalász oldalakat készítsenek, amelyek a logout utáni állapotodra hasonlítanak.
Állítsd az Allowed Web Origins-t csak a produkciós origin-edre. Csendes hitelesítéshez (token-megújítás rejtett iframe-en keresztül) használt. Egy wildcard origin lehetővé teszi a támadói oldalaknak, hogy csendes auth-ot végezzenek a tenanted ellen.
Állítsd az Allowed CORS origins-t az API-végpontokhoz, ne az alkalmazáshoz. Tenant Settings → Advanced → Allowed CORS origins. Az alapértelmezett üres (korlátozott); csak explicit, általad kontrollált origin-eket adj hozzá.

Tokenek és refresh-rotáció

A token-élettartam, a refresh-rotáció és az aláíró algoritmus eldönti bármely token-szivárgás robbanási sugarát.

Engedélyezd a Refresh Token Rotation-t. Application → Refresh Token Settings → Rotation. Minden refresh új refresh tokent ad ki, és érvényteleníti a régit. Abszolút lejárattal kombinálva ez féken tartja a token-lopást.
Állítsd a Refresh Token Reuse Interval-t 0-ra (vagy olyan alacsonyra, amennyire a replay-tűrésed engedi). A reuse interval lehetővé teszi, hogy egy token kétszer is felhasználható legyen ugyanabban az ablakban — kapcsold ki, hacsak nincs konkrét okod megtartani.
Állítsd az Absolute Refresh Token Expiry-t 14-30 napra, ne végtelenre. Application → Refresh Token Expiration → Absolute Expiration. Az Auth0 alapból csak Inactivity-re áll, ami azt jelenti, hogy egy tétlen session évekig fennmaradhat.
Állítsd a JWT Signature Algorithm-ot RS256-ra. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. Az RS256 aszimmetrikus aláírást használ, így a kliens nem hamisíthat tokeneket. Soha ne használj HS256-ot kliens-felé álló alkalmazásokhoz.
Ellenőrizd az aud és iss claimeket minden JWT-n, amit az API-d fogad. Használd a hivatalos Auth0 SDK-t a szerveroldalon — automatikusan ellenőrzi ezeket. A kézzel írt JWT-elemzés általában kihagyja az audience-validációt, ami auth-megkerülés.

Action-ök és custom kód

Az Auth0 Actions (és a legacy Rules) szerveroldalon futnak bejelentkezéskor és más életciklus-eseményeknél. Hozzáférnek a teljes kérés-kontextushoz. Az itteni nem biztonságos kód tenant-szintű sebezhetőség.

Soha ne logold az event.user-t vagy az event.transaction-t mint egész objektumot. Ezek e-mail-címeket, IP-címeket és más PII-t tartalmaznak. Csak mezőszintű naplózást használj, és csak azt logold, amire szükséged van.
Használd a secrets store-t bármilyen API-kulcshoz vagy webhook URL-hez. Actions → Edit → Secrets. Soha ne ágyazz be egy API-kulcsot string-literálként az action-kódba — a kód látható bárkinek, akinek Action-szerkesztői hozzáférése van a tenantre.
Érvényesítsd a bemeneteket, mielőtt user_metadata-ként vagy app_metadata-ként megőriznéd őket. Egy self-service action, ami az event.body.name-et a user.user_metadata.display_name-be írja, stored-XSS-vektor, ha a frontended escape-elés nélkül rendereli azt a mezőt.

RBAC és resource serverek

Ha Auth0 RBAC-ot használsz, a szerep-jogosultság leképezés az autorizációs réteged. Rontsd el, és bármely hitelesített felhasználó tud admin-végpontokra ütni.

Definiálj Resource Servereket (API-kat) explicit módon az Auth0 Dashboardon, ne menet közben. Minden API-nak van azonosítója (az audience), scope-jai és aláírási beállításai. Regisztrált API nélkül minden token az implicit „Auth0 Management API"-ra kerül kiállításra — rossz audience.
Konfigurálj jogosultságokat API-nként, és követeld meg őket a kódodban a scope claimmel. Ne ellenőrizz szerep-tagságot az alkalmazás-logikádban; ellenőrizz scope-okat az access tokenben. A scope-ok az OAuth-natív autorizációs mechanizmus.
Teszteld, hogy egy hitelesített felhasználó a szükséges szerep / scope nélkül nem tud privilegizált végpontokra ütni. Jelentkezz be normál felhasználóként, próbálj POST /api/admin/users/delete-et hívni. A válasznak 403-nak kell lennie.

Anomália-detekció és tenant-logok

Az Auth0 magas jelszintű eseményeket emitál. Állítsd be őket, hogy figyelmeztessék a csapatodat, ne csak egy log-bufferben üljenek.

Engedélyezd az Attack Protection-t: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Mindegyik alapból ki van kapcsolva az ingyenes csomagokon; kapcsold be őket mind a produkcióhoz.
Streameld a tenant-logokat egy SIEM-be vagy az alkalmazás-logjaidba. Dashboard → Monitoring → Streams. Az Auth0 a legtöbb csomagon 30 napig őrzi a logokat; a hosszú távú megőrzés streamelést igényel a saját rendszeredbe.
Riasszon az fcoa (sikertelen cross-origin auth) és fp (sikertelen bejelentkezés) csúcsokra. Egy ezekből álló rövid ablakos kitörés credential stuffing. Routeold az on-call csatornádba.

Következő lépések

Futtass egy FixVibe-szkennelést az éles URL-edre — a baas.clerk-auth0 ellenőrzés jelzi a JavaScriptbe ágyazott Auth0 client secret-eket és más identity-szolgáltató kitettségi osztályokat. A Clerk ekvivalenséért lásd Clerk biztonsági checklist. A BaaS-szolgáltatókra kiterjedő átfogó áttekintésért olvasd el a BaaS hibás konfiguráció szkenner cikket.