// docs / baas security / clerk hardening
Clerk security checklist፦ 20 ንጥሎች
Clerk ለapp-ዎ auth፣ session-ዎች እና organization-ዎችን ይይዛል — ይህም የተበላሸ Clerk integration auth bypass፣ session-fixation vector ወይም org-leakage path ነው ማለት ነው። ይህ checklist 20-ንጥል audit በkey-ዎች፣ session config፣ webhook-ዎች፣ organization-ዎች፣ JWT template-ዎች እና ongoing monitoring ላይ ነው። AI coding tool-ዎች Clerk-ን በምክንያታዊ default ቶሎ ያዘጋጃሉ፤ ይህ list የሚተውዋቸውን ንጥሎች ይይዛል።
Auth-layer misconfiguration-ዎች ለምን AI-tooling ድካማ ቦታ መሆናቸውን ለማወቅ AI coding tool-ዎች ለምን የደህንነት ክፍተት ይተዋሉ ይመልከቱ። በAuth0 ላይ ለሚተካከለው checklist Auth0 security checklist ይመልከቱ።
Environment key-ዎች እና origin allowlist
Clerk ለproject-ናቸው ሁለት የተለያዩ key-ዎችን ያወጣል። እነዚህን መቀላቀል ወይም ማፍሰስ የመጀመሪያው የውድቀት ሁነት ነው።
- Publishable key-ን (
pk_live_*በproduction፣pk_test_*በdev) በbrowser ይጠቀሙ፤ secret key-ን (sk_live_*/sk_test_*) በserver ብቻ ይጠቀሙ። Publishable key በNEXT_PUBLIC_CLERK_PUBLISHABLE_KEYውስጥ ደህና ነው፤ secret key public env prefix በፍጹም መሸከም የለበትም እና በclient component ውስጥ በፍጹም መታየት የለበትም። - Production app
pk_live_*ይጠቀማል፣pk_test_*አይደለም መሆኑን ያረጋግጡ። Test instance-ዎች unverified email address-ዎችን እና የተዘጋ MFA ይፈቅዳሉ — test mode ወደ production መልኩ auth bypass ነው። - በClerk Dashboard ውስጥ የተፈቀዱ origin-ዎችን ያዋቅሩ። Settings → Domains → Allowed origins production domain-ዎን በትክክል list ማድረግ አለበት። ባዶ ወይም wildcard origin list-ዎች attacker-ዎች ከbackend-ዎ ጋር የሚነጋገሩ rogue Clerk frontend-ዎችን እንዲፈጥሩ ይፈቅዳሉ።
- በማንኛውም መውጣት ወይም በተጠረጠረ leak ላይ secret key-ን ሮቴት ያድርጉ። Dashboard → API Keys → Reset። ቀደም ያለው key invalidate ይደረጋል፤ ከሮቴት በፊት server-side code-ን በአዲሱ value እንደገና ይዘርጉ።
Session configuration
Session expiry እና idle timeout የተሰረቀ session 10-ደቂቃ event ወይም 30-ቀን event የመሆኑ ልዩነት ናቸው።
- ለsensitive data ለሚይዙ SaaS app-ዎች session inactivity timeout-ን ለ30 ደቂቃ ወይም በታች ያስቀምጡ። Dashboard → Sessions → Inactivity timeout። Banking-tier app-ዎች 5-10 ደቂቃ ይጠቀማሉ፤ standard SaaS 30-60 ደቂቃ፤ consumer app-ዎች 1-7 ቀናት። ነባሪ 7 ቀናት ነው።
- በpassword change፣ email change እና MFA enrollment ላይ session revocation-ን ያስችሉ። Dashboard → Sessions → Revoke on። እነዚህ user-initiated የደህንነት event-ዎች ናቸው፤ በሌላ device ላይ ያሉ session-ዎች መገደል አለባቸው።
- Session-ዎችን በእያንዳንዱ protected route server-side ያረጋግጡ፣ በsign-in ጊዜ ብቻ አይደለም። በNext.js ውስጥ፦
const { userId } = await auth();በserver component / API route ውስጥ JWT-ን ከcookie ያነባል እና ይፈትሻል። Cookie-only check-ን በፍጹም አያምኑ። - በsession cookie ላይ
SameSite=Lax(default) ወይምStrictያስቀምጡ። በDevTools → Application → Cookies ውስጥ ያረጋግጡ።SameSite=NoneCSRF vector ነው — cross-domain auth setup በግልጽ ካላዋቀሩ በፍጹም አይጠቀሙ።
Webhook verification
Clerk webhook-ዎች በuser lifecycle event-ዎች (created፣ updated፣ deleted፣ session.ended) ላይ ይተኩሳሉ። እነዚህ ለdatabase-ዎ synchronization mechanism ናቸው — እና የተጭበረበረ webhook database-write primitive ነው።
- በእያንዳንዱ webhook ላይ Svix signature-ን ያረጋግጡ። Clerk webhook-ዎች በSvix የተፈረሙ ናቸው።
new Webhook(secret).verify(body, headers)ይጠቀሙ። Verification ካልተሳካ በ401ይከለክሉ። - Webhook secret-ን በenvironment variable ያከማቹ፣ በcode ውስጥ አይደለም። Secret በእያንዳንዱ Dashboard regeneration ላይ ይሮቴታል — deploy-ዎ ከenv ማንበብ አለበት፣ ከconstant አይደለም።
- በእያንዳንዱ handler ላይ idempotency። Webhook delivery-ዎች ሊደገሙ ይችላሉ።
svix-idheader-ን dedupe ለማድረግ በwebhook_eventstable ውስጥ እንደ primary key ይጠቀሙ። State change-ና idempotency insert-ን በተመሳሳዩ transaction ይከበቡ። - በ
user.deletedላይ PII-ን በ24 ሰዓታት ውስጥ hard-delete ወይም anonymize ያድርጉ። GDPR / CCPA ይጠይቃሉ። የdeletion path-ን audit ያድርጉ፦ የዚህን user data ምን table-ዎች ይይዛሉ? የሚቻለውን ቦታ FK ON DELETE CASCADE ይጠቀሙ።
Organization-ዎች እና permission-ዎች
Clerk Organizations ከተጠቀሙ፣ org boundary የእርስዎ tenant isolation ነው። እያንዳንዱ server-side query በእሱ filter መደረግ አለበት።
- በእያንዳንዱ API route ላይ ሁለቱንም
userIdእናorgId-ን ከauth()ያንብቡ እና database query-ዎችን በሁለቱም filter ያድርጉ።WHERE org_id = $orgId AND user_id = $userId። ከrequest body የመጣንorg_idበፍጹም አያምኑ። - <strong>Use Clerk role checks for privileged operations, not boolean checks against the user object.</strong> <code>has({ role: 'org:admin' })</code> reads the role from the verified JWT. A user can spoof a boolean on a stale client object; they cannot spoof a JWT claim.
- Cross-org isolation-ን በሁለት እውነተኛ org account-ዎች ይፈትኑ። Org A ይፈጥሩ፣ data ይሙሉ፣ በሌላ browser ላይ ወደ Org B sign in ያድርጉ፣ የOrg A data-ን በAPI ለማንበብ ይሞክሩ። Response
403ወይም404መሆን አለበት።
JWT template-ዎች እና external integration-ዎች
JWT template-ዎች የClerk identity-ን ወደ Supabase፣ Firebase እና ሌሎች downstream service-ዎች ይገፋሉ። የተበላሹ template-ዎች over-share claim ወይም ያልመጠኑትን data ያጋልጣሉ።
- ለእያንዳንዱ JWT template፣ እያንዳንዱን claim list ያድርጉ እና አስፈላጊ መሆኑን ያረጋግጡ። Dashboard → JWT Templates።
emailእናphone-ን ወደ Supabase የሚልክ template በbrowser ውስጥ JWT-ን ለሚያነብ ሁሉ PII ያጋልጣል። - ለclient-side downstream call-ዎች የተጠቀሙ JWT template-ዎች ላይ አጭር expiry ያስቀምጡ። ለdownstream API request 60 ሰከንዶች standard ነው። ረዥም-ጊዜ JWT-ዎች ይሰረቃሉ እና ይደገማሉ።
- በተቀባይ ጎን audience (
aud) claim-ን ያረጋግጡ። Supabase፣ Firebase ወዘተaudለሚጠበቀው service identifier መዛመዱን መፈትሽ አለባቸው። ያለ ይህ፣ ለservice A የተወጣ JWT ለservice B authenticate ሊያደርግ ይችላል።
Operational monitoring
Auth ካለዎት እጅግ-signal log source ነው። ይከታተሉት።
- በIP / በaccount failed-login ድንገተኛ መጨመር ላይ alert ያድርጉ። ከnormal failure rate 50× credential-stuffing attack ነው። Clerk እነዚህ event-ዎችን ወደ webhook ይልካል፤ ወደ SIEM ይዘርጉ።
- የsession እና instance settings drift ሩብ-ዓመታዊ review። Clerk ሲዘምን ነባሪዎች ይቀየራሉ፤ "የቆዩ configuration-ዎች" ከጊዜ ጋር በዝምታ ስህተት ይሆናሉ። Dashboard JSON export-ን ከመጨረሻ-known-good copy ጋር ይዳኝ።
ቀጣይ እርምጃዎች
በproduction URL-ዎ ላይ FixVibe scan ያስኪዱ — የbaas.clerk-auth0 check Clerk publishable key-ዎችን፣ በproduction ውስጥ test key-ዎችን እና bundled secret key-ዎችን ይሰምራል። በAuth0 ላይ ለሚተካከለው checklist Auth0 security checklist ይመልከቱ። በBaaS provider-ዎች ላይ ለሰፊ እይታ BaaS misconfiguration scanner ያንብቡ።