API security

Web application-da UI attacker ilə business logic arasında nazik bir pərdədir: düymələr gizlədilir, form-lar field-ləri məhdudlaşdırır, ekran yalnız lazım olanı göstərir. API-də bu pərdə yoxdur. Attacker birbaşa endpoint-lərlə danışır, istədiyi parametri göndərir, istədiyi ardıcıllıqla, istədiyi sürətlə. Mobil app, SPA, partnyor inteqrasiyası və daxili service-lər eyni API-ni çağırır, ona görə də API bu gün əsas attack surface-dir.

Bu fəslin əsas fikri sadədir: API-nin qəbul etdiyi hər request-i UI-dan gəlmiş kimi yox, curl ilə əl ilə yazılmış kimi düşünün. Çünki attacker məhz belə edir.

OWASP API Security Top 10

OWASP-ın 2023 siyahısı API-lərdə real olaraq tapılan problemləri ümumiləşdirir:

Diqqət edin: on riskdən üçü authorization-dur. SSRF və misconfiguration Fəsil 4-də ümumi formada əhatə olunub; aşağıda qalanlara API bucağından baxırıq.

Authorization üç səviyyədə

Fəsil 3-də BOLA-nı "təkrarlanmağa davam edən bug" adlandırdıq. API-də authorization üç ayrı sualdır və hər biri ayrıca unudula bilər.

Object səviyyəsi (API1). "Bu istifadəçi bu obyektə çata bilərmi?" Ardıcıl ID-ləri UUID ilə əvəz etmək bunu həll etmir. UUID təxmin edilməsi çətin olan identifier-dir, authorization deyil: o, log-larda, URL paylaşımlarında, başqa endpoint-lərin cavablarında leak olur. Check həmişə serverdə, hər request-də, obyektin owner-i və ya əlaqəsi ilə aparılmalıdır.

Property səviyyəsi (API3). Obyektə access-in olması onun bütün field-lərinə access demək deyil. Bu risk iki istiqamətdə işləyir:

• Excessive data exposure. Endpoint database obyektini olduğu kimi serialize edir və client-in "göstərmədiyi" field-ləri qaytarır: email, phone, password_hash, daxili flag-lar. UI onları göstərmir, amma response-da var.
• Mass assignment. Endpoint request body-ni birbaşa obyektə bind edir və istifadəçi gözlənilməyən field əlavə edir:

PATCH /api/users/me
Content-Type: application/json

{ "display_name": "Aysel", "role": "admin", "credit_balance": 99999 }

Həll hər iki istiqamətdə açıq allowlist-dir: hər endpoint üçün oxuna bilən və yazıla bilən field-lərin ayrıca DTO və ya schema-sı. Database modelini birbaşa API contract-ına çevirməyin.

Function səviyyəsi (API5). "Bu istifadəçi bu əməliyyatı edə bilərmi?" GET /api/users hər kəs üçün işləyir, DELETE /api/users/42 isə yalnız admin üçün olmalıdır. Klassik səhvlər: admin endpoint-lərinin ayrıca prefix-də (/api/admin/...) olub check-siz qalması, HTTP method-u dəyişməklə (GET əvəzinə PUT) check-in bypass olunması, "UI-da düymə yoxdur" fərziyyəsi. Default deny burada da qaydadır: role və ya permission tələbi olmayan endpoint deploy olunmamalıdır.

API-lər üçün authentication

API client-ləri brauzer deyil, ona görə authentication mexanizmi də fərqlidir.

API key-lər client-i, yəni application-ı identify edir, istifadəçini yox. Onlar uzunömürlüdür, adətən scope-suzdur və mobil app-lərdə, frontend kodunda, public repository-lərdə asanlıqla leak olur. API key-ə quota və usage tracking üçün baxın, authorization qərarının əsası kimi yox.

OAuth 2.0 access token-ləri (Fəsil 3) istifadəçinin adından məhdud scope ilə verilir, qısaömürlüdür və revoke edilə bilir. İstifadəçi data-sına toxunan API-lər üçün düzgün seçim budur.

Token-i qəbul edən hər API Fəsil 3-dəki cədvəldə sadalanan beş yoxlamanı özü aparır: signature, exp/nbf, iss, aud və scope. Gateway token-i artıq yoxlayıbsa belə, backend service aud və scope-u yenidən yoxlamalıdır. Əks halda gateway-dən yan keçən daxili request heç bir check-dən keçmir. İki əlavə API qaydası:

• Token heç vaxt URL query parametrində göndərilmir; o, log-lara və Referer header-inə düşür.
• API key, HMAC signature və reset token kimi secret-lər constant-time funksiya ilə müqayisə olunur, çünki adi müqayisə timing attack-ə açıqdır (Fəsil 3).

Resource consumption və business flow-lar

Software Architecture kitabının 8-ci və 11-ci fəsillərində rate limiting və pagination reliability bucağından izah olunub. Security bucağı budur: limit olmayan hər yer attacker üçün pul, CPU və ya data çıxarmaq kanalıdır (API4).

• Ölçü limitləri: request body, upload faylı, array uzunluğu, string uzunluğu.
• Pagination cap-ləri: ?limit=1000000 server tərəfindən maksimuma endirilir. Əks halda bir request bütün cədvəli dump edir.
• Query mürəkkəbliyi: GraphQL-də depth və complexity limitləri, batch query-lərdə əməliyyat sayı limiti.
• Xərc kvotaları: SMS, email, ödəniş və ya LLM çağırışı edən endpoint-lər hər çağırışda real pul xərcləyir. Onlara istifadəçi və tenant üzrə gündəlik kvota qoyun.

API6 daha incədir: burada heç bir bug yoxdur, flow düzgün işləyir, sadəcə miqyasda abuse olunur. Bot-lar konsert biletlərini saniyələr içində alıb yenidən satır (ticket scalping), endpoint OTP SMS-lərini kiminsə nömrəsinə yağdırmaq üçün istifadə olunur, referral bonusları minlərlə saxta account ilə toplanır. Burada IP üzrə rate limit kifayət etmir. Hansı flow-ların biznes üçün həssas olduğunu threat model-də (Fəsil 2) müəyyən edin və onlara device fingerprinting, account yaşı, CAPTCHA və ya addım-addım verification kimi xüsusi control-lar tətbiq edin.

Inventory və versioning

Bilmədiyiniz API-ni qoruya bilməzsiniz (API9). İki tipik problem:

• Shadow API-lər: heç bir inventarda və sənəddə olmayan endpoint-lər. Debug üçün açılıb qalmış route, komandanın gateway-dən yan keçib birbaşa expose etdiyi service.
• Zombie API-lər: "deprecate olunmuş", amma hələ də işləyən köhnə versiyalar. /v2/users düzgün authorization-a malikdir, /v1/users isə iki il əvvəlki kodla hələ də cavab verir.

Versioning strategiyası Software Architecture kitabının 8-ci fəslində izah olunub. Security qaydası isə budur: hər işləyən versiya eyni authentication, authorization və monitoring control-larına malik olmalıdır, və ya söndürülməlidir. İnventarı sənədlərdən yox, real trafikdən qurun: gateway log-ları, OpenAPI spec-ləri və production-da həqiqətən cavab verən route-ların müqayisəsi shadow endpoint-ləri üzə çıxarır.

Third-party API-ləri consume etmək

Developer-lər istifadəçi input-una şübhə ilə yanaşır, amma tanınmış partnyorun API cavabına kor-koranə etibar edirlər (API10). Third-party compromise oluna, səhv cavab qaytara və ya attacker-in nəzarət etdiyi data-nı ötürə bilər.

• Cavabı schema ilə validate edin, istifadəçi input-u kimi. Oradan gələn string SQL query-yə və ya HTML-ə düşürsə, injection eyni şəkildə işləyir.
• Redirect-ləri avtomatik izləməyin; bu, SSRF-ə qapı açır.
• Timeout və cavab ölçüsü limiti qoyun.
• Yalnız TLS üzərindən, certificate validation ilə çağırın.
• Partnyorun credential-larını secret kimi saxlayın və scope-unu məhdudlaşdırın (Fəsil 4).

CORS: nədir və nə deyil

CORS brauzerin same-origin policy-sini kontrollu şəkildə yumşaldan mexanizmdir: server brauzerə "bu origin-dən gələn JavaScript mənim cavabımı oxuya bilər" deyir. CORS authentication və ya authorization mexanizmi deyil. curl, server-side script və ya mobil app CORS-a məhəl qoymur; o yalnız brauzerdəki digər saytları məhdudlaşdırır.

Təhlükəli konfiqurasiya request-in Origin header-ini olduğu kimi geri qaytarıb credential-lara icazə verməkdir:

Access-Control-Allow-Origin: https://evil.example
Access-Control-Allow-Credentials: true

Bu halda istifadəçinin daxil olduğu hər hansı saytdakı script onun cookie-ləri ilə API-ni çağırıb cavabı oxuya bilər. Həll: origin-lərin dəqiq allowlist-i, null origin-ə icazə verməmək, regex ilə subdomain match-ində diqqətli olmaq (evil-example.com də example.com ilə bitir).

API-ləri test etmək

API security testing hər endpoint üçün təkrarlanan sual dəstidir:

• Authorization matrisi: hər endpoint-i fərqli role-lar və fərqli owner-lər ilə çağırın. A istifadəçisinin token-i ilə B-nin obyektini istəyən test CI-də işləməlidir.
• Schema validation: OpenAPI və ya GraphQL schema-sı contract-dır. Gözlənilməyən field-lər, tiplər və ölçülər boundary-də rədd edilir; həm request, həm response schema-ya qarşı yoxlanılır.
• Negativ test-lər: token-siz, expire olmuş token ilə, başqa aud ilə, artıq field ilə, limitdən böyük payload ilə.
• Fuzzing və DAST: spec-dən avtomatik generate olunan request-lər manual test-in görmədiyi kənar halları tapır.

Yeni endpoint üçün threat model qısa ola bilər: kim çağırır, hansı obyektə toxunur, hansı field-ləri qaytarır və dəyişir, abuse olunarsa xərci nədir.

Monitoring və incident response

Fəsil 5-dəki log kateqoriyalarına API-yə xas siqnallar əlavə olunur:

• Enumeration pattern-ləri: bir client-in ardıcıl ID-lər üzrə yüzlərlə fərqli obyekt istəməsi.
• 403 və 404 spike-ları: authorization check-lərinə vuran attacker çoxlu rədd edilmiş request yaradır.
• Cavab ölçüsündə anomaliyalar: adi 2 KB-lıq cavab əvəzinə megabayt-larla data, scraping və ya pagination abuse-unu göstərir.
• Deprecate olunmuş versiyalara trafik və ya inventarda olmayan route-lara request-lər.
• Bir token-in qeyri-adi coğrafiyalardan və ya qeyri-adi sürətlə istifadəsi.

API breach-ində ilk addımlar konkretdir: təsirlənmiş token-ləri və API key-ləri revoke edin, vulnerable endpoint-i söndürün və ya gateway-də bloklayın, sonra access log-lardan hansı obyektlərin oxunduğunu müəyyən edin. Bu sonuncu addım yalnız log-larda istifadəçi və obyekt ID-ləri varsa mümkündür, ona görə onları bu gün log etməyə başlayın.

Tapşırıqlar

1. Ən çox istifadə olunan beş endpoint-inizi götürün və hər biri üçün üç authorization səviyyəsini yoxlayın: object, property, function. Hansı check kodda açıq şəkildə görünmür?
2. Production gateway log-larındakı unikal route-ların siyahısını OpenAPI spec-inizlə müqayisə edin. Sənəddə olmayan neçə endpoint tapdınız? Neçə köhnə versiya hələ də trafik alır?
3. Pul xərcləyən bir flow seçin (SMS, ödəniş, bilet sifarişi) və onu bir saat ərzində script ilə min dəfə çağıran attacker-i təsəvvür edin. Hansı control onu dayandırar və bunu kim fərq edər?