მთავარი დასკვნა
თითოეული საბოლოო წერტილისთვის განსაზღვრეთ ვინაობის შემოწმება, ობიექტის დონის ავტორიზაცია, დასაშვები სქემა და რომელი მგრძნობიარე მონაცემები უნდა გამოირიცხოს პასუხიდან.
რას განსაზღვრავს საბოლოო წერტილი
API პროგრამებს განსაზღვრული წესებით მონაცემების გაცვლისა და ოპერაციების შესრულების საშუალებას აძლევს. საბოლოო წერტილი არის სერვერზე ან სერვისში რესურსის URL მასზე გამოყენებულ მეთოდთან ერთად: კლიენტი აგზავნის მოთხოვნას, სერვისი კი პასუხს აბრუნებს. მაგალითად, GET /accounts/{id}‑ს შეუძლია ანგარიშის წაკითხვა, POST /payments‑ს კი გადახდის შექმნა. URL‑ის ცოდნა წვდომას არ ანიჭებს.
რესურსი
განსაზღვრავს მისამართებულ მონაცემებს ან ოპერაციას.
იდენტობა და ავტორიზაცია
ამოწმებს, ვინ გაგზავნა მოთხოვნა და რისი უფლება აქვს რესურსთან მიმართებით.
პასუხი
აბრუნებს მხოლოდ აუცილებელ მონაცემებს და არ ამჟღავნებს შიდა კონფიგურაციას ან საიდუმლოებებს.
გამოყავით /health და /info საბოლოო წერტილები
/health ჩვეულებრივ მოკლე სიგნალს იძლევა, მუშაობს თუ არა პროცესი ან სერვისი; ორკესტრატორმა ან მონიტორმა ის შეიძლება მზადყოფნის ან გადატვირთვის ქცევის განსასაზღვრად გამოიყენოს. Kubernetes‑ში კონტეინერი გადაიტვირთება, როცა liveness შემოწმებების წარუმატებლობა კონფიგურირებულ ზღვარს მიაღწევს, readiness კი მოუმზადებელ პოდს Kubernetes Service‑ით მარშრუტიზებული ახალი ტრაფიკიდან გამორიცხავს. Readiness ქსელის უსაფრთხოების წესი არ არის და პოდზე ყველა წვდომას არ ბლოკავს. /info‑მ შეიძლება აპლიკაციის ვერსია და აგების მეტამონაცემები გამოაჩინოს. სახელები სტანდარტულ ქცევას არ იძლევა გარანტიად: შიგთავსს, წვდომის დონესა და ქსელურ არეალს თქვენ აკონტროლებთ. საჯარო პასუხებში არ შეიტანოთ საიდუმლოებები, გარემოს ცვლადები, შიდა მისამართები, კომპონენტების ზუსტი ვერსიები და დამოკიდებულებების მგრძნობიარე სტატუსი; შეამცირეთ დიაგნოსტიკური დეტალები და საჭიროებისამებრ მოითხოვეთ ავთენტიფიკაცია.
ძლიერი ავთენტიფიკაცია და ობიექტის დონის ავტორიზაცია
API‑ის ყველა ტრაფიკისთვის მოითხოვეთ HTTPS. მომხმარებლის ან სერვისის ვინაობა შესაბამისი მექანიზმით გადაამოწმეთ; შეზღუდეთ ტოკენის მოქმედების ვადა, აუდიტორია და უფლებების არეალი, საიდუმლოებები კი ვერსიების საცავში არ შეიტანოთ. ყოველ მოთხოვნაზე სერვერში ხელახლა შეამოწმეთ ავტორიზაცია კონკრეტული ობიექტისა და ოპერაციისთვის: მომხმარებლის ავთენტიფიკაცია სხვა ანგარიშზე ან ადმინისტრაციულ ფუნქციაზე წვდომას არ ანიჭებს. სერვისებს ცალკე იდენტობები და მინიმალურად აუცილებელი უფლებები მიეცით.
დაიცავით შემომავალი მონაცემები და მონაცემთა ბაზის მოთხოვნები
სერვერში შეამოწმეთ მოთხოვნის ზომა, შიგთავსის ტიპი და სქემა, დასაშვები ველებისა და ფორმატების მკაფიო წესებით. SQL მომხმარებლის ტექსტის მიერთებით არ ააგოთ. პარამეტრიზებული მოთხოვნები მნიშვნელობებს SQL კოდისგან გამოყოფს და SQL ინექციისგან დაცვის ძირითადი საშუალებაა. შეყვანის შემოწმება დამატებით შრედ სასარგებლოა, თუმცა პარამეტრიზაციას არ ცვლის. მონაცემთა ბაზის ანგარიშს მხოლოდ აუცილებელ ცხრილებსა და ოპერაციებზე მიეცით უფლება, მომხმარებლებისგან დამალეთ დეტალური შეცდომები და პაროლები შესაბამისი ნელი, მარილიანი ჰეშით შეინახეთ.
შეზღუდეთ რესურსების მოხმარება და გამოსცადეთ საბოლოო წერტილები
შეზღუდეთ მოთხოვნების სიხშირე, გვერდებად დაყოფა, სხეულის ზომა და ძვირადღირებული ძიებისა თუ ექსპორტის ოპერაციების ღირებულება. გაითვალისწინეთ ავთენტიფიკაციამდე და მის შემდეგ შემთხვევები, თითოეული ანგარიშისა თუ გასაღების მოხმარება; მხოლოდ IP‑ზე ლიმიტმა განაწილებული ბოტები შეიძლება ვერ შეაჩეროს. ჟურნალებში არ შეიტანოთ პირადი მონაცემები, ტოკენები და პაროლები, თუმცა განსაზღვრული შენახვისა და წვდომის პოლიტიკით გამოვლენისთვის საკმარისი მოვლენები შეინარჩუნეთ. გამოსცადეთ არასწორი ტოკენები, სხვა მომხმარებლის ობიექტის ID, დამატებითი ველები, ზედმეტად დიდი მონაცემები, SQL სინტაქსი და ლიმიტების აღსრულება. დაადასტურეთ პასუხის კოდების, დაყოვნების, შეცდომებისა და ბლოკირების ქცევის მოლოდინებთან შესაბამისობა.