// docs / baas security / auth0 hardening

Auth0-ის უსაფრთხოების სია: 22 პუნქტი

Auth0 არის ვინაობა-როგორც-სერვისი პლატფორმა უზარმაზარი ზედაპირით — აპლიკაციები, API-ები (resource-სერვერები), ტენანტები, action-ები, წესები (legacy), კავშირები და გრანტები. ნებისმიერი მათგანის არასწორი კონფიგურაცია არის auth-ის გვერდს ავლა. ეს სია არის 22-პუნქტიანი აუდიტი აპლიკაციებზე, callback / logout-დაშვებებზე, ტოკენებსა და refresh-ცვლაზე, კასტომ-action-ებზე, RBAC-ზე, ანომალიების აღმოჩენაზე და მიმდინარე მონიტორინგზე. თითოეული პუნქტი დასამოწმებელია Auth0 Dashboard-ში 10 წუთზე ნაკლებში.

Clerk-ის ეკვივალენტური სიისთვის, ნახეთ Clerk-ის უსაფრთხოების სია. ფონური ინფორმაციისთვის, რატომ არის ვინაობის-ფენის არასწორი კონფიგურაციები AI-ხელსაწყოს ბრმა წერტილი, ნახეთ რატომ ტოვებენ AI-კოდირების ხელსაწყოები უსაფრთხოების ხარვეზებს.

აპლიკაციის ტიპი და გრანტის ტიპები

აპლიკაციის ტიპი და ჩართული გრანტის ტიპები არის ყველაზე მაღალი-ეფექტის პარამეტრები Auth0-ში. მათი არასწორი დაყენება ხსნის შეტევის კლასებს, რომელთა დახურვაც ვერც ერთი frontend-კოდი ვერ შეძლებს.

გამოიყენეთ Application Type = Single Page Application ბრაუზერ-მხოლოდ აპებისთვის და Regular Web Application სერვერ-რენდერებული აპებისთვის. არასწორი ტიპი დაუშვებს არასწორ გრანტის ტიპებს — მაგ., Regular Web App SPA-გრანტით ჩართავს PKCE-ის გარეშე Implicit ფლოუ-ს, რომელიც ჟონავს ტოკენებს URL-ფრაგმენტებით.
გათიშეთ Implicit გრანტის ტიპი ყოველ აპლიკაციაზე. Dashboard → Application → Advanced Settings → Grant Types → მოხსენით Implicit. Implicit ფლოუ აბრუნებს ტოკენებს URL-ფრაგმენტებში, სადაც ისინი ლოგდება ბრაუზერის ისტორიასა და ანალიტიკაში. გამოიყენეთ Authorization Code PKCE-თი ნაცვლად.
გათიშეთ Password-გრანტი, თუ არ გაქვთ დოკუმენტირებული საჭიროება. Resource Owner Password Credentials (ROPC) გრანტი მოითხოვს, რომ თქვენ თვითონ ამუშავოთ მომხმარებლის პაროლები — რომელიც გვერდს უვლის უმეტესობას იმისა, რის ყიდვაც Auth0-დან გასურდით. გათიშეთ, თუ legacy სისტემას არ აერთიანებთ.
ჩართეთ Authorization Code PKCE-თი ყოველ საჯარო კლიენტზე. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = ჩართული. PKCE სავალდებულოა მობილური აპებისთვის და SPA-ებისთვის, რომ თავიდან აიცილოს კოდის ჩარევა.

Callback და logout URL-დაშვების სიები

ღია გადამისამართებები OAuth-callback-ის გზაზე არის ტოკენი-ქურდობის პრიმიტივი. Auth0-ის დაშვების სია არის თქვენი ერთადერთი დაცვა.

დააწესეთ Allowed Callback URLs თქვენი ზუსტი პროდუქციის callback-გზაზე — wildcard-ის გარეშე. https://yourapp.com/callback, არა https://yourapp.com/*. Wildcard-callback-ები აძლევენ თავდამსხმელებს ტოკენების გადამისამართებას ნებისმიერი ქვეგზებზე თქვენს დომენზე.
დააწესეთ Allowed Logout URLs სასრულ სიაზე. იგივე წესი: მხოლოდ ცხადი URL-ები. ღია logout-გადამისამართება აძლევს თავდამსხმელებს phishing-გვერდების შექმნას, რომლებიც გავს თქვენი logout-შემდგომი მდგომარეობას.
დააწესეთ Allowed Web Origins თქვენი პროდუქციის origin-ზე მხოლოდ. გამოიყენება ჩუმი ავთენტიფიკაციისთვის (ტოკენის განახლება დაფარული iframe-ით). Wildcard-origin აძლევს თავდამსხმელის გვერდებს ჩუმი auth-ის შესრულებას თქვენი ტენანტის წინააღმდეგ.
დააწესეთ Allowed CORS origins API-endpoint-ებისთვის, არა აპლიკაციისთვის. Tenant Settings → Advanced → Allowed CORS origins. ნაგულისხმევი არის ცარიელი (შეზღუდული); დაამატეთ მხოლოდ ცხადი origin-ები, რომელსაც აკონტროლებთ.

ტოკენები და refresh-ცვლა

ტოკენის სიცოცხლის ხანგრძლივობა, refresh-ცვლა და ხელმოწერის ალგორითმი წყვეტენ ნებისმიერი ტოკენი-ჟონვის აფეთქების რადიუსს.

ჩართეთ Refresh Token Rotation. Application → Refresh Token Settings → Rotation. ყოველი refresh გასცემს ახალ refresh-ტოკენს და აუქმებს ძველს. შერეული აბსოლუტური ვადის გასვლასთან, ეს იცავს ტოკენი-ქურდობას.
დააწესეთ Refresh Token Reuse Interval 0-ზე (ან რაც შეიძლება დაბალზე, რასაც თქვენი replay-ის ტოლერანტობა აძლევს ნებას). Reuse interval-ი დაუშვებს ტოკენის ორჯერ გამოყენებას იმავე ფანჯარაში — გათიშეთ ის, თუ კონკრეტული მიზეზი არ გაქვთ მის შესანახად.
დააწესეთ Absolute Refresh Token Expiry 14-30 დღეზე, არა უსასრულობაზე. Application → Refresh Token Expiration → Absolute Expiration. Auth0 ნაგულისხმევად მხოლოდ Inactivity-ზე იყენებს, რაც ნიშნავს, რომ უმოქმედო სესია წლების განმავლობაში შეიძლება გრძელდებოდეს.
დააწესეთ JWT-ხელმოწერის ალგორითმი RS256-ზე. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 იყენებს ასიმეტრიულ ხელმოწერას, ისე რომ კლიენტმა ვერ გააფერმკრთალოს ტოკენები. არასოდეს გამოიყენოთ HS256 კლიენტისთვის-მიმართულ აპლიკაციებში.
დაამოწმეთ aud და iss claim-ები ყოველ JWT-ზე, რომელსაც თქვენი API იღებს. გამოიყენეთ ოფიციალური Auth0 SDK სერვერის მხარეს — ის ავტომატურად დაამოწმებს. ხელით-მოწერილი JWT-პარსირება ჩვეულებრივ ცდილობს audience-ვალიდაციას, რომელიც არის auth-ის გვერდს ავლა.

Action-ები და კასტომ-კოდი

Auth0 Action-ები (და legacy Rule-ები) მუშაობენ სერვერის მხარეს შესვლისას და სხვა სასიცოცხლო ციკლის მოვლენებზე. მათ აქვთ წვდომა მთლიან მოთხოვნის კონტექსტზე. არასაიმედო კოდი აქ არის ტენანტ-ფართო მოწყვლადობა.

არასოდეს ლოგი გააკეთოთ event.user-ის ან event.transaction-ის მთლიან ობიექტად. ეს შეიცავს ელფოსტის მისამართებს, IP-მისამართებს და სხვა PII-ს. გამოიყენეთ ველის-დონის ლოგი მხოლოდ და ლოგი მხოლოდ ის, რაც გჭირდებათ.
გამოიყენეთ საიდუმლოების შენახვა ნებისმიერი API-გასაღებისთვის ან webhook-URL-ისთვის. Actions → Edit → Secrets. არასოდეს არ ჩასვათ API-გასაღები სტრიქონის ლიტერალად action-ის კოდში — კოდი ხილულია ნებისმიერი ადამიანისთვის, ვისაც აქვს Action-რედაქტორის წვდომა ტენანტზე.
დაამოწმეთ ინფუთები, სანამ მათ user_metadata-ად ან app_metadata-ად შეინახავთ. Self-service action, რომელიც წერს event.body.name-ს user.user_metadata.display_name-ში არის შენახული-XSS-ვექტორი, თუ თქვენი frontend ამ ველს რენდერავს გადახაზვის გარეშე.

RBAC და resource-სერვერები

თუ იყენებთ Auth0 RBAC-ს, როლი-ნებართვა მაპპინგი არის თქვენი ავტორიზაციის ფენა. არასწორად დააყენებთ და ნებისმიერ ავთენტიფიცირებულ მომხმარებელს შეუძლია მოხვდეს ადმინ-endpoint-ებზე.

განსაზღვრეთ Resource Server-ები (API-ები) ცხადად Auth0 Dashboard-ში, არა ფრენაში. ყოველ API-ს აქვს იდენტიფიკატორი (audience), სკოპები და ხელმოწერის პარამეტრები. დარეგისტრირებული API-ის გარეშე, ყოველი ტოკენი გაცემულია იმპლიციტური „Auth0 Management API"-ისთვის — არასწორი audience.
კონფიგურირეთ ნებართვები API-ზე და მოითხოვეთ ისინი თქვენს კოდში scope claim-ით. ნუ შეამოწმებთ როლის წევრობას თქვენი აპლიკაციის ლოგიკაში; შეამოწმეთ სკოპები access-ტოკენში. სკოპები არის OAuth-მშობლიური ავტორიზაციის მექანიზმი.
დაატესტეთ, რომ ავთენტიფიცირებულ მომხმარებელს საჭირო როლის / სკოპის გარეშე არ შეუძლია მოხვდეს პრივილეგირებულ endpoint-ებზე. შედით ნორმალურ მომხმარებლად, სცადეთ გამოიძახოთ POST /api/admin/users/delete. პასუხი უნდა იყოს 403.

ანომალიების აღმოჩენა და ტენანტ-ლოგები

Auth0 აისროლებს მაღალი-სიგნალის მოვლენებს. დააყენეთ ისინი თქვენი გუნდის გასაფრთხილებლად, არა მხოლოდ ლოგ-ბუფერში ჩაჯდომისთვის.

ჩართეთ Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. თითოეული გათიშულია ნაგულისხმევად უფასო ტარიფზე; ჩართეთ ისინი ყველა პროდუქციისთვის.
გადაუგზავნეთ ტენანტ-ლოგები SIEM-ს ან თქვენი აპლიკაციის ლოგებს. Dashboard → Monitoring → Streams. Auth0 იცავს ლოგებს 30 დღით უმეტესობა გეგმაზე; გრძელვადიანი შენახვა მოითხოვს stream-ს თქვენი საკუთარი სისტემაში.
გააფრთხილეთ fcoa-სა (ვერ ჯვარედინი-origin auth) და fp-ის (ვერ შესვლის) ბუნებზე. ამ მოვლენების ბუნი მოკლე ფანჯარაში არის credential-stuffing. გადაუგზავნეთ თქვენი on-call არხს.

შემდეგი ნაბიჯები

გაუშვით FixVibe-სკანი თქვენი პროდუქციის URL-ის წინააღმდეგ — baas.clerk-auth0 შემოწმება მონიშნავს Auth0-ის კლიენტის საიდუმლოებს, ბანდლირებულს JavaScript-ში და სხვა ვინაობის-პროვაიდერის გამოვლენის კლასებს. Clerk-ის ეკვივალენტურისთვის, ნახეთ Clerk-ის უსაფრთხოების სია. BaaS-პროვაიდერებზე ერთიანი ხედვისთვის, წაიკითხეთ BaaS-ის არასწორი კონფიგურაციის სკანერი.