API Təhlükəsizliyi: Sızmaların Qarşısını Necə Almaq Olar?

Mobil tətbiqiniz backend-lə necə danışır? Mikroservisləriniz bir-biri ilə necə əlaqə saxlayır? Tərəfdaş şirkətiniz sizin sistemə necə qoşulur? Bütün bu halların ortaq cavabı eynidir: API. Məhz buna görə də son illərdə ən çox hədəf alınan zəiflik nöqtəsi artıq vebsaytın özü deyil, onun arxasındakı API-lardır. Bir sorğu kifayət edir ki, düzgün qorunmayan bir endpoint vasitəsilə min istifadəçinin şəxsi məlumatı üzə çıxsın — və bu, nəzəri risk deyil, hər il yüzlərlə şirkətin başına gələn real ssenaridir.

Bu yazıda API-ların ən çox hədəf olduğu zəiflik nöqtələrini, real sızmaların necə baş verdiyini və komandanızın bu riskləri necə minimuma endirə biləcəyini praktiki şəkildə izah edəcəyik.

API Təhlükəsizliyi Nə Üçün Bu Qədər Vacibdir?

Əvvəllər bir tətbiqin bütün funksiyaları tək bir sistemin daxilində işləyirdi və xarici dünya ilə əlaqə məhdud idi. İndi isə Mikroservis arxitekturası, mobil tətbiqlər və üçüncü tərəf inteqrasiyaları sayəsində bir orta ölçülü layihə belə onlarla API endpoint-ə malikdir. Hər yeni endpoint isə potensial olaraq yeni bir hücum nöqtəsidir.

Fərq ondadır ki, vebsayt zəifliyi adətən bir səhifəni riskə atır, API zəifliyi isə birbaşa verilənlər bazasına, istifadəçi məlumatlarına və biznes məntiqinə çıxış aça bilər. Bu səbəbdən API təhlükəsizliyi artıq "əlavə" deyil, layihənin əsas hissəsi hesab olunmalıdır.

Ən Çox Rast Gəlinən API Zəiflikləri

OWASP təşkilatının API Security Top 10 hesabatına əsasən, əksər sızmalar bir neçə təkrarlanan səhvdən qaynaqlanır:

• Sınmış Obyekt Səviyyəli Avtorizasiya (BOLA): İstifadəçi URL-dəki ID-ni dəyişərək başqasının məlumatına çıxış əldə edir — məsələn, /api/order/1024 əvəzinə /api/order/1025 yazmaqla başqasının sifarişini görmək.
• Zəif Autentifikasiya: Token-lərin müddətinin bitməməsi, zəif parol siyasəti və ya API açarlarının kodun içində açıq saxlanılması.
• Həddindən Artıq Məlumat Açıqlanması: API cavab olaraq lazım olandan qat-qat çox məlumat qaytarır, frontend isə yalnız bir hissəsini göstərir — qalan hissə isə brauzer konsolunda hər kəsə açıqdır.
• Rate Limiting-in Olmaması: Bir istifadəçinin saniyədə minlərlə sorğu göndərməsinə heç bir məhdudiyyət qoyulmur, bu da həm brute-force hücumlarına, həm də server yükünün artmasına səbəb olur.
• Səhv Konfiqurasiya: Test mühiti üçün açılmış debug rejiminin production-da da aktiv qalması, lazımsız HTTP metodlarının açıq olması.
• Inyeksiya Hücumları: İstifadəçidən gələn məlumatın yoxlanılmadan birbaşa verilənlər bazası sorğusuna daxil edilməsi (SQL Injection).

API Açarları və Tokenlərin Düzgün İdarə Edilməsi

API açarı və ya token, sistemə "bu sorğunu göndərən etibarlı tərəfdir" deməyin yoludur. Amma bu açarlar düzgün idarə olunmasa, özləri ən böyük zəifliyə çevrilir. Ən çox rast gəlinən səhv — API açarının birbaşa kodun içində, hətta bəzən açıq Repository-də saxlanılmasıdır. Bu açarları .env fayllarında və ya xüsusi Secret Manager xidmətlərində saxlamaq, heç vaxt versiya nəzarəti sisteminə əlavə etməmək lazımdır.

JWT Token istifadə edən sistemlərdə isə tokenin ömrü mümkün qədər qısa saxlanılmalı, uzunmüddətli girişlər üçün isə ayrıca Refresh Token mexanizmi qurulmalıdır. Bu, hətta bir token oğurlansa belə, hücumçunun ondan uzun müddət istifadə edə bilməməsini təmin edir.

Rate Limiting: Sorğu Sayına Nəzarət

Rate Limiting — müəyyən vaxt aralığında bir istifadəçi və ya IP ünvanından qəbul edilə biləcək sorğu sayını məhdudlaşdırmaq deməkdir. Bu mexanizm olmadan bir hücumçu login endpoint-inə saniyədə minlərlə fərqli parol göndərərək hesabı asanlıqla sındıra bilər, yaxud sadəcə API-ı sorğularla boğaraq bütün sistemi işə yararsız hala gətirə bilər.

Praktiki həll: hər endpoint üçün məqbul sorğu limiti müəyyən edin, limiti aşan sorğulara "429 Too Many Requests" cavabı qaytarın və şübhəli aktivliyi real vaxtda izləyin.

HTTPS və Məlumatların Şifrələnməsi

API üzərindən ötürülən hər məlumat — istifadəçi adı, parol, token, şəxsi məlumat — mütləq HTTPS protokolu ilə şifrələnməlidir. Adi HTTP üzərindən göndərilən məlumat şəbəkədə "aralıq hücumu" (Man-in-the-Middle) vasitəsilə asanlıqla ələ keçirilə bilər. Bu, bu gün üçün minimum standartdır, amma təəssüf ki, hələ də bəzi daxili API-larda diqqətdən kənarda qalır.

Giriş Məlumatlarının Yoxlanılması

API-a gələn hər sorğu potensial təhlükə kimi qəbul edilməlidir. İstifadəçidən gələn heç bir məlumata "etibar etmə" prinsipi ilə yanaşmaq lazımdır — gözlənilən format, uzunluq və tip yoxlanılmadan heç bir dəyər birbaşa verilənlər bazası sorğusuna və ya sistem əmrinə ötürülməməlidir. Bu sadə addım, Inyeksiya hücumlarının böyük əksəriyyətinin qarşısını alır.

API Təhlükəsizliyi üçün Əsas Təcrübələr

• Ən Az Səlahiyyət Prinsipi: Hər token yalnız ehtiyacı olan əməliyyatlara icazə verməlidir, sistemin tamamına deyil.
• Versiyalaşdırma: API-ı /v1, /v2 formatında versiyalayın ki, köhnə, artıq təhlükəsiz olmayan versiyaları asanlıqla söndürə biləsiniz.
• Loglama və Monitorinq: Hər sorğunu qeyd edin ki, sızma baş verdikdə mənbəni tez tapa biləsiniz.
• Müntəzəm Təhlükəsizlik Testi: API-ları CI/CD Pipeline daxilində avtomatik skan edən alətlərlə mütəmadi yoxlayın.
• Sənədləşdirmə Nəzarəti: İstifadə olunmayan, unudulmuş "kölgə" endpoint-lərin sənədləşdirilməsini və vaxtaşırı auditini təmin edin.

CORS və Kim Sizin API-a Sorğu Göndərə Bilər?

CORS — hansı domenlərin brauzer üzərindən sizin API-a sorğu göndərə biləcəyini müəyyən edən mexanizmdir. Bir çox komanda inkişaf mərhələsində "hər şey işləsin" deyə bu qaydanı tamamilə açıq buraxır — yəni istənilən vebsaytın sizin API-ınıza sorğu göndərməsinə icazə verir. Layihə production-a keçdikdən sonra bu qayda daraldılmasa, hər hansı zərərli sayt öz istifadəçisinin brauzeri vasitəsilə sizin API-a sorğu göndərə, hətta müəyyən hallarda istifadəçinin adından əməliyyat apara bilər.

Düzgün yanaşma sadədir: yalnız real olaraq sizin API-a müraciət etməli olan domenləri ağ siyahıya (whitelist) əlavə edin, qalan hər şeyi rədd edin. "Icazə ver, sonra məhdudlaşdırarıq" məntiqi təhlükəsizlikdə həmişə tərsinə işləyir.

Sızma Baş Verdikdə: İlk Addımlar

Nə qədər diqqətli olsanız da, sızma riski heç vaxt sıfıra enmir — vacib olan ona hazır olmaqdır. Şübhəli aktivlik aşkarlandığı andan etibarən komanda üç şeyi paralel etməlidir: təhlükə altında olan token və API açarlarını dərhal ləğv etmək, hansı endpoint-lərin və hansı istifadəçi məlumatlarının təsirləndiyini logladan müəyyənləşdirmək, və zəifliyi bağlayan düzəlişi mümkün qədər tez, amma tələsik test edilmədən deyil, Deploy etmək.

Bu mərhələdə ünsiyyət də texniki addımlar qədər vacibdir. Əgər istifadəçi məlumatı risk altında olubsa, bunu gizlətmək əvəzinə şəffaf şəkildə bildirmək, uzunmüddətli etibarı qorumaq baxımından həmişə daha doğru seçimdir.

Ən Çox Buraxılan Səhvlər

Komandaların əksəriyyəti API təhlükəsizliyini "sonradan əlavə olunacaq funksiya" kimi görür — əvvəlcə API işə salınır, təhlükəsizlik isə "vaxt tapanda" düşünülür. Reallıqda isə autentifikasiya və avtorizasiya məntiqi ilk gündən arxitekturaya daxil edilməlidir, çünki sonradan əlavə etmək həm daha baha, həm də daha risklidir.

İkinci ən çox rast gəlinən səhv — daxili API-ların "kim onsuz da bilmir" deyə qorunmadan saxlanılmasıdır. Hər API, istifadəçi görsün-görməsin, ictimai internetə açıq olan hər endpoint kimi qorunmalıdır.

Tez-tez Verilən Suallar

API açarı sızarsa nə etmək lazımdır?
Açarı dərhal ləğv edin, yenisini yaradın və hansı sorğuların həmin açarla göndərildiyini loglardan yoxlayın ki, hansı məlumatın risk altında olduğunu müəyyən edəsiniz.

Kiçik layihələr üçün də API təhlükəsizliyi vacibdirmi?
Bəli. Hücumçular üçün layihənin ölçüsü fərq etmir — avtomatlaşdırılmış skanerlər internetdəki bütün açıq endpoint-ləri ölçüsündən asılı olmayaraq yoxlayır.

Rate Limiting istifadəçi təcrübəsinə mane olmurmu?
Düzgün qurulduqda, yox. Limit adi istifadəçinin heç vaxt çatmayacağı həddə qoyulur, yalnız anormal aktivliyi bloklayır.

API təhlükəsizliyini kim yoxlamalıdır: daxili komanda, yoxsa xarici mütəxəssis?
İdeal olaraq hər ikisi. Daxili komanda gündəlik nəzarəti aparır, müstəqil təhlükəsizlik auditi isə komandanın gözündən qaça biləcək boşluqları aşkar edir.

Daxili istifadə üçün olan API-ları da qorumaq lazımdırmı?
Bəli, mütləq. "Daxili" API çox vaxt yalnız şəbəkə səviyyəsində gizlədilir, amma konfiqurasiya səhvi və ya VPN-dəki bir boşluq onu asanlıqla xarici dünyaya açıq edə bilər. Ona görə də hər API, ictimai olub-olmamasından asılı olmayaraq, eyni ciddiliklə qorunmalıdır.

Nəticə

API-lar müasir proqram təminatının onurğa sütunudur — mobil tətbiqdən mikroservisə, tərəfdaş inteqrasiyasından ödəniş sisteminə qədər hər şey onların üzərindən keçir. Məhz buna görə də API təhlükəsizliyi son mərhələdə düşünülən əlavə deyil, ilk gündən layihənin arxitekturasına daxil edilməli olan əsas prinsipdir. Düzgün autentifikasiya, məhdudlaşdırılmış giriş, şifrələmə və müntəzəm monitorinq — bunların hamısı birlikdə sizi ən çox rast gəlinən sızmaların böyük əksəriyyətindən qoruyur.

Əgər mövcud API-larınızın nə dərəcədə qorunduğuna əmin deyilsinizsə, Crocusoft komandası ilə əlaqə saxlayaraq təhlükəsizlik qiymətləndirməsi ala bilərsiniz.