امنیت API؛ احراز هویت با کنترل دسترسی فرق دارد

کاربر سفارش شمارهٔ ۴۲ را می‌بیند. اگر شناسه را به ۴۳ تغییر دهد آیا سفارش فرد دیگری را می‌گیرد؟ اگر بله، JWT معتبر جلوی مشکل را نگرفته است. کنترل دسترسی به شیء یا BOLA ناقص است.

شناسهٔ تصادفی حدس زدن را دشوار می‌کند، اما جای مجوزدهی را نمی‌گیرد. شناسه ممکن است از لینک یا بخش دیگری معلوم شود. هر مسیر خواندن و تغییر منبع باید همان قاعدهٔ مالکیت را اجرا کند.

// مثال آموزشی؛ API واقعی به چارچوب بستگی دارد.
const order = await orders.findOne({
  id: orderId, userId: currentUser.id
});
if (!order) throw new NotFoundError();
return { id: order.id, status: order.status };

در سامانهٔ چندمستاجری، سازمان و نقش هم مهم‌اند. دسترسی به صفحهٔ مدیریت هم کافی نیست؛ endpoint باید مجوز مدیریتی را خودش بررسی کند. سیاست بهتر است متمرکز و قابل‌آزمایش باشد تا مسیرهای جدید قاعده را فراموش نکنند.

بدنهٔ درخواست را مستقیم در مدل کاربر ذخیره نکنید. کاربر ممکن است نقش یا مالک منبع را بفرستد. فهرست فیلدهای قابل‌ویرایش را صریح تعیین کنید. قیمت، مالکیت و وضعیت پرداخت باید از منبع معتبر سمت سرور بیاید.

• کاربر الف منبع خودش را می‌خواند: مجاز.
• کاربر ب همان شناسه را می‌فرستد: رد.
• ناشناس درخواست می‌دهد: رد.
• کاربر نقش یا مالک را در ورودی می‌فرستد: رد یا نادیده گرفته شود.
• پس از لغو مجوز، دریافت فایل دوباره بررسی شود.

فقط توکن خراب را آزمایش نکنید. توکن معتبر کاربر دیگر برای آزمون مجوزدهی ضروری است. URL مستقیم فایل هم نباید کنترل endpoint را دور بزند.

یک API یادداشت با مالک بسازید. کاربر دوم نباید یادداشت اول را بخواند، ویرایش یا حذف کند. همین قاعده را به نتایج جست‌وجو و پیوست‌ها گسترش دهید. برای هر مسیر تست مستقل نگه دارید؛ یک endpoint امن تضمین نمی‌کند همهٔ مسیرهای جانبی هم امن هستند.

در بازبینی خروجی هم به اطلاعات اضافی توجه کنید. پاسخ عمومی لازم نیست ایمیل، شماره، توکن یا شناسه‌های داخلی غیرضروری را برگرداند. هر فیلد باید دلیل کاربردی مشخصی داشته باشد.