უსაფრთხოების ჩამონათვალი AI-ით აშენებული აპებისთვის: რა შევამოწმოთ გაშვებამდე

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

AI აპლიკაციის შემქმნელები კარგად აკეთებენ ფუნქციების მუშაობას. ისინი ავტომატურად არ არიან ფრთხილები, რადგან „ფრთხილად ყოფნა“ იშვიათად წერია მოთხოვნაში. ქვემოთ მოცემული პრობლემების უმეტესობა წარმოიქმნება იმ რამეებისგან, რაც არავის უთხოვია, ამიტომ გამოსწორება ჩვეულებრივ იმაში მდგომარეობს, რომ ითხოვო.

როგორ გამოვიყენოთ ეს ჩამონათვალი

გაიარეთ იგი თანმიმდევრობით და თითოეულ პუნქტზე ორი რამ გააკეთეთ: ჰკითხეთ AI-ს, რომ დამუშავებულია, და თავად გამოსცადეთ. AI-ს შეუძლია უფლებების შემოწმების დაწერა; მხოლოდ ტესტი გეტყვით, რომ ის მუშაობს. პუნქტები მონიშნულია ასე:

• სავალდებულო — გააკეთეთ ეს, სანამ აპს სხვა ვინმე გამოიყენებს.
• რეკომენდებულია — გააკეთეთ ეს, სანამ გექნებათ რეალური მომხმარებლები ან რეალური მონაცემები.
• მოგვიანებით — ღირს ამის გაკეთება აპის ზრდასთან ერთად.

თუ მხოლოდ ერთი საათი გაქვთ, გააკეთეთ ყველა სავალდებულო პუნქტი.

1. ავთენტიკაცია: ვინ არის ეს?

ავთენტიკაცია ნიშნავს ადამიანის ვინაობის დადასტურებას, ჩვეულებრივ შესვლის საშუალებით. იხილეთ რა არის ავთენტიკაცია საფუძვლებისთვის და როგორ დავამატოთ შესვლა აპში ვარიანტებისთვის.

• სავალდებულო: ყველა გვერდი, რომელიც პირად მონაცემებს აჩვენებს, მოითხოვს შესვლას. ტესტი: გამოდით სისტემიდან და ჩასვით პირადი გვერდის URL პირდაპირ ბრაუზერში.
• სავალდებულო: ყველა API ბოლო წერტილი, რომელიც ამ გვერდებს უდევს საფუძვლად, ასევე მოითხოვს შესვლას — არა მხოლოდ გვერდი. ტესტი: გამოდით სისტემიდან, გახსენით ბრაუზერის ქსელის ჩანართი და გაიმეორეთ მოთხოვნა, რომელსაც აპი აკეთებდა შესვლილი ყოფნისას.
• სავალდებულო: პაროლები ინახება ჰეშირებული ნელი პაროლის ჰეშირების ალგორითმით, არასდროს უბრალო ტექსტად. OWASP-ის პაროლის შენახვის რეკომენდაცია ჯერ Argon2id-ს ასახელებს, ალტერნატივებად scrypt-ს, bcrypt-ს ან PBKDF2-ს. ჰკითხეთ: „როგორ ინახება პაროლები?“
• რეკომენდებულია: პაროლის აღდგენის ბმულები ვადაგასულია და მუშაობს მხოლოდ ერთხელ.
• რეკომენდებულია: სესიის cookie-ები მონიშნულია Secure, HttpOnly და SameSite-ით, ხოლო გამოსვლა სერვერზე ასრულებს სესიას.
• მოგვიანებით: შესთავაზეთ ორფაქტორიანი ავთენტიკაცია ან შესვლა პროვაიდერით, რომელსაც ის აქვს.

შეამოწმეთ ყოველი API მარშრუტი და გვერდი, რომელიც მომხმარებლის მონაცემებს აბრუნებს. თითოეულმა უნდა უარყოს მოთხოვნები მომხმარებლებისგან, რომლებიც არ არიან შესულები, სერვერზე და არა მხოლოდ გვერდის კოდში. ჩამოწერეთ მარშრუტები, რომლებიც შეამოწმეთ.

2. ავტორიზაცია: რის გაკეთება შეუძლიათ?

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

• სავალდებულო: ყოველი წაკითხვა, განახლება და წაშლა სერვერზე ამოწმებს, რომ ჩანაწერი მიკუთვნებულია მიმდინარე მომხმარებელს (ან მის გუნდს).
• სავალდებულო: ტესტი: შექმენით ორი ანგარიში, A და B. A-ს ანგარიშით გახსენით ერთ-ერთი A-ს ჩანაწერი და ჩაიწერეთ მისი ID URL-ში ან ქსელურ მოთხოვნაში. შედით B-ს ანგარიშით და მოითხოვეთ იგივე ID. B-მ უნდა მიიღოს შეცდომა და არა A-ს მონაცემები.
• სავალდებულო: ადმინისტრატორის გვერდები და ადმინისტრატორის API ბოლო წერტილები სერვერზე ამოწმებენ მომხმარებლის როლს. ადმინისტრატორის ბმულის დამალვა დაცვა არ არის.
• სავალდებულო: მომხმარებლებს არ შეუძლიათ საკუთარი როლის, ფასის, ბალანსის ან მფლობელის ველების შეცვლა მოთხოვნის რედაქტირებით. ტესტი: ქსელის ჩანართში ნახეთ, რას აგზავნის პროფილის განახლება. თუ შედის ისეთი ველები, როგორიცაა role ან isAdmin, სთხოვეთ AI-ს, რომ კლიენტიდან ისინი იგნორირებულ იქნას.
• რეკომენდებულია: URL-ებში ID-ები რთული გამოსაცნობი იყოს (შემთხვევითი ID-ები და არა 1, 2, 3). ეს არ ცვლის უფლებების შემოწმებას, მაგრამ ზღუდავს ზიანს, თუ ერთი მათგანი აკლია.

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

3. მწკრივის დონის წვდომა მონაცემთა ბაზაში

„მწკრივის დონის წვდომა“ ნიშნავს, რომ ცხრილის თითოეული მწკრივი (ერთი დაჯავშნა, ერთი ინვოისი) ჩანს მხოლოდ იმ მომხმარებლებისთვის, ვისაც ის ეკუთვნის. ამის აღსრულების ორი გავრცელებული გზა არსებობს:

ორივე კარგად შეიძლება. მნიშვნელოვანია:

• სავალდებულო: თუ ბრაუზერი პირდაპირ ესაუბრება მონაცემთა ბაზას (ზოგი ჰოსტირებული მონაცემთა ბაზის პროდუქტი ამის საშუალებას იძლევა), მწკრივის დონის წესები ჩართულია ყველა ცხრილზე. მათ გარეშე, ვინც საჯარო გასაღები იცის, შეძლებს მთელი ცხრილის წაკითხვას.
• სავალდებულო: მოთხოვნები ფილტრავს მიმდინარე მომხმარებლით ან გუნდით, და არა ბრაუზერის მიერ გაგზავნილი ID-ით.
• რეკომენდებულია: საერთო მონაცემებს (გუნდის პროექტებს) აქვთ მკაფიო წესი იმის შესახებ, ვინ არის გუნდში, და ის აღსრულდება ერთ ადგილას.

4. საიდუმლოები და API გასაღებები

API გასაღები არის სერვისის პაროლი. Stripe-ი, ელფოსტის და AI პროვაიდერები ყველა მათ იყენებს. ფონისთვის იხილეთ რა არის გარემოს ცვლადები და საიდუმლოები.

• სავალდებულო: გასაღებები ინახება პროექტის გარემოს ცვლადებში ან საიდუმლოებებში და არასდროს იწერება კოდში.
• სავალდებულო: გასაღებები, რომლებსაც შეუძლიათ ფულის დახარჯვა ან პირადი მონაცემების წაკითხვა, გამოიყენება მხოლოდ სერვერზე. ტესტი: გახსენით თქვენი ცოცხალი საიტი, ნახეთ გვერდის წყარო და JavaScript ფაილები დეველოპერის ინსტრუმენტებში და მოძებნეთ თქვენი გასაღების დასაწყისი (მაგალითად sk_). ის არ უნდა ჩანდეს.
• სავალდებულო: გასაღებები არასდროს ჩაგისვამთ ჩატში, საჯარო რეპოზიტორიაში ან ეკრანის ანაბეჭდში. თუ ჩაგისვამთ, შეცვალეთ ისინი პროვაიდერთან (შექმენით ახალი და წაშალეთ ძველი).
• რეკომენდებულია: გამოიყენეთ შეზღუდული ან შეზღუდული უფლებების გასაღებები, სადაც პროვაიდერი სთავაზობს მათ. Stripe, მაგალითად, გვირჩევს შეზღუდულ გასაღებებს, რომლებსაც აქვთ მხოლოდ ინტეგრაციისთვის საჭირო უფლებები.
• რეკომენდებულია: სატესტო და ცოცხალი გასაღებები ცალკეა, ხოლო ცოცხალი აპი ცოცხალ გასაღებებს იყენებს მხოლოდ მაშინ, როცა მზად ხართ.

ზოგი გასაღები შექმნილია საჯაროდ გამოსაყენებლად — Stripe-ის publishable გასაღები (pk_…) ან რუკების გასაღები, რომელიც შემოიფარგლება თქვენი დომენით. წესი ეხება გასაღებებს, რომლებიც უფლებას აძლევენ, და არა ყველა სტრიქონს, რომელიც გასაღებს ჰგავს.

5. შეყვანის ვალიდაცია

ყველაფერი, რასაც მომხმარებელი აგზავნის — ფორმის ველები, ფაილის ატვირთვა, URL პარამეტრები — შეიძლება იყოს რაიმე, არა მხოლოდ ის, რაც თქვენი ფორმა უშვებს.

• სავალდებულო: ვალიდაცია ხდება სერვერზე და არა მხოლოდ ბრაუზერში. ბრაუზერის შემოწმებები მოსახერხებლობისთვისაა; ნებისმიერს შეუძლია მათი გვერდის ავლა.
• სავალდებულო: მონაცემთა ბაზის მოთხოვნები იყენებს პარამეტრებს და არა მომხმარებლის შეყვანიდან გადმოწერილ ტექსტს (ეს იცავს SQL ინექციისგან). ჰკითხეთ AI-ს დასადასტურებლად.
• სავალდებულო: მომხმარებლის მიერ შეყვანილი ტექსტი ნაჩვენებია როგორც ტექსტი და არა როგორც HTML. ტესტი: შეიყვანეთ <b>hello</b> როგორც თქვენი სახელი. უნდა ნახოთ თეგები და არა მუქი ტექსტი.
• რეკომენდებულია: ფაილის ატვირთვა ამოწმებს ტიპს და ზომას, ხოლო ატვირთული ფაილები არ მიეწოდება თქვენი აპის მთავარი დომენიდან როგორც გასაშვები გვერდები.
• რეკომენდებულია: მომხმარებლებისთვის ნაჩვენები შეცდომები მარტივია („რაღაც არასწორად მოხდა“); დეტალური შეცდომები მხოლოდ სერვერის ჟურნალში მიდის.
• რეკომენდებულია: Webhook-ები ისეთი სერვისებიდან, როგორიცაა Stripe, ამოწმებენ პროვაიდერის ხელმოწერას მოქმედებამდე. იხილეთ რა არის webhook.

დაამატეთ სერვერის მხარის ვალიდაცია ყოველ ფორმაზე და API ბოლო წერტილზე: სავალდებულო ველები, სიგრძეები, ფორმატები და დასაშვები მნიშვნელობები. ყველაფერი დანარჩენი უარყავით მკაფიო შეტყობინებით. არ აჩვენოთ შიდა შეცდომის დეტალები მომხმარებლებს.

6. რეიტ ლიმიტები და ბოროტად გამოყენება

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

• სავალდებულო: შესვლა, რეგისტრაცია და პაროლის აღდგენა შეზღუდულია IP მისამართით და ანგარიშით.
• სავალდებულო: ყველაფერი, რაც ფულს გიჯდებათ ზარზე — AI მოდელის მოთხოვნები, SMS, ელფოსტა — აქვს მომხმარებლის ლიმიტს და მოითხოვს შესვლას.
• რეკომენდებულია: საჯარო ფორმებს (კონტაქტი, ლოდინის სია) აქვთ სპამისგან დაცვა: რეიტ ლიმიტი, დამალული ველი ხაფანგისთვის ან CAPTCHA.
• რეკომენდებულია: დააყენეთ ხარჯების ზღვრები ან შეტყობინებები ფასიან პროვაიდერებთან, რომ ბაგმა ან შემტევმა უსასრულო ანგარიში ვერ გამოიწვიოს.

7. დამოკიდებულებები

აპები აშენებულია ღია კოდის პაკეტებისგან, და პაკეტებს ზოგჯერ აქვთ ცნობილი დაუცველობები.

• რეკომენდებულია: სთხოვეთ AI-ს შეამოწმოს ცნობილი დაუცველობები (JavaScript პროექტებისთვის npm audit ან თქვენი პაკეტების მენეჯერის ეკვივალენტი) და განაახლოს დაზარალებული.
• რეკომენდებულია: წაშალეთ პაკეტები, რომლებსაც აპი აღარ იყენებს.
• რეკომენდებულია: ფრთხილად იყავით პაკეტებთან, რომლებსაც ძალიან ცოტა მომხმარებელი ჰყავს ან რომელთა სახელები პოპულარული პაკეტების ტიპოგრაფიულ შეცდომებს ჰგავს.
• მოგვიანებით: გადაამოწმეთ ყოველ ერთ-ორ თვეში, ან ჩართეთ ავტომატური შეტყობინებები, თუ თქვენი კოდი GitHub-ზეა.

8. სარეზერვო ასლები და აღდგენა

უსაფრთხოება მოიცავს იმის შესაძლებლობას, რომ შეცდომებისგან აღდგეთ — თქვენი, AI-ის ან შემტევის.

• სავალდებულო: იცოდეთ, სად ინახება თქვენი მონაცემები და არის თუ არა სარეზერვო ასლი. ნუ ივარაუდებთ; შეამოწმეთ თქვენი ჰოსტის დოკუმენტაცია.
• რეკომენდებულია: შეინახეთ თქვენი პერიოდული ექსპორტი მნიშვნელოვანი მონაცემებისა (მაგალითად, CSV ექსპორტის ფუნქცია ან მონაცემთა ბაზის დამპი), სხვა ადგილას შენახული.
• რეკომენდებულია: შეინახეთ თქვენი კოდი ვერსიების კონტროლში, რომ ნებისმიერი ვერსია აღდგეს.
• რეკომენდებულია: განადგურებადი მოქმედებები (ანგარიშის წაშლა, პროექტის წაშლა) მოითხოვს დადასტურებას, და განიხილეთ „soft delete“, რომელიც გარკვეული დროით შეიძლება გაუქმდეს.
• მოგვიანებით: ერთხელ მაინც გამოსცადეთ აღდგენა. სარეზერვო ასლი, რომელიც არასდროს აღგიდგენიათ, იმედია და არა გეგმა.

9. გაშვებამდე

• სავალდებულო: ცოცხალი საიტი ყველგან იყენებს HTTPS-ს.
• სავალდებულო: განვითარებიდან დარჩენილი ნიმუშის მონაცემები, სატესტო ანგარიშები და დებაგის გვერდები ამოღებულია.
• რეკომენდებულია: კონფიდენციალურობის პოლიტიკა ამბობს, რა მონაცემებს აგროვებთ და რატომ — ბევრ ადგილას სავალდებულოა, თუ აგროვებთ პერსონალურ მონაცემებს. ნუ მიუთითებთ სერტიფიკატებს (SOC 2, HIPAA), რომლებიც არ გაქვთ.
• რეკომენდებულია: გაქვთ გზა, როგორც უსაფრთხოების პრობლემებზე დაგიკავშირდნენ, და იცით, როგორ შეცვალოთ ყველა გასაღები სწრაფად.

უსაფრთხოების მიღმა უფრო ფართო გაშვებამდე შემოწმებისთვის იხილეთ როგორ გადავიყვანოთ AI პროტოტიპი წარმოებაში.

როდის დასჭირდება პროფესიონალის მიმოხილვა

ჩამონათვალი ხშირ შეცდომებს იჭერს, მაგრამ ექსპერტს ვერ ანაცვლებს. განიხილეთ გადახდა მიმოხილვაზე, თუ ბარათის ნომრებს თავად ამუშავებთ და არა ჰოსტირებული checkout-ით, ინახავთ ჯანმრთელობის, ფინანსურ ან ბავშვთა მონაცემებს, ყიდით კომპანიებს, რომლებიც უსაფრთხოების კითხვარს ითხოვენ, ან სერიოზულად დაზარალდებით გაჟონვის შემთხვევაში. თქვენი კოდის ექსპორტირებადობა ამ მიმოხილვას გაცილებით ამარტივებს.

უსაფრთხოება Mythex-ზე აშენებისას

Mythex-ში არ არის უსაფრთხოების სკანირების პანელი, ამიტომ ზემოთ მოცემული ჩამონათვალი არის პროცესი, რომელსაც უნდა მიჰყვეთ. რაღაცები, რომლებიც დაგეხმარებათ:

• პროექტის საიდუმლოებები. შეინახეთ გასაღებები პროექტის პარამეტრებში → Secrets, ან აგენტის ჩატში ნაჩვენები საიდუმლოებების ბარათით, რომ ისინი კოდსა და შეტყობინებებში არ მოხვდეს. ცოცხალი აპის საიდუმლოს შეცვლის შემდეგ, თავიდან გამოაქვეყნეთ.
• Plan და Ask რეჟიმები. სთხოვეთ აგენტს შეამოწმოს უფლებები რედაქტირების გარეშე: „Ask რეჟიმში ჩამომითვალეთ ყველა API მარშრუტი და რა უფლებების შემოწმებას ასრულებს.“
• /test აგენტს აძლევს საშუალებას, მომხმარებლის სახით გაიაროს თქვენი გადახედვა — სასარგებლოა მე-2 ნაწილის ორი ანგარიშით ტესტისთვის.
• Checkpoints საშუალებას გაძლევთ დაბრუნდეთ ცვლილებაზე, რომელმაც რამე დაამტვრია.

იხილეთ უსაფრთხოება თქვენს მიერ აშენებული აპებისთვის და გარემოს ცვლადები და საიდუმლოებები დოკუმენტაციაში. თუ შემდეგ მომხმარებლის ანგარიშებს ამატებთ, წაიკითხეთ როგორ დავამატოთ შესვლა აპში.

კითხვები