Asosiy xulosa
Har bir oxirgi nuqta uchun shaxsni tekshirish, obyekt darajasidagi vakolat, qabul qilinadigan sxema va javobga kiritilmasligi kerak boʻlgan maxfiy maʼlumotlarni belgilang.
Oxirgi nuqta nimani belgilaydi
API dasturlarga belgilangan qoidalar asosida maʼlumot almashish va operatsiyalarni bajarish imkonini beradi. Oxirgi nuqta — server yoki xizmatdagi resurs URLi va unga qoʻllanadigan usul: mijoz soʻrov yuboradi, xizmat esa javob qaytaradi. Masalan, GET /accounts/{id} hisobni oʻqishi, POST /payments esa toʻlov yaratishi mumkin. URLni bilish kirish huquqini bermaydi.
Resurs
Murojaat qilinayotgan maʼlumot yoki operatsiyani belgilaydi.
Shaxs va vakolat
Soʻrovni kim yuborganini va resurs bilan nima qilishi mumkinligini tekshiradi.
Javob
Faqat zarur maʼlumotlarni qaytaradi, ichki konfiguratsiya yoki sirlarni oshkor qilmaydi.
/health va /info oxirgi nuqtalarini ajrating
/health odatda jarayon yoki xizmat ishlayotganini qisqa bildiradi; orkestrator yoki monitor undan tayyorlik yoki qayta ishga tushirishni belgilashda foydalanishi mumkin. Kubernetesda muvaffaqiyatsiz liveness tekshiruvlari sozlangan chegaraga yetganda konteyner qayta ishga tushadi, readiness esa tayyor boʻlmagan podni Kubernetes Service orqali yoʻnaltiriladigan yangi trafikdan chiqaradi. Readiness podga barcha kirishni bloklaydigan tarmoq xavfsizligi qoidasi emas. /info ilova versiyasi va yigʻilma metamaʼlumotlarini koʻrsatishi mumkin. Bu nomlar standart xatti-harakatni kafolatlamaydi: mazmun, kirish darajasi va tarmoq qamrovini siz boshqarasiz. Ommaviy javoblarga sirlar, muhit oʻzgaruvchilari, ichki manzillar, komponentlarning aniq versiyalari va bogʻliqliklarning maxfiy holatini kiritmang; diagnostika tafsilotlarini kamaytiring va zarur joyda autentifikatsiya talab qiling.
Kuchli autentifikatsiya va obyekt darajasidagi vakolat tekshiruvi
Barcha API trafiki uchun HTTPS talab qiling. Foydalanuvchi yoki xizmat shaxsini mos mexanizm bilan tekshiring; tokenning amal muddati, auditoriyasi va doirasini cheklang, sirlarni versiya nazoratida saqlamang. Har bir soʻrovda server tomonida aynan shu obyekt va operatsiya uchun vakolatni qayta tekshiring: foydalanuvchini autentifikatsiyalash unga boshqa hisob yoki maʼmuriy funksiyaga kirish bermaydi. Xizmatlarga alohida identifikatorlar va eng kam zarur ruxsatlarni bering.
Kiritmalar va maʼlumotlar bazasi soʻrovlarini himoyalang
Qabul qilinadigan maydon va formatlar uchun aniq qoidalar bilan soʻrov hajmi, mazmun turi va sxemasini serverda tekshiring. Foydalanuvchi matnini biriktirib SQL tuzmang. Parametrli soʻrovlar qiymatlarni SQL kodidan ajratadi va SQL inʼeksiyasiga qarshi asosiy himoyadir. Kiritmani tekshirish qoʻshimcha qatlam sifatida foydali, ammo parametrlash oʻrnini bosmaydi. Baza hisobiga faqat zarur jadvallar va operatsiyalarni bering, batafsil xatolarni foydalanuvchilardan yashiring va parollarni mos, sekin hisoblanadigan, salt qoʻshilgan xesh bilan saqlang.
Resurs sarfini cheklang va oxirgi nuqtalarni sinang
Soʻrov chastotasi bilan birga sahifalash, xabar tanasi hajmi hamda qimmat qidiruv va eksport operatsiyalari sarfini cheklang. Autentifikatsiyadan oldingi va keyingi holatlar hamda har bir hisob yoki kalit sarfini hisobga oling; faqat IPga asoslangan limit taqsimlangan botlarni toʻxtatmasligi mumkin. Aniqlash uchun yetarli hodisalarni belgilangan saqlash va kirish siyosati asosida saqlagan holda shaxsiy maʼlumotlar, tokenlar va parollarni jurnallarga kiritmang. Notoʻgʻri tokenlar, boshqa foydalanuvchi obyekti IDsi, ortiqcha maydonlar, haddan katta yuklamalar, SQL sintaksisi va limitlar bajarilishini sinang. Javob kodlari, kechikish, xatolar va bloklash xatti-harakati kutilganga mosligini tasdiqlang.