عبدالله الكندي يصحّح ٦ قناعات خاطئة عن أمان واجهات API

واجهة الـ API هي الباب الخلفي لتطبيقك: كل شاشة في الجوال وكل صفحة في لوحة التحكم تكلّمها. والمشكلة إن فرقاً كثيرة تحميها بقناعات تبدو منطقية وهي غلط. عبدالله الكندي يمر هنا على ست قناعات تتكرر في المشاريع، ويصحح كل وحدة بالطريقة اللي تُبنى فيها الحماية فعلاً: المفاتيح، وتحديد معدل الطلبات، والصلاحيات.

«المفتاح مخفي داخل التطبيق، محد بيوصله»

أي شي داخل ملف التطبيق اللي ينزل على جوال المستخدم يعتبر مكشوفاً. ملف APK أو IPA يُفك بأدوات مجانية، والطلبات تُراقب بأداة وسيطة على نفس الجهاز. التشويش والتشفير يبطئون المهاجم، ما يمنعونه.

الحل إنك تفرّق بين نوعين من المفاتيح. مفتاح عام مصمم إنه يكون في الواجهة، مثل المفتاح العام في Supabase أو مفتاح خرائط مقيّد باسم حزمة التطبيق، وهذا ما يعطي إلا ما تسمح به قواعدك في السيرفر. ومفتاح سري يعطي صلاحية كاملة — مفتاح بوابة الدفع، أو مفتاح نموذج الذكاء الاصطناعي، أو مفتاح الخدمة في قاعدة البيانات — وهذا مكانه السيرفر فقط. التطبيق يطلب من سيرفرك، وسيرفرك يكلّم الخدمة الخارجية بالمفتاح السري.

«حطيناها في متغيرات البيئة، يعني آمنة»

متغيرات البيئة خطوة صحيحة، لكنها مو نهاية القصة. في Next.js مثلاً، أي متغير يبدأ بـ NEXT_PUBLIC_ ينضم لكود المتصفح ويشوفه أي زائر. وملف ‎.env اللي انرفع لمستودع git مرة وحدة يبقى في تاريخ المستودع حتى لو حذفته بعدها. والقواعد اللي يلتزم بها عبدالله عبدالرحيم بن سنكر الكندي في مشاريع منصة أزهل الرقمية:

• ملف ‎.env داخل ‎.gitignore من أول commit، مو بعد أول تسريب.
• لكل بيئة مفاتيحها: مفاتيح التطوير غير الإنتاج، عشان جهاز مطوّر مخترق ما يفتح بيانات العملاء.
• لكل خدمة أقل صلاحية تحتاجها: مفتاح للقراءة فقط إذا الخدمة تقرأ فقط.
• تدوير المفاتيح: إذا انكشف مفتاح، ألغه فوراً عند المزوّد وأصدر بديلاً، لا تكتفي بحذفه من الكود.
• حد إنفاق أو تنبيه استهلاك عند المزوّدين اللي يحاسبون بالاستخدام، مثل نماذج الذكاء الاصطناعي، عشان المفتاح المسرّب ما يتحول لفاتورة مفتوحة.

«تحديد المعدل للمواقع الكبيرة بس»

تحديد معدل الطلبات (Rate limiting) مو حماية من زحمة الزوار فقط. هو اللي يمنع تخمين كلمات المرور، وطلب آلاف رموز التحقق على حسابك، وسحب قاعدة بياناتك صفحة صفحة عبر سكربت. وأرخص وقت تطبقه فيه هو أول يوم.

الطريقة العملية حدود مختلفة لكل نوع نقطة نهاية. تسجيل الدخول وإرسال الرموز تاخذ حداً صارماً لكل رقم ولكل عنوان IP، ونقاط القراءة العادية حداً أوسع لكل مستخدم مسجّل. ولما يتجاوز أحد الحد، يرجع له الرد 429 Too Many Requests مع ترويسة Retry-After تقول له متى يحاول. وخوارزمية مثل «دلو التوكنات» (Token bucket) تسمح بدفعة قصيرة من الطلبات وتمنع الاستمرار عليها، وهذا يناسب المستخدم الحقيقي اللي يفتح شاشة فتطلب عدة أشياء في نفس اللحظة.

ووين تطبقه؟ أول خط دفاع قبل ما يوصل الطلب لكودك: في شبكة توصيل المحتوى أو بوابة الـ API إذا عندك. والخط الثاني داخل التطبيق نفسه للحدود اللي تعتمد على هوية المستخدم. وإذا السيرفر يشتغل على أكثر من نسخة، العدّادات لازم تكون في مخزن مشترك مثل Redis، وإلا كل نسخة تحسب لحالها ويصير الحد الفعلي أضعاف اللي كتبته.

«المستخدم مسجّل دخول، إذن مسموح له»

التوثيق (Authentication) يجاوب «مين أنت؟»، والتفويض (Authorization) يجاوب «وش يحق لك؟». والخلط بينهم سبب أشهر الثغرات: مستخدم مسجّل يغيّر رقم الطلب في الرابط من 1001 إلى 1002 فيشوف طلب غيره. كل طلب لازم يمر بسؤالين: هل التوكن صالح؟ وهل هذا المورد بالذات يخص هذا المستخدم، أو دوره يسمح له؟

وفي قواعد البيانات اللي يكلّمها التطبيق مباشرة مثل Supabase، هذا التفويض يُكتب كسياسات أمان على مستوى الصفوف (Row Level Security). جدول بدون سياسات مفعّلة يعني إن أي أحد معه المفتاح العام يقدر يقرأ الجدول كله. ونفس المنطق للصلاحيات الدقيقة في التوكنات: بدل توكن يقدر يسوي كل شي، أعطِ كل تكامل نطاقاً محدداً (Scopes) مثل قراءة الطلبات فقط.

«التوكن ما ينتهي، أريح للمستخدم»

توكن وصول بدون تاريخ انتهاء يعني إن أي توكن ينسرق يبقى صالحاً للأبد. النمط المعتاد: توكن وصول قصير العمر، ومعه توكن تجديد أطول يُحفظ في مكان آمن — Keychain في iOS و Keystore في أندرويد، عبر حزمة مثل flutter_secure_storage — ويمكن إلغاؤه من السيرفر لو سجّل المستخدم خروجه أو بلّغ عن سرقة جواله. المستخدم ما يحس بشي، والتجديد يصير في الخلفية.

«الأمان نضيفه قبل الإطلاق بأسبوع»

الأمان اللي ينضاف في آخر أسبوع غالباً طبقة سطحية فوق تصميم مفتوح. الأسئلة الأساسية — وين تعيش المفاتيح؟ ومين يقدر يقرأ أي جدول؟ ووش الحد لكل نقطة نهاية؟ — تنحسم مع أول جدول وأول endpoint. وتغييرها بعد ما يكبر المشروع يعني إعادة النظر في كل شاشة تكلّم السيرفر.

ومع الحماية، المراقبة. سجّل محاولات الدخول الفاشلة والطلبات المرفوضة بالرموز 401 و 403 و 429، وخلّ عندك تنبيهاً لو قفزت فجأة، لأن القفزة غالباً أول علامة على هجوم. وبالمقابل، لا تسجّل التوكنات ولا كلمات المرور ولا بيانات البطاقات في السجلات أبداً؛ السجل نفسه يصير تسريباً لو وصله أحد.

اسأل مطوّرك سؤالاً واحداً يكشف لك الكثير: لو أخذ أحد ملف التطبيق وفكّه الليلة، وش أسوأ شي يقدر يسويه؟ إذا كان الجواب واضحاً ومطمئناً، فأنت في يد أمينة. وإذا تردد، فهذا وقت المراجعة، مو بعد التسريب.