REST API-ni necə qorumalı: praktik yoxlama siyahısı
API çox vaxt müasir tətbiqin ən açıq hissəsidir — o, tərifinə görə xarici dünyadan sorğular qəbul etmək üçün nəzərdə tutulub, bu isə o deməkdir ki, hücumçunun məlumatlarınıza və biznes məntiqinizə ən birbaşa yolu da məhz odur. API-ni düzgün qorumaq tək bir funksiya deyil; bu, ayrı-ayrı məsələlərdən ibarət yoxlama siyahısıdır və onların hər birini düşünülmüş şəkildə nəzərdən keçirməyə dəyər.
Autentifikasiya: sorğunu kimin göndərdiyini sübut etmək
Qorunan endpoint-ə gələn hər sorğu üçün onu kimin göndərdiyini etibarlı şəkildə müəyyən etmək lazımdır. Geniş yayılmış, sağlam yanaşmalara servislərarası əlaqə üçün API açarları və istifadəçiyə yönəlmiş tətbiqlər üçün token əsaslı autentifikasiya (məsələn, OAuth 2.0 və ya JWT) daxildir. Konkret mexanizm əsasları düzgün qurmaq qədər vacib deyil: tokenlərin müddəti bitməlidir, onlar yalnız şifrələnmiş bağlantılar üzərindən ötürülməlidir və heç vaxt URL-də görünməməlidir — orada onların təhlükəsiz olmayan hansısa loqa düşmə ehtimalı qat-qat yüksəkdir.
Avtorizasiya: nəyə icazə verildiyini yoxlamaq
Autentifikasiya «siz kimsiniz» sualına cavab verir. Avtorizasiya isə «sizə nə etməyə icazə verilir» sualına cavab verir və bu, yalnız girişdə bir dəfə deyil, hər bir sorğuda aparılmalı olan ayrıca yoxlamadır. Çox yayılmış və ağır nəticələr doğuran səhv belədir: API sorğuda etibarlı token olduğunu düzgün yoxlayır, lakin tələb olunan konkret resursun həqiqətən həmin istifadəçiyə məxsus olub-olmadığını heç vaxt yoxlamır. Məhz bu yolla bir istifadəçi sadəcə sorğudakı ID-ni dəyişməklə başqa istifadəçinin məlumatlarını görə və ya redaktə edə bilir — bu, real təhlükəsizlik auditlərində ən çox aşkarlanan problemlərdən biri olan pozulmuş giriş nəzarətinin (broken access control) bir növüdür.
Sorğuların məhdudlaşdırılması: sui-istifadədən və həddindən artıq yüklənmədən qorunma
Sorğuların məhdudlaşdırılması (rate limiting) olmadan tək bir müştəri — istər zərərli, istərsə də sadəcə səhv konfiqurasiya edilmiş — API-nizi sorğu selinə qərq edə bilər: ya giriş endpoint-i kimi bir şeyi kobud güclə (brute force) sındırmaq, ya da sadəcə infrastrukturunuzu həddindən artıq yükləmək üçün. Praktik məhdudlaşdırma hər istifadəçi və ya hər API açarı üçün ağlabatan limitlər təyin etmək, müştəri limitə çatdıqda aydın cavab qaytarmaq və giriş, parolun bərpası kimi həssas endpoint-lərə adi oxuma sorğularından daha sərt limitlər tətbiq etmək deməkdir.
Daxil edilən məlumatların yoxlanılması: gələnə heç vaxt etibar etməyin
Hər sorğudakı hər sahə tətbiq məntiqinizin hər hansı yerində istifadə olunmazdan əvvəl gözlənilən dəyərlərə — tipə, uzunluğa, formata, icazə verilən diapazona — uyğunluq baxımından yoxlanılmalıdır. Bu, SQL inyeksiyasının qarşısını alan prinsipin eynisidir, lakin onun tətbiq sahəsi qat-qat genişdir: real tətbiq zəifliklərinin böyük bir hissəsinin arxasında verilənlər bazası sorğularından xeyli kənara çıxan, səhv formatlı və ya gözlənilməz daxiletmələr dayanır.
Ötürmə təhlükəsizliyi: hər şeyi istisnasız şifrələyin
Hər sorğu və cavab HTTPS üzərindən ötürülməlidir və hətta risk baxımından aşağı görünən endpoint-lər üçün belə şifrələnməmiş ehtiyat variant ümumiyyətlə olmamalıdır. Müasir alətlər (məsələn, Let's Encrypt) bunu düzgün qurmağı demək olar ki, pulsuz edir, ona görə də API-nizin hər hansı hissəsində bundan imtina etmək üçün tutarlı bəhanə nadir hallarda tapılır.
Ağlabatan xəta mesajları
Ətraflı xəta mesajları proqramlaşdırma zamanı həqiqətən faydalıdır, canlı mühitdə (production) isə həqiqətən təhlükəlidir. Daxili fayl yollarını, verilənlər bazasının versiyasını və ya tam stack trace-i açan xəta hücumçuya real zəiflik axtarışında böyük üstünlük verir. Canlı mühitdəki xəta cavabları istifadə üçün kifayət qədər informativ olmalı, ondan artıq heç nə olmamalıdır.
Loqlaşdırma və monitorinq
Kimin nəyə və nə vaxt müraciət etdiyinin real qeydi sizə lazımdır — nəyisə ləngitmək üçün yox, nəsə səhv gedərsə, çiyin çəkmək əvəzinə araşdırmaq üçün əsl izin olması üçün. Qeyri-adi qanunauyğunluqları, məsələn, bir hesabın birdən-birə həddən artıq çox sorğu göndərməsini izləmək aktiv hücumu real insidentə çevrilməzdən əvvəl, erkən mərhələdə aşkar etməyə imkan verir.
Öz API-nizi yoxlamaq üçün siyahı
- Qəsdən ictimai edilmiş endpoint-lər istisna olmaqla, hər endpoint autentifikasiya tələb edirmi?
- Hər sorğuda istifadəçinin sadəcə sistemə daxil olduğu deyil, məhz həmin konkret resursa icazəsi olduğu yoxlanılırmı?
- Sorğuların məhdudlaşdırılması, xüsusən giriş, parolun bərpası və digər həssas endpoint-lərdə, tətbiq olunubmu?
- Daxil edilən hər məlumat — yalnız açıq-aşkar riskli görünənlər deyil — istifadədən əvvəl yoxlanılırmı?
- HTTPS hər yerdə, istisnasız məcburi edilibmi?
- Canlı mühitdəki xəta cavabları daxili reallaşdırma detallarını ifşa etmirmi?
- İnsidenti sonradan həqiqətən araşdırmaq üçün kifayət qədər loq yazılırmı?
Bu siyahı üzərində diqqətlə işləmək — mücərrəd şəkildə deyil, endpoint-bə-endpoint — Burncode-un müştərilər üçün infrastrukturun möhkəmləndirilməsi və real uyğunluq auditinə hazırlıqla yanaşı apardığı praktik tətbiq təhlükəsizliyi auditinin məhz özüdür.