Əsas fikir
Hər endpoint üçün kimliyin yoxlanmasını, obyekt səviyyəsində icazəni, qəbul edilən sxemi və həssas məlumatın cavabdan çıxarılmasını müəyyən edin.
Endpoint nəyi müəyyən edir
API proqramların əvvəlcədən müəyyən edilmiş qaydalarla məlumat və əməliyyat mübadiləsi aparmasına imkan verir. Endpoint server və ya xidmət üzərində resursu göstərən URL və həmin resursa tətbiq olunan metoddur; müştəri sorğu göndərir, xidmət cavab qaytarır. Məsələn, GET /accounts/{id} oxuma əməliyyatını, POST /payments isə ödəniş yaratma əməliyyatını ifadə edə bilər. URL-i bilmək həmin resursa icazə verildiyini göstərmir.
Resurs
Hansı məlumat və ya əməliyyatın əlçatan olduğunu dəqiqləşdirir.
Kimlik və icazə
Sorğunu kimin göndərdiyini və həmin resurs üzərində nə edə biləcəyini yoxlayır.
Cavab
Yalnız tələb olunan məlumatı qaytarır; daxili sazlama və sirrləri açıqlamır.
/health və /info endpoint-lərini ayırın
/health adətən prosesin və ya xidmətin işləkliyinə dair qısa siqnal verir; orchestrator və monitorinq onu hazır olma və ya yenidən başlatma qərarlarında istifadə edə bilər. Kubernetes-də uğursuz liveness yoxlamaları konfiqurasiya olunmuş həddə çatdıqda konteyner yenidən başladılır, readiness yoxlaması isə hazır olmayan pod-a Kubernetes Service vasitəsilə yeni trafikin yönləndirilməsini dayandırır; bu, şəbəkə girişini bloklayan təhlükəsizlik qaydası deyil. /info tətbiq versiyası və quruluş metadatasını göstərə bilər. Hər iki endpoint-in adı standart davranışa zəmanət vermir: məzmunu, giriş səviyyəsini və şəbəkə əhatəsini siz müəyyən edirsiniz. İctimai cavabda sirr, mühit dəyişəni, daxili ünvan, dəqiq komponent versiyası və həssas asılılıq vəziyyətini qaytarmayın; diaqnostika məlumatını məhdudlaşdırın və ehtiyac varsa autentifikasiya arxasına keçirin.
Güclü autentifikasiya və obyekt səviyyəli icazə
HTTPS-i bütün API trafikində məcburi edin. İstifadəçi və xidmət kimliyini uyğun mexanizmlə yoxlayın; tokenin etibarlılıq müddətini, auditoriyasını və əhatə dairəsini məhdudlaşdırın, sirləri kod deposuna yazmayın. Hər sorğuda konkret obyekt və əməliyyat üçün icazəni server tərəfində yenidən yoxlayın: istifadəçinin autentifikasiyası başqa istifadəçinin hesabına və ya inzibati funksiyaya giriş hüququ yaratmır. Xidmətlərə ayrıca identiklik verin və minimum səlahiyyət tətbiq edin.
Daxil olan məlumatı və verilənlər bazası sorğularını qoruyun
Sorğunun ölçüsünü, məzmun tipini və sxemini server tərəfində yoxlayın; qəbul edilən sahələr və formatlar üçün açıq qaydalar müəyyən edin. SQL sorğusunu istifadəçi mətnini birləşdirərək qurmayın. Parametrli sorğular dəyəri SQL kodundan ayırır; bu, SQL injection-a qarşı əsas müdafiədir. Məlumat yoxlaması faydalı əlavə qatdır, parametrizasiyanı əvəz etmir. Verilənlər bazası hesabına yalnız tələb olunan cədvəl və əməliyyatları verin, detallı xəta mesajlarını istifadəçiyə göstərməyin və parolları uyğun yavaş, duzlanmış hash ilə saxlayın.
Resurs istifadəsini məhdudlaşdırın və endpoint-ləri sınaqdan keçirin
Sorğu tezliyi ilə yanaşı səhifələmə, sorğu ölçüsü, bahalı axtarış və ixrac əməliyyatlarının xərclərini də məhdudlaşdırın. Limitlər autentifikasiya öncəsi və sonrası ssenariləri, hesab və açar üzrə istifadələri nəzərə alsın; tək IP limiti botların paylanmasını dayandırmaya bilər. Şəxsi məlumatı, tokenləri və parolları loglara yazmayın; girişləri aşkarlama üçün kifayət qədər saxlayın, lakin saxlanma və giriş qaydalarını tətbiq edin. Testlərdə səhv token, başqa istifadəçiyə məxsus obyekt ID-si, artıq sahələr, böyük payload, SQL sintaksisi və limit həddini yoxlayın. Cavab kodu, gecikmə, xəta və bloklama davranışının gözlənilən olduğunu təsdiqləyin.