API xavfsizligi: OWASP API Security Top 10 bo'yicha amaliy qo'llanma

Bugungi veb-sayt ko'pincha faqat "frontend" emas. Brauzerdagi React yoki Vue ilovasi, mobil ilova, hamkorlar tizimi — barchasi bitta API bilan gaplashadi. Foydalanuvchi interfeysda faqat o'ziga ruxsat berilgan tugmalarni ko'radi, lekin API'ga to'g'ridan-to'g'ri so'rov yuborish uchun hech qanday tugma kerak emas: curl yoki proksi vositasi yetarli. Shuning uchun API xavfsizligi interfeysdagi cheklovlarga emas, serverdagi tekshiruvlarga tayanishi kerak.

OWASP bu sohaga alohida ro'yxat ajratgan — OWASP API Security Top 10 (2023). Bu maqolada har bir bandni qisqa tushuntiramiz, uni o'z tizimingizda qanday tekshirish mumkinligini va Laravel hamda Node (Express) misolida qanday tuzatishni ko'rsatamiz.

Nima uchun bu ekspertiza uchun muhim

Rasmiy kiberxavfsizlik ekspertizasida mutaxassislar ilovani nafaqat brauzer orqali, balki API darajasida ham sinaydi: so'rovlarni ushlab olib, identifikatorlarni almashtirib, qo'shimcha maydonlar qo'shib, tokensiz yoki boshqa foydalanuvchi tokeni bilan qayta yuborib ko'radi. Mobil ilova ekspertizasida esa ilova ichidan API manzillari ajratib olinadi va backend alohida tekshiriladi. Ya'ni API'dagi xato veb hisobotida ham, mobil hisobotda ham chiqishi mumkin.

O'z mahsulotimiz — soliq-moliya SaaS platformasi — ekspertizasida topilgan topilmalarning bir qismi aynan shu sinfga tegishli edi: kerakli holat tekshiruvisiz bajarilishi mumkin bo'lgan amallar (biznes mantiq xatosi) va javoblarda ortiqcha ma'lumot qaytishi (ma'lumot ochiqlanishi).

API1: Broken Object Level Authorization (BOLA)

Ro'yxatdagi birinchi va eng keng tarqalgan muammo. API obyektni identifikator bo'yicha qaytaradi, lekin bu obyekt so'rov yuborgan foydalanuvchiga tegishli ekanini tekshirmaydi. Veb-ilovalarda bu IDOR nomi bilan ma'lum — batafsil alohida maqolada yozganmiz.

Tekshirish: ikki test akkaunt oching (A va B). A akkaunti bilan o'z obyektini oling, keyin B tokeni bilan xuddi shu ID'ni so'rang:

curl -s https://api.your-domain.uz/v1/invoices/1042 \
  -H "Authorization: Bearer <B_TOKEN>"

Javob 403 yoki 404 bo'lishi kerak, A ning ma'lumoti emas. Faqat GET emas, PUT, PATCH, DELETE va fayl yuklab olish endpointlarini ham sinang.

Laravel'da tuzatish — har bir obyekt uchun policy yoki so'rovni egasi bo'yicha cheklash:

public function show(Invoice $invoice)
{
    $this->authorize('view', $invoice);
    return new InvoiceResource($invoice);
}

// yoki so'rovning o'zini cheklash
$invoice = $request->user()->invoices()->findOrFail($id);

Node/Express'da ham xuddi shu tamoyil: ID bo'yicha emas, "ID + egasi" bo'yicha qidiring.

const invoice = await db.invoice.findFirst({
  where: { id: req.params.id, ownerId: req.user.id },
});
if (!invoice) return res.sendStatus(404);

API2: Broken Authentication

Autentifikatsiya mexanizmidagi xatolar: parolni cheksiz sinash imkoni, tokenlarning muddatsizligi, zaif imzolangan tokenlar, parolni tiklash oqimidagi kamchiliklar. Login sahifasini himoyalash haqida bu yerda, token xatolari haqida esa JWT maqolasida batafsil yozganmiz.

Tekshirish uchun savollar:

• /login, /password/reset, /otp/verify endpointlarida urinishlar soni cheklanganmi?
• Token muddati bormi va logout'dan keyin token haqiqatan bekor bo'ladimi?
• Mobil API'da "eski versiya" uchun qoldirilgan, himoyasiz login yo'li yo'qmi?

API3: Broken Object Property Level Authorization

Bu band ikki eski muammoni birlashtiradi: ortiqcha ma'lumot qaytarish va mass assignment. Birinchisida API butun model obyektini qaytaradi va frontend kerakli maydonlarni o'zi tanlaydi — javobda esa parol xeshi, ichki izohlar yoki boshqa foydalanuvchilarning telefon raqamlari qoladi. Ikkinchisida API kelgan JSON'ni to'g'ridan-to'g'ri modelga yozadi va foydalanuvchi "role": "admin" yoki "balance": 999999 qo'shib yuborishi mumkin.

Tekshirish: brauzer DevTools'da yoki proksida javoblarni ko'ring — interfeysda ko'rinmaydigan maydonlar bormi? Profilni yangilash so'roviga qo'shimcha maydon qo'shib ko'ring:

curl -s -X PATCH https://api.your-domain.uz/v1/profile \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"name":"Test","is_admin":true,"role":"admin"}'

Keyin profilni qayta o'qing: rol o'zgarganmi?

Laravel'da tuzatish — javob uchun API Resource, kirish uchun validatsiya qilingan ma'lumot:

// faqat ruxsat etilgan maydonlar yoziladi
$user->update($request->validated());

class UserResource extends JsonResource
{
    public function toArray($request): array
    {
        return ['id' => $this->id, 'name' => $this->name];
    }
}

Modelda $guarded = [] ishlatmang, $fillable ro'yxatini aniq yozing. Node'da ham req.body ni to'g'ridan-to'g'ri update() ga bermang: zod yoki joi kabi sxema bilan faqat kerakli maydonlarni ajrating.

API4: Unrestricted Resource Consumption

API bitta so'rovda qancha resurs sarflashi cheklanmagan: sahifalashsiz ro'yxat, ?limit=1000000, juda katta fayl yuklash, cheksiz SMS yoki email yuborish. Natijada server sekinlashadi yoki pullik xizmatlar (SMS shlyuzi) uchun hisob oshib ketadi.

Laravel'da throttle middleware va sahifalash chegarasi:

RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});

$perPage = min((int) $request->query('per_page', 20), 100);

Express'da express-rate-limit paketi va express.json({ limit: '100kb' }) kabi tana hajmi chegarasi. Veb-server darajasida ham client_max_body_size va limit_req qo'yish mumkin — nginx maqolasida ko'rsatganmiz.

API5: Broken Function Level Authorization

BOLA obyektga tegishli bo'lsa, bu band funksiyaga tegishli: oddiy foydalanuvchi admin endpointini chaqira oladi. Ko'pincha admin yo'llari faqat interfeysda yashirilgan bo'ladi, serverda esa rol tekshirilmaydi.

Tekshirish: frontend JavaScript fayllarida yoki mobil ilovada /admin, /internal, /manage kabi yo'llarni qidiring va oddiy foydalanuvchi tokeni bilan chaqiring. GET ruxsat etilgan joyda DELETE usulini ham sinang.

Laravel'da admin yo'llarini guruhga olib, middleware yoki Gate bilan himoyalang:

Route::middleware(['auth:sanctum', 'can:admin'])
    ->prefix('admin')
    ->group(function () { /* ... */ });

API6: Unrestricted Access to Sensitive Business Flows

Texnik jihatdan hamma narsa to'g'ri, lekin biznes jarayonni avtomatlashtirib suiiste'mol qilish mumkin: promo-kodlarni ommaviy olish, cheklangan tovarni bot bilan sotib olish, ro'yxatdan o'tishni avtomatlashtirish. Bu yerda yechim kontekstga bog'liq: foydalanuvchi va qurilma bo'yicha limit, harakatlar ketma-ketligini serverda tekshirish, shubhali faollikni kuzatish.

Shu bandga yaqin muammo bizning ekspertizada ham chiqqan: to'lov provayderi tasdiqlamasdan turib "muvaffaqiyatli to'lov" sahifasi ko'rsatilgan edi. Bu haqda alohida maqola bor. Asosiy qoida: holat o'zgarishini (to'langan, tasdiqlangan, yuborilgan) faqat server tekshiruvidan keyin qabul qiling.

API7: Server Side Request Forgery (SSRF)

API foydalanuvchi bergan URL bo'yicha so'rov yuborsa (rasm import, webhook, havola oldindan ko'rish), hujumchi server orqali ichki tarmoqqa yoki bulut metadata xizmatiga murojaat qilishi mumkin. Himoya: ruxsat etilgan domenlar ro'yxati, ichki IP diapazonlarini bloklash, redirect'larni cheklash.

API8: Security Misconfiguration

Noto'g'ri sozlamalar: production'da debug rejimi, stack trace qaytaruvchi xatolar, ruxsat berilmagan HTTP usullari, xavfsizlik headerlarining yo'qligi, noto'g'ri CORS. Bularning har biri haqida alohida yozganmiz: debug rejimi, xavfsizlik headerlari, CORS.

Tez tekshiruv — mavjud bo'lmagan endpointga va noto'g'ri JSON bilan so'rov yuboring:

curl -s https://api.your-domain.uz/v1/nonexistent
curl -s -X POST https://api.your-domain.uz/v1/login \
  -H "Content-Type: application/json" -d '{bad json'

Javobda fayl yo'llari, SQL so'rovlari yoki framework versiyasi bo'lmasligi kerak.

API9: Improper Inventory Management

Siz qaysi API'larni ishlatayotganingizni bilasizmi? Ko'pincha v1 yangilanadi, v0 esa eski mobil ilovalar uchun qoldiriladi va unutiladi. Yoki staging.api subdomeni production ma'lumotlari bilan ochiq turadi. Ekspertiza bunday "unutilgan" eshiklarni topishi mumkin.

Bizning tajribamizda shu bandga yaqin topilma bo'lgan: brauzerga ilovaning barcha marshrutlari ro'yxati yuborilardi. Bu hujumchiga API xaritasini tayyor holda beradi. Laravel'da Ziggy ishlatsangiz, faqat kerakli marshrutlarni chiqaring:

// config/ziggy.php
return [
    'only' => ['dashboard', 'invoices.*', 'profile.*'],
];

Amaliy qadamlar: barcha API versiyalari va hostlarini ro'yxatga oling, ishlatilmayotganlarini o'chiring, Swagger/OpenAPI hujjatini production'da ochiq qoldirmang yoki autentifikatsiya orqasiga qo'ying.

API10: Unsafe Consumption of APIs

Sizning API'ingiz boshqa API'lardan (to'lov tizimi, davlat xizmatlari, xarita) ma'lumot oladi. Agar tashqi javobga ko'r-ko'rona ishonsangiz — tekshirmasdan bazaga yozsangiz yoki sahifada ko'rsatsangiz — tashqi tizimdagi muammo sizga o'tadi. Tashqi javoblarni ham validatsiya qiling, faqat HTTPS orqali ulaning, vaqt chegarasi (timeout) qo'ying va redirect'larga avtomatik ergashmang.

Laravel HTTP klientida:

$response = Http::timeout(10)
    ->withOptions(['allow_redirects' => false])
    ->get('https://partner.example/api/status');

$data = validator($response->json(), [
    'status' => 'required|in:paid,pending,failed',
])->validate();

O'zingiz tekshirish uchun qisqa reja

1. Barcha API endpointlari ro'yxatini tuzing (php artisan route:list --path=api yoki Express router'lari).
2. Ikki test akkaunt va bitta admin akkaunt tayyorlang.
3. Har bir endpointni tokensiz, boshqa foydalanuvchi tokeni bilan va oddiy foydalanuvchi tokeni bilan admin funksiyasiga chaqiring.
4. Yozish endpointlariga qo'shimcha maydonlar yuboring.
5. Javoblarni interfeysda ko'rinadigan ma'lumot bilan solishtiring.
6. Login, OTP va SMS endpointlarida tezlik cheklovini sinang.
7. Natijalarni jadvalga yozing va har bir topilmani tuzatgandan keyin qayta sinang.

Bu ishni faqat o'zingizga tegishli tizimda va test ma'lumotlarida bajaring.

API'da xavfsizlik chegarasi — server. Interfeysda yashirilgan tugma himoya emas.

Checklist

• Har bir obyekt endpointida egalik tekshiruvi (policy yoki so'rov cheklovi) bor.
• Admin va ichki funksiyalar serverda rol bo'yicha himoyalangan.
• Javoblar API Resource yoki DTO orqali, faqat kerakli maydonlar bilan qaytadi.
• Yozish so'rovlarida faqat validatsiyadan o'tgan maydonlar qabul qilinadi.
• Login, OTP, SMS va og'ir endpointlarda tezlik cheklovi va sahifalash chegarasi bor.
• Debug o'chirilgan, xatolar umumiy xabar bilan qaytadi.
• Eski API versiyalari, test hostlari va ochiq hujjatlar inventarizatsiya qilingan.
• Tashqi API javoblari validatsiya qilinadi, timeout qo'yilgan.

Xulosa

OWASP API Top 10 — bu nazariya emas, ekspertizada sinab ko'riladigan aniq savollar ro'yxati. Ularning ko'pchiligi bir qoidaga tushadi: har bir so'rovda "bu foydalanuvchi bu obyekt bilan, bu amalni, shu hajmda bajarishga haqlimi?" degan savolga server javob berishi kerak.

API'ingizni ekspertizadan oldin shu ro'yxat bo'yicha ko'rib chiqmoqchimisiz? Skanerlash uchun ariza qoldiring — Claude AI agenti endpointlar va kodni tez ko'rib chiqadi, mutaxassisimiz topilmalarni tasdiqlab, teshiklarni yopishga yordam beradi.