English | 繁中版 | 简中版 | বাংলা | Čeština | Deutsch | Ελληνικά | Español | فارسی | Français | हिंदी | Indonesia | Italiano | 日本語 | 한국어 | ພາສາລາວ | Македонски | മലയാളം | Монгол | Nederlands | Polski | Português (Brasil) | Русский | ไทย | Türkçe | Українська | Tiếng Việt
قائمة تحتوي على أهم الاحتياطات الأمنية حينما تقوم بتخطيط واختبار وإطلاق الـAPI الخاصة بك
- لا تستخدم
Basic Auth
لكن استخدم المعايير القياسية للمصادقة (مثال JWT, OAuth). - لا تعد اختراع العجلة في
المصادقة
،توليد الرموز
،تخزين كلمات المرور
. قم باستخدام المعايير القياسية. - استخدم
تحديد عدد المحاولات
والحرمان من الدخول jail feature
في تسجيل الدخول. - استخدم التشفير في كل البيانات الحساسة.
- استخدم مفتاح عشوائي ومعقد (
JWT Secret
) لتجعل هجوم التخمين بالقوة brute forcing صعبا جدا. - لا تقم باستخراج خوارزمية التشفير من محتوى رمز الـ JWT. قم بإجبار الرمز البرمجي على استخدام خوارزمية (
HS256
أوRS256
). - اجعل مدة انتهاء الرمز (
TTL
,RTTL
) قصيرة قدر الإمكان. - لا تقم بتخزين أي بيانات حساسة داخل محتوى رمز الـ JWT, لأنه يمكن كشف هذه المحتويات بسهولة easily.
- تجنب تخزين الكثير من البيانات. عادةً ما تتم مشاركة JWT في الرؤوس ولديها حد للحجم.
- حدد الطلبات (Throttling) لتتجنب هجوم حجب الخدمة DDoS وهجوم التخمين بالقوة brute-force.
- استخدم HTTPS على الخادوم لتتجنب هجمات التنصت على الطلبات MITM (Man In The Middle Attack).
- استخدم
HSTS
header مع الـ SSL لتتجنب هجمات الـ SSL Strip. - قم بإيقاف تشغيل قوائم الدليل.
- بالنسبة لواجهات برمجة التطبيقات الخاصة، اسمح بالوصول فقط من عناوين IP والمضيفين المدرجين في القائمة البيضاء.
- تحقق دائما من
redirect_uri
في الرمز البرمجي للخادوم لتسمح فقط بقائمة محددة من الروابط. - دائما حاول أن تقوم بالتبادل والرد برمز برمجي وليس بالرمز (لا تسمح
response_type=token
). - استخدم متغير
state
في الرابط مع مزيج عشوائي من الحروف لتمنع هجمات الـ CSRF على عملية المصادقة الخاصة بالـ OAuth. - حدد الصلاحية والنطاق الافتراضي scope، وقم بالتحقق منه مع كل تطبيق.
- استخدم الوسيلة المناسبة HTTP method حسب العملية التي تريد القيام بها :
GET (للقرائة)
,POST (انتاج أو اضافة)
,PUT/PATCH (لإستبدال او تحديث)
, andDELETE (لحذف سجل)
, و قم بالرد بـ405 Method Not Allowed
في حالة إذا كانت الوسيلة method غير مناسبة . - قم بالتحقق من
content-type
في رأس الطلب reuest header أو ما يسمى بـ (Content Negotiation) لتسمح فقط بالتنسيقات المدعومة (مثالapplication/xml
,application/json
, إلى آخره) وقم بالرد بـ406 Not Acceptable
إذا كان التنسيق غير ذلك. - قم بالتحقق من
content-type
في محتوى الطلب نفسه posted data (مثالapplication/x-www-form-urlencoded
,multipart/form-data
,application/json
, إلى آخره). - قم بالتحقق من مدخلات المستخدم لتتجنب الثغرات الشائعة (مثال
XSS
,SQL-Injection
,Remote Code Execution
, إلى آخره). - لا تستخدم أي بيانات حساسة (
credentials
,Passwords
,security tokens
, أوAPI keys
) في الرابط ولكن استخدم الطريقة القياسية وهي رأس الطلب الخاص بالمصادقة Authorization header. - استخدم فقط التشفير من جانب الخادم.
- استخدم واجهة للـ API لتستفيد من التخزين المؤقت caching وسياسات تحديد عدد الطلبات Rate Limit policies (مثال
الحصة Quota
,التنبية في الارتفاع المفاجئ Spike Arrest
,وتحديد عدد الطلبات المتزامنة Concurrent Rate Limit
)
- قم بفحص كل النطاقات والروابط للتحقق من كونهم محميين وراء مصادقة authentication لتتجنب المصادقة المكسورة broken authentication.
- يجب تجنب استخدام المعرف الخاص بالموارد. قم باستخدام
/me/orders
بدلا من/user/654321/orders
. - لا تقم باستخدام المعرف التلقائي auto-increment. قم باستخدام
UUID
بدلا منه. - لو قمت بمعالجة ملفات XML, تأكد من أن معالجة entity parsing غير مفعلة لتتجنب هجمات
XXE
(XML external entity). - لو قمت بمعالجة ملفات XML, تأكد من أن entity expansion غير مفعلة لتتجنب هجمات
Billion Laughs/XML bomb
من خلال هجوم exponential entity expansion. - استخدم شبكات تسليم المحتوى CDN لرفع الملفات.
- لو كنت تتعامل مع حجم بيانات ضخم، استخدم عمليات منفصلة Workers, Queues لمعالجة البيانات في الخلفية والرد على المستخدم بسرعة لتجنب حجب الطلب HTTP Blocking.
- لا تترك وضع التصحيح DEBUG mode في حالة التشغيل.
- استخدم مكدسات غير قابلة للتنفيذ عند توفرها.
- استخدم
X-Content-Type-Options: nosniff
في رأس الطلب header. - استخدم
X-Frame-Options: deny
في رأس الطلب header. - استخدم
Content-Security-Policy: default-src 'none'
في رأس الطلب header. - احذف الرؤوس headers التي تدل عليك -
X-Powered-By
,Server
,X-AspNet-Version
إلى آخره. - قم بإجبار إرسال
content-type
مع الرد، لو قمت بالرد بمحتويات من توعapplication/json
فمن المستحسن أن يكون الرد بcontent-type
application/json
. - لا تقم بالرد بمعلومات وبيانات حساسة مثل
credentials
,Passwords
,security tokens
. - قم بالرد بكود حالة صحيح status code طبقا للعملية التي تقوم بها. (مثال
200 OK
,400 Bad Request
,401 Unauthorized
,405 Method Not Allowed
, إلى آخره).
- مراجعة التصميم الخاص بك والتنفيذ مع وحدة / التكامل اختبارات الاختبار unit/integration tests coverage.
- استخدام عملية مراجعة الرمز البرمجي وتجاهل الموافقة على الرمز البرمجي الذي قمت بكتابته.
- تأكد من أن جميع مكونات الخدمات الخاصة بك يتم فحصها بشكل ثابت بواسطة برامج الفيروسات قبل إرسالها إلى الإنتاج، بما في ذلك المكتبات الخارجية وغيرها من التبعيات.
- قم بإجراء اختبارات الأمان باستمرار (التحليل الثابت/الديناميكي) على التعليمات البرمجية الخاصة بك.
- تحقق من تبعياتك (البرنامج ونظام التشغيل) بحثًا عن نقاط الضعف المعروفة.
- تصميم حل التراجع عن عمليات النشر rollback.
- Use centralized logins for all services and components.
- Use agents to monitor all traffic, errors, requests, and responses.
- Use alerts for SMS, Slack, Email, Telegram, Kibana, Cloudwatch, etc.
- Ensure that you aren't logging any sensitive data like credit cards, passwords, PINs, etc.
- Use an IDS and/or IPS system to monitor your API requests and instances.
- yosriady/api-development-tools - مجموعة من الادوات و المصادر لبناء RESTful HTTP+JSON APIs.
لا تتردد في المساهمة عن طريق أخذ نسخة من هذه القائمة fork، وإجراء بعض التغييرات، وتقديم طلبات المراجعة pull request. أي أسئلة الرجاء مراسلتنا على البريد الإلكتروني [email protected]
.