تعرض واجهة برمجة التطبيقات (API) وظائف وبيانات للبرامج. إن كانت غير محمية جيدًا، فقد تُسرّب معلومات، أو تقبل إجراءات غير مصرح بها، أو تنهار تحت وابل من الطلبات.

هذه الممارسات صالحة أيًا كانت لغة البرمجة المستخدمة.

تحقق من هوية المتصل وما يحق له فعله

المصادقة والتفويض معًا. عند كل طلب: حدد هوية المتصل (عبر رمز مميز)، ثم تحقق من صلاحياته على المورد المحدد المطلوب. لا تفترض أبدًا أن مستخدمًا موثّقًا يحق له فعل أي شيء أو رؤية بيانات مستخدم آخر.

لا تثق بأي شيء يدخل

تحقق صارم. تحقق من نوع كل معلمة وتنسيقها وحجمها وحدودها. ارفض افتراضيًا. احذر من المعرّفات التي يرسلها العميل: من هنا يتسرب الوصول المباشر إلى كائن يخص شخصًا آخر.

تحمّل الحِمل

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

احمِ النقل والأسرار

  • HTTPS إلزامي، وإصدارات TLS محدّثة.
  • المفاتيح والأسرار خارج الشيفرة والمستودع، في خزنة أو متغيرات بيئة.
  • تدوير الأسرار وإمكانية إلغائها.

راقب، رقّم الإصدارات، قلّص

  • سجّل الوصول والأخطاء، راقب الحالات الشاذة، وصدّرها إلى نظام SIEM.
  • رقّم إصدارات واجهة البرمجة لتتطور دون كسر التوافق، وأزل الإصدارات القديمة.
  • اعرض فقط النقاط الطرفية الضرورية؛ حافظ على تحديث التبعيات؛ اختبر بانتظام (مراجعة، فحص).

أسئلة شائعة

هل يكفي مفتاح API لتأمين الوصول؟

لا. المفتاح يُعرّف فقط، ولا يُفوّض بدقة، ويمكن سرقته. يلزم مصادقة وتفويض لكل مورد وتحديد لمعدل الطلبات.

هل يجب عرض رسائل خطأ مفصّلة؟

لا في بيئة الإنتاج: فهي تفيد المهاجم. رسالة عامة على جانب العميل، والتفاصيل في سجلات الخادم.

كيف يُمنع الوصول المباشر إلى كائن يخص شخصًا آخر؟

تحقق دائمًا من أن المتصل يملك حق الوصول إلى المعرّف المطلوب تحديدًا، ولا تثق أبدًا بمعرّف يقدّمه العميل دون تحقق.