حفاظت API با FortiWeb؛ نکات طراحی Policy برای JSON، Token و Rate Limit

حفاظت API با FortiWeb با محافظت یک سایت ساده فرق دارد. در API، مسیرها کوتاه‌ترند، payloadها اغلب JSON هستند، خطاها ممکن است برای کاربر نهایی دیده نشود، و یک false positive کوچک می‌تواند بخشی از اپلیکیشن موبایل یا پنل مشتری را از کار بیندازد. از طرف دیگر، API بدون کنترل WAF و rate limit می‌تواند نقطه فشار جدی برای brute force، scraping، abuse و حمله‌های لایه application باشد.

برای همین FortiWeb باید API را با شناخت رفتار واقعی سرویس ببیند، نه فقط با چند Signature عمومی. این مطلب روی طراحی عملی Policy تمرکز دارد؛ برای عیب‌یابی لاگ بعد از اجرا، مطلب عیب‌یابی FortiWeb با لاگ و Request مکمل همین مسیر است.

API Inventory را قبل از Policy بنویسید

اگر endpointها، methodها و نوع احراز هویت مشخص نباشد، Policy یا خیلی باز می‌شود یا مدام false positive می‌دهد. قبل از اینکه FortiWeb را روی حالت سخت‌گیرانه ببرید، برای هر سرویس حداقل این موارد را داشته باشید:

• دامنه و pathهای اصلی API، مثل /api/v1/orders یا /auth/login
• methodهای مجاز برای هر مسیر؛ GET، POST، PUT، PATCH یا DELETE
• نوع احراز هویت؛ cookie، bearer token، header اختصاصی یا mTLS
• حدود طبیعی اندازه request body و upload
• رفتار معمول خطا، retry و rate مصرفی کلاینت‌ها

host: api.example.com
endpoint: /api/v1/orders
methods: GET, POST
auth: Authorization: Bearer token
content-type: application/json
normal_body_size: under 128 KB
known_clients: mobile-app, partner-gateway
risk: order scraping, token abuse, injection in search fields

JSON را مثل form معمولی فرض نکنید

خیلی از خطاهای WAF در API از همین‌جا شروع می‌شود. برنامه ممکن است JSON nested، آرایه‌های بزرگ، فیلدهای اختیاری یا متن‌های چندزبانه ارسال کند. اگر FortiWeb بدون شناخت این الگوها سخت‌گیر شود، request سالم را به‌عنوان payload مشکوک می‌بیند. برعکس، اگر همه چیز آزاد باشد، WAF نقش چندانی در کنترل حمله ندارد.

برای هر endpoint مهم، فیلدهای حساس مثل search، comment، callback URL، redirect، upload و queryهای آزاد را جدا بررسی کنید. این فیلدها معمولاً هم از نظر امنیتی مهم‌اند، هم بیشتر باعث false positive می‌شوند.

Rate Limit را بر اساس رفتار واقعی تنظیم کنید

Rate limit خوب فقط یک عدد عمومی برای کل سایت نیست. login، search، دریافت لیست سفارش، دریافت فایل و API شریک تجاری رفتار متفاوت دارند. اگر همه را با یک سقف کنترل کنید، یا جلوی abuse گرفته نمی‌شود یا مشتری سالم ضربه می‌خورد.

• برای login و OTP سقف سخت‌گیرانه‌تر لازم است.
• برای endpointهای خواندنی پرترافیک، cache و رفتار کلاینت را در نظر بگیرید.
• برای partner API، IP یا token مشتری را در تحلیل جدا کنید.
• برای mobile app، retry خودکار و ضعف شبکه کاربر را لحاظ کنید.

Exceptionهای API باید تاریخ و مالک داشته باشند

در APIها exception بی‌نام خیلی سریع زیاد می‌شود. هر exception باید دلیل، مالک، endpoint، تاریخ بازبینی و معیار حذف داشته باشد. اگر توسعه‌دهنده می‌گوید یک payload خاص لازم است، بهتر است نمونه سالم، نمونه خطا و دلیل business آن ثبت شود. این کار جلوی انباشته شدن ruleهای موقت را می‌گیرد.

جمع‌بندی

FortiWeb برای API زمانی نتیجه می‌دهد که Policy از روی رفتار واقعی endpointها طراحی شود: method، JSON، token، rate، exception و لاگ. اگر API فقط پشت WAF قرار بگیرد اما inventory و tuning نداشته باشد، یا سرویس سالم را اذیت می‌کند یا حمله‌های مهم را درست جدا نمی‌کند.

منبع رسمی: برای بررسی قابلیت‌ها و جزئیات نسخه، مستندات Fortinet FortiWeb مرجع اصلی است.