امنیت API؛ کلید، دسترسی سطح رکورد و محدودیت نرخ

امنیت API معمولاً به‌شکل فهرستی از تهدیدها نوشته می‌شود که خواندنش کسی را امن‌تر نمی‌کند. این راهنما برعکس است: چهار لایه‌ای که واقعاً جلوی حادثه را می‌گیرند، به‌ترتیب اهمیت — و از اشتباهی شروع می‌کند که بیش از همه‌ی بقیه با هم اتفاق می‌افتد و همیشه هم دیر معلوم می‌شود.

اشتباه شماره یک: کلید داخل کلاینت

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

پس تفکیک اول این است:

• کلید سروری فقط جایی می‌رود که کاربر به آن دسترسی ندارد: سرور خودتان یا لایه‌ی میانی.
• کلید عمومی فقط برای داده‌ای است که ذاتاً عمومی است — کاتالوگ محصول، فهرست خدمت‌ها.
• توکن کاربر چیزی است که در اپ می‌نشیند، و مال یک کاربر است نه کل پروژه.

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

لایه‌ی دوم: هر کاربر فقط داده‌ی خودش

کلید معتبر یعنی «این برنامه اجازه دارد حرف بزند»، نه «این آدم اجازه دارد این رکورد را ببیند». این دو را قاطی کردن، منشأ رایج‌ترین نشتی داده در اپ‌های موبایل است: اپی که همه‌ی سفارش‌ها را می‌گیرد و در کلاینت فیلتر می‌کند تا فقط مال کاربر را نشان دهد. داده‌ی بقیه واقعاً روی دستگاه آن کاربر رفته است — کافی است کسی به‌جای اپ، خود درخواست را ببیند.

راه درست، دسترسی سطح رکورد سمت سرور است: کاربر واردشده اصلاً رکورد دیگری دریافت نمی‌کند. سه سطح که باید از هم جدا بمانند:

جزئیات ساخت این سطوح بدون کد در احراز هویت کاربران با JWT و مستندات احراز هویت آمده است.

لایه‌ی سوم: اعتبارسنجی ورودی

هر چیزی که از کلاینت می‌آید، ادعاست نه واقعیت. سه مورد که همیشه باید سمت سرور بررسی شوند:

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

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

لایه‌ی چهارم: محدودیت نرخ و دیدن ترافیک

محدودیت نرخ فقط ضد حمله نیست؛ بیشتر وقت‌ها جلوی حلقه‌ی معیوب کلاینت خودتان را می‌گیرد — همان کدی که در حالت خطا بی‌وقفه دوباره تلاش می‌کند. در فیکارو محدودیت نرخ بخشی از سرویس است و سقفش به پلن پروژه بستگی دارد؛ کلید پلی‌گراند سخت‌گیرانه‌تر محدود شده تا آزمایش، سهمیه‌ی واقعی را نخورد.

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

چک‌لیست کوتاه قبل از انتشار

1. هیچ کلید سروری داخل اپ یا مخزن نیست
2. هر موجودیت سطح دسترسی صریح دارد — «فعلاً باز بماند» یعنی باز می‌ماند
3. فیلدهای حساس از ورودی کاربر پذیرفته نمی‌شوند
4. کلیدی که جایی نشت کرده، باطل شده نه پاک
5. کلید پلی‌گراند و پروداکشن قاطی نشده‌اند
6. HTTPS همه‌جا — و هیچ توکنی در آدرس صفحه (query string) نمی‌رود

اگر تازه در حال ساخت API هستید، ساخت API بدون کدنویسی مسیر کامل را دارد و مستندات کار با API قالب خطاها و فیلترها را.

سوالات متداول

کلید API را می‌شود داخل اپلیکیشن موبایل گذاشت؟

کلید سروری نه — اپ قابل باز کردن است و کلید استخراج می‌شود. داخل اپ فقط توکن کاربر می‌نشیند که مال یک نفر است، یا کلید عمومی که فقط داده‌ی ذاتاً عمومی را می‌خواند.

کلیدم را گم کرده‌ام، چطور دوباره ببینمش؟

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

فیلتر کردن داده در کلاینت کافی نیست؟

نه، و این رایج‌ترین نشتی داده در اپ‌هاست. اگر سرور همه‌ی رکوردها را بفرستد و اپ فقط مال کاربر را نشان دهد، داده‌ی بقیه واقعاً روی دستگاه او رفته است. جداسازی باید سمت سرور و در سطح رکورد باشد.

محدودیت نرخ چقدر است؟

به پلن پروژه بستگی دارد و بخشی از سرویس است، نه چیزی که پیکربندی کنید. کلید پلی‌گراند سخت‌گیرانه‌تر محدود شده تا آزمایش‌های شما سهمیه‌ی واقعی پروژه را مصرف نکند.