API باید برای هر درخواست بررسی کند کاربر اجازهٔ دسترسی به همان داده و انجام همان عملیات را دارد. برای نمونه، ورود موفق به حساب کاربری مجوز خواندن فاکتور حساب دیگری را ایجاد نمی‌کند. وقتی کاربر شناسهٔ فاکتور را در آدرس می‌فرستد، مالکیت یا مجوز سازمانی را سمت سرور بررسی کنید.
دسترسی را از شیء شروع کنید
فرض کنید مسیر GET /invoices/:id فاکتور را با شناسه می‌خواند. بررسی کنید فاکتور به سازمان کاربر تعلق دارد و نقش کاربر اجازهٔ مشاهده دارد. در پروژهٔ چندسازمانی، شناسهٔ سازمان را از هویت تأییدشده به دست آورید. برای عملیات ویرایش، مجوز و فهرست فیلدهای قابل تغییر را جداگانه بررسی کنید. تغییر وضعیت مالی یا مالکیت نباید از طریق پذیرش همهٔ فیلدهای ورودی ممکن شود.
سه حساب آزمایشی برای پیدا کردن خطا
| حساب | درخواست | نتیجهٔ مورد انتظار |
|---|---|---|
| عضو سازمان اول | خواندن فاکتور مجاز سازمان خود | پاسخ مجاز |
| عضو سازمان دوم | خواندن همان فاکتور با شناسهٔ مستقیم | پاسخ مطابق سیاست عدم دسترسی |
| کاربر فقط‌خواندنی | ویرایش فاکتور مجاز برای مشاهده | درخواست رد می‌شود و داده تغییر نمی‌کند |
در تست، علاوه بر کد پاسخ وضعیت داده را دوباره بخوانید. اگر درخواست ویرایش رد شد، مقدار قبلی باید باقی بماند. درخواست‌های دسته‌ای، فایل دانلود و گزارش خروجی را هم با همان منطق بررسی کنید. گاهی صفحهٔ اصلی دسترسی را درست کنترل میکند ولی لینک خروجی فایل بررسی جداگانه ندارد.
کنترل‌های تکمیلی برای محیط واقعی
اعتبارسنجی ورودی، محدودیت حجم و نرخ درخواست، ثبت رخداد بدون دادهٔ حساس و جداسازی دسترسی حساب‌های خدماتی را در نظر بگیرید. خطاهای مشکوک را همراه شناسهٔ درخواست و شناسهٔ سازمان ثبت کنید تا بررسی ممکن باشد. در بازبینی دوره‌ای، مسیرهای قدیمی و نسخه‌های API را هم پیدا کنید. طراحی تست واحد و یکپارچه · راهنمای امنیت API از OWASP