+
+## API4:2019 ضعف في البنية التحتية و حد محاولات الطلبات
+
+
+| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
+|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|
+| خصائص API : قابلية الاستغلال **2** | الانتشار **3** : قابلية الاكتشاف **3** | التأثر التقني **2** : تأثر الأعمال |
+| ان عملية الاختراق في بعض الاحيان عملية غير معقدة حيث لا يستلزم الا طلب بسيط للـAPI ومن غير عملية مصادقة كذلك وقد يتم ارسال طلب من خلال جهاز واحد او أجهزة متعددة او أجهزة الخدمات السحابية. | من الاخطاء الشائعة والمنتشرة هو عدم وضع معدل لطلبات او لم يتم اختيار الموصفات المناسبة عند تنصيب واجهات برمجة التطبيقات API. | قد يؤدي الاستغلال الى هجمات حجب الخدمة DOS مما يجعل واجهة برمجة التطبيقات API غير مستجيبة او خارج الخدمة. |
+
+
+
+
+### هل أنا معرض لهذه الثغرة؟
+
+
تستهلك واجهة برمجة التطبيقات API المصادر والأصول من شبكات ووحدات المعالجة وكذلك وسائط التخزين حيث يعتمد بشكل كبير مقدرة تعامل البنية التحتية حسب طلبات ومدخلات المستخدم لمصادر البيانات. وضع في الاعتبار ان طلبات واجهة برمجة التطبيقات API التي تفوق قدرات البنية التحتية تعرضها للخطر بشكل كبير اذا لم يتم تداركها و وضع معدل لمستوى ومحتوى تلك الطلبات ومنها:
+
+* مدة حياة الطلب
+* اعلى حد من استخدام الذاكرة العشوائية لكل طلب
+* عدد الملفات وطرق وصفها وحفظها وعرضها
+* عدد العمليات
+* عدد وحجم البياتات عند رفعها
+* عدد الطلبات لكل مستخدم
+* عدد الصفحات التي يتم عرضها في كل طلب و استجابة لصفحة الواحدة.
+
+
+## امثلة على سيناريوهات الهجوم:
+
+### السيناريو الاول:
+
+يقوم المهاجم برفع صورة كبيرة الحجم والابعاد عن طريق طلب POST الى `/api/v1/images` وعند اكتمال عملية الرفع يقوم الخادم باستعراض الصور المتبقية على هيئة ايقونات مصغرة بسبب الابعاد والحجم الذي قد يستغرق الموارد وقد يؤدي الى عدم واجهة برمجة التطبيقات API.
+
+## السيناريو الثاني :
+
+ يقوم التطبيق بعرض المستخدمين بحد اقصى 100 مستخدم في كل صفحة من خلال ارسال طلب الى `/api/users?page=1&size=100`، مما قد يمكن المهاجم من تغير القيمة الى 200000 في عدد أسماء المستخدمين المعروضة في صفحة واحد مما يسبب في حدوث مشكلات في أداة قاعدة البيانات وفي الوقت نفسة تصبح واجهة برمجة التطبيقات غير متاحة وغير قادرة على التعامل مع الطلبات الأخرى ( هجمة حجب الخدمة DOS ) ويمكن استخدام نفس السيناريو لاستعراض الأخطاء او لاستغلال بعض عمليات Integer Overflow او Buffer Overflow.
+
+### كيف أمنع هذه الثغرة؟
+
+* استخدم منصة Docker مما يجعل الامر في غاية البساطة في التحكم في الذاكرة العشوائية او وحدات المعالجة و التخزين
+* ضع معدل محدد لعدد الطلبات التي يقوم بطلبها المستخدم خلال اطار زمني معين
+* اخطار المستخدم عند تجازو المعدل المحدد في الاطار الزمني المعين
+* قم باضافة بعض آليات التحقق من جانب الخادم في عمليات الطلبات او حتى التحقق من النصوص او العمليات او الطلبات وتحديداً في تلك العمليات التي تتطلب عدد من السجلات يتم استرجاعها من العميل.
+* تحديد وفرض الحد الاعلى لحجم وابعاد الطلبات المرفوعة مثل الحد الاقصى لعدد الجمل او الحد الاعلى لعدد الاسطر
+
+### المراجع :
+
+* [Blocking Brute Force Attacks][5]
+* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors,
+ processes, restarts)][6]
+* [REST Assessment Cheat Sheet][7]
+
+### المصادر الخارجية :
+
+* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8]
+* [CWE-770: Allocation of Resources Without Limits or Throttling][9]
+* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based
+ Application Systems][10], NIST
+
+[1]: https://docs.docker.com/config/containers/resource_constraints/#memory
+[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu
+[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart
+[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit
+[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
+[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts
+[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md
+[8]: https://cwe.mitre.org/data/definitions/307.html
+[9]: https://cwe.mitre.org/data/definitions/770.html
+[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf
diff --git a/2019/ar/src/0xa5-broken-function-level-authorization.md b/2019/ar/src/0xa5-broken-function-level-authorization.md
new file mode 100644
index 000000000..5c98550a9
--- /dev/null
+++ b/2019/ar/src/0xa5-broken-function-level-authorization.md
@@ -0,0 +1,66 @@
+
+
+## API5:2019 ضعف في التحقق من الهوية وادارة الصلاحيات و التفويض
+
+| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
+|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------|
+| خصائص API : قابلية الاستغلال **3** | الانتشار **2** : قابلية الاكتشاف **1** | التأثر التقني **2** : تأثر الأعمال |
+| ان عملية استغلال هذه الثغرة بسيط نسيباً بحيث يستطيع المهاجم ارسال طلب غير ضار من خلال واجهة برمجة التطبيقات API الى مصادر البيانات التي من الغير مصرح له بالاطلاع عليها. وقد تكون تلك المصادر متاحة للمسخدمين المجهولين او المستخدم الذي لا يملك صلاحيات عالية. وحيث ان من السهل اكتشاف مثل تلك الثغرات من خلال معرفة سلوك الطلبات والياتها المستخدمة وطرق طلبها والردود المتوقعة من كل طلب وقد يتم استغلالها ببساطة من خلال استبدال طلب GET بـ PUT او تغير صلاحيات المستخدم من "User " الى "Admin". | عادة ما يتم تحديد صلاحيات الوصول للموارد من خلال الاعدادات. وفي بعض الأحيان على مستوى الاكواد البرمجية، ان عملية تنصيب طرق التحقق بالشكل الصحيح قد تكون في بعض الأحيان عملية معقدة. حيث ان معظم التطبيقات الحديثة تحتوي على مختلف الصلاحيات والمجموعات بتسلسل هرمي معقد بعض الشئ. | بعض آليات العمل قد تسمح للمهاجم في الاستفادة والوصول والاطلاع الغير مصرح به، او حصوله على صلاحيات إدارية تمكنه من التحكم والسيطرة. |
+
+
+
+
هل أنا معرض لهذه الثغرة؟
+
+
أفضل طريقة للعثور على مشكلات وخلل تفويض مستوى الصلاحيات والمصادقة هي إجراء تحليل عميق لآلية التفويض ، مع مراعاة التسلسل الهرمي للمستخدم ، والأدوار أو المجموعات المختلفة في التطبيق ، وطرح الأسئلة التالية:
+
+* هل يستطيع المستخدم العادي الوصول الى مصادر صلاحيات المدراء ؟
+* هل يستطيع المستخدم تعديل او تعيين او مسح مصادر البيانات عند تغير طريقة الطلب للبروتوكول على سبيل المثال من GET الى DELETE ؟
+* هل يستطيع المستخدم في مجموعة أ من الوصول الى مصادر المجموعة ب من خلال تخمين مصدر تلك المجموعة `/api/v1/users/export_all`
+
+* لا تقم بوضع وتقسيم الصلاحيات ما بين الصلاحيات المعتادة والصلاحيات الادارية من خلال مسار URL.
+* و من الشائع لدى المطورين عرض مصادر البيانات الإدارية ضمن مسار محدد مثل API/Admin ومن الشائع كذلك استخدام مصادر واحدة للمستخدم العادي وكذلك للمدراء مثل api/users.
+
+## امثلة على سيناريوهات الهجوم:
+
+### السيناريو الاول:
+
+ يقوم التطبيق فقط بالسماح للمستخدمين المدعوين بالتسجيل، حيث يقوم التطبيق بطلب API الخاص من خلال طلب GET على سبيل المثال المسار التالي ` /api/invites/{invite_guid}` ويأتي الرد من الخادم والذي يحتوي على ملف JSON مع تفاصيل الدعوة، وكذلك تفاصيل المستخدمين و الصلاحيات والبريد الالكتروني.
+
+ يقوم المهاجم بتكرار الطلبات ومحاولة التلاعب والتعديل في طريقة الطلب من مصدر البيانات من GET الى POST مع المسار التالي `/api/invites/new` حيث ان هذا المسار مسموح بالوصول له فقط لأصحاب الصلاحيات الإدارية بواسطة صفحة الإدارة والتي من الواضح عدم تطبيق مستوى المصادقة والتفويض على مستوى الصلاحية.
+
+ المهاجم قام باستغلال الخطأ من خلال ارسال طلب دعوة لنفسه ومن ثم قام بإنشاء حساب بصلاحيات مرتفعة.
+
+```
+POST /api/invites/new
+
+{“email”:”hugo@malicious.com”,”role”:”admin”}
+```
+
+### السيناريو الثاني :
+
+ تحتوي واجهة برمجة التطبيقات API على صلاحيات وصول الى مصادر البيانات والمحددة فقط لمدراء النظام من خلال الطلب باستخدام GET للمسار التالي `/api/admin/v1/users/all` حيث ان مصدر البيانات عند ارجاع البيانات لا تقوم بالتأكد من صلاحيات من قام بطلبها او الصلاحيات المخولة له مما يمكن المهاجم من تخمين المسارات الخاصة بمصادر البيانات لاستعراض بيانات حساسة غير مصرح له بالوصول لها.
+
+### كيف أمنع هذه الثغرة؟
+
+يجب أن يحتوي التطبيق الخاص بك على وحدة تفويض متسقة وسهلة التحليل يتم استدعاؤها من خلال جميع وظائف تطبيقك. في كثير من الأحيان يتم توفير هذه الحماية بواسطة مكون أو أكثر خارج الاكواد البرمجية الخاصة بالتطبيق.
+
+* يجب منع الوصول لجميع المصادر بشكل افتراضي وبعد ذلك يتم السماح والاستثناء للمصادر لكل مصدر على حدة ولكل صلاحية بشكل مستقل.
+* قم بمراجعة صلاحيات المصادقة والتفويض الخاص بالآليات العمل، مع مراعاة منطق التسلسل الهرمي وصلاحيات المجموعات والصلاحيات على مستوى المستخدمين.
+* التأكد من ان صلاحيات التحكم الادارية مبنية بشكل سليم ومرتبطة بصلاحيات المصادقة والتفويض لكل مجموعة او مستخدم او صلاحية.
+* التأكد من ان الاوامر والصلاحيات الادارية مبنية بشكل محوكم وهناك وحدة تحكم تقوم بفحص الصلاحيات والتفويض لكل مستخدم بناء على المجموعة التي تم تعيينه بداخلها.
+
+
+
+## المراجع :
+
+* [OWASP Article on Forced Browsing][1]
+* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2]
+* [OWASP Development Guide: Chapter on Authorization][3]
+### المصادر الخارجية :
+
+* [CWE-285: Improper Authorization][4]
+
+[1]: https://www.owasp.org/index.php/Forced_browsing
+[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control
+[3]: https://www.owasp.org/index.php/Category:Access_Control
+[4]: https://cwe.mitre.org/data/definitions/285.html
diff --git a/2019/ar/src/0xa6-mass-assignment.md b/2019/ar/src/0xa6-mass-assignment.md
new file mode 100644
index 000000000..b5892b5e4
--- /dev/null
+++ b/2019/ar/src/0xa6-mass-assignment.md
@@ -0,0 +1,70 @@
+
+
+## API6:2019 التعيين الجماعي
+
+| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
+|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
+| خصائص API : قابلية الاستغلال **2** | الانتشار **2** : قابلية الاكتشاف **2** | التأثر التقني **2** : تأثر الأعمال |
+| يتطلب الاستغلال عادةً فهم منطق آلية العمل وعلاقة الكائنات ببعضها وهيكل واجهة برمجة التطبيقات API. حيث يعد استغلال التعيين الجماعي أسهل في واجهات برمجة التطبيقاتAPI ، حيث أنها تفصح عن أجزاء من بنية التطبيق ومسميات خصائصه. | تشجع الأطر الحديثة في البرمجة المطورين على استخدام الدوال التي تربط بشكل الأوتوماتيكي المدخلات من المستخدم مع المتغيرات البرمجية ومكونات التطبيق الداخلية. يستطيع المهاجم استخدام هذه الخاصية لتحديث أو تغيير بعض الخصائص الحساسة لمكونات التطبيق التي لم ينوى المطور السماح بها. | قد يؤدي هذا الاستغلال إلى تصعيد الصلاحيات والتلاعب بالبيانات وتجاوز آليات الأمان وغير ذلك. |
+
+
+
+## هل أنا معرض لهذه الثغرة؟
+
+تحتوي بعض التطبيقات الحديثة على العديد من الخصائص وبعض تلك الخصائص يجب تحديثها بواسطة المستخدمين على سبيل المثال `user.first_name` أو `user.address` وبعض الخصائص لا يسمح للمستخدمين بتعديلها على سبيل المثال `user.is_vip`.
+
+تكون واجهة برمجة التطبيقات API ومصادر البيانات عرضة للاختراق إذا تم استخدام مدخلات المستخدم ككائنات داخلية، من دون مراعاة لمستوى حساسية وخطورة تلك الكائنات. وها قد يسمح للمهاجم بتحديث خصائص الكائنات التي لا يجب أو غير مصرح له بالوصول إليها.
+
+### أمثلة على بعض الخصائص الحساسة:
+
+* التعديل في بعض الخواص: مثل `user.is_admin`, `user.is_vip` يجب أن تكون فقط لأصحاب الصلاحيات الإدارية.
+* الخواص المعتدة على العمليات: مثل `user.cash` يجب أن يتم التحقق داخلياً بعد التأكد من عملية الدفع.
+* الخواص الداخلية: على سبيل المثال `article.created_time` يجب أن يكون داخلياً وبواسطة التطبيق فقط.
+
+
+## أمثلة على سيناريوهات الهجوم:
+
+### السيناريو الأول
+
+تطبيق مخصص لرحلات يوفر للمستخدم خيار تعديل البيانات والمعلومات الأساسية للملف الشخصي من خلال إرسال طلب بواسطة برمجة واجهة التطبيقات API التالي `/api/v1/users/me` بواسطة طلب PUT باستخدامJSON بالشكل التالي:
+
+```json
+{"user_name":"inons","age":24}
+```
+يتضمن الطلب GET للمسار التالي `/api/v1/users/me` مع خاصية معرفة الرصيد الائتمانية:
+
+```json
+{"user_name":"inons","age":24,"credit_balance":10}.
+```
+
+حيث قام المهاجم باعتراض الطلب وتغيره إلى التالي:
+
+```json
+{"user_name":"attacker","age":60,"credit_balance":99999}
+```
+
+ونظراً لان مصادر البيانات مصابة بخلل في التعيين والتعديل قام المهاجم بالحصول على مبالغ مالية من دون دفع أي مبلغ حقيقي.
+
+### السيناريو الثاني:
+
+تتيح منصة مشاركة ملفات الفيديو تحميل ورفع وتنزيل الملفات بتنسيقات وامتدادات مختلفة. حيث لاحظ المهاجم أن واجهة برمجة التطبيقات والتي تستطيع الوصول لها من خلال طلب GET على المسار التالي `/api/v1/videos/{video_id}/meta_data` انه يستطيع الحصول على ملف JSON يحتوي على خصائص ملفات الفيديو. على سبيل المثال `mp4_conversion_params":"-v codec h264` مما يوضح أن التطبيق يستخدم أوامر Shell لعملية تحويل الفيديو.
+
+وجد المهاجم احد مصادر البيانات مصابة بالثغرة التي تسمح له بالتعديل والتعين فقام بإرسال تعليمات برمجية ضارة باستخدام واجهة برمجة التطبيقات API مع طلب POST من خلال المسار التالي `/api/v1/videos/new` حيث قام بتعين القيمة التالية مع العملية `mp4_conversion_params":"-v codec h264 && format C:/` والتي سمحت للمهاجم بتنفيذ التعليمات من خلال أوامر Shell بعد إرساله لطلب تنزيل ملف الفيديو.
+
+## كيف أمنع هذه الثغرة؟
+
+* تجنب بقدر ما يمكن استخدام الوظائف التي تتطلب من المستخدم إدخال بعض المتغيرات في الاكواد الداخلية.
+* أضف الخصائص التي يتوجب على المستخدم إدخالها إلى قائمة بيضاء محددة.
+* استخدام الطرق والأساليب التي تمنع المستخدم من الاطلاع أو الوصول غير المصرح به إلى المصادر أو الخصائص.
+* إذا كان من الممكن فرض سياسة استخدام مدخلات محددة في البيانات عند عمليات الرفع أو التنزيل.
+
+
+
المراجع:
+المصادر الخارجية:
+
+* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][1]
+
+[1]: https://cwe.mitre.org/data/definitions/915.html
+
+
+
diff --git a/2019/ar/src/0xa7-security-misconfiguration.md b/2019/ar/src/0xa7-security-misconfiguration.md
new file mode 100644
index 000000000..24d4a150c
--- /dev/null
+++ b/2019/ar/src/0xa7-security-misconfiguration.md
@@ -0,0 +1,88 @@
+
+
+# API7:2019 الاعداد الخاطئ
+
+| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
+|-------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
+| خصائص API : قابلية الاستغلال **3** | الانتشار **3** : قابلية الاكتشاف **3** | التأثر التقني **2** : تأثر الأعمال |
+| يحاول المهاجمون غالباً البحث عن الثغرات الأمنية على مستوى الأنظمة او اليات العمل اول على مصادر بيانات غير محمية وذلك بغاية الوصول الغير مصرح به للمعلومات. | يمكن ان يحدث الاعداد الخاطئ في أي مستوى من مستويات واجهة برمجة التطبيقات API، ابتداءًا من مستوى الشبكة الى مستوى التطبيقات، حيث تتوفر الأدوات للقيام بالفحص واكتشاف الأخطاء بشكل آلي وذلك بهدف البحث عن مواطن الإعدادات الخاطئة او الخدمات الفعالة والغير ضرورية او الخيارات القديمة والمصابة بثغرات. | قد يؤدي عملية الإعدادات الخاطئة الى تسريب البيانات وكذلك اختراق الأنظمة والخوادم. |
+
+
+
+## هل أنا معرض لهذه الثغرة؟
+
+### قد يكون واجهة التطبيقات API معرضة لثغرات في حال :
+
+* اذا لم يكن هناك أي آلية متبعة لعملية تعزيز حماية النظام في جميع مراحله او اذا كان هناك تهيئة غير صحيحة على الخدمات السحابية.
+* اذا لم يكن هناك آلية لسد الثغرات الأمنية او في حال كانت الأنظمة المستخدمة غير محدثة او خارجة عن الخدمة.
+* اذا كان هناك تفعيل لبعض الطلبات الغير مطلوبة مثل بعض طلبات HTTP الغير مستخدمة TREAC او DELETE على سبيل المثال.
+* اذا لم يتم استخدام التشفير بواسطة TLS.
+* إذا لم يتم تعين سياسة مشاركة المواد بطريقة صحيحة او كان هناك خطا في الإعدادات الخاصة بها
+* إذا كانت رسائل الخطأ تحتوي على معلومات حساسة ويمكن تتبعها.
+
+
+## امثلة على سيناريوهات الهجوم:
+
+### السيناريو الاول:
+
+ يعثر المهاجم على ملف `.bash_history` في احد المسارات الرئيسية في الخادم والذي يحتوي على الأوامر التي يستخدمها المطورين في الوصول الى واجهة برمجية التطبيقات API.
+
+```
+$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg=='
+```
+
+ يمكن للمهاجم ايضاً معرفة مصادر البيانات من خلال الأوامر التي يستخدمها المطورين من خلال تكرار عملية الوصول للملف أعلاه وما حدث ذلك الا بسبب عدم توثيق الإجراءات بالشكل الصحيح.
+
+
+### السيناريو الثاني :
+
+ يقوم المهاجمون في معظم الأحيان باستخدام محركات البحث بهدف الحصول على خوادم يستطيع من خلالها الوصول الى مصدر البيانات بشكل مباشر. او من خلال البحث عن أحد المنافذ المشهورة في قواعد البيانات او في إدارة الأنظمة والخوادم. وفي حال كان الخادم او النظام المستهدف يقوم باستخدام الأعدادت الافتراضية وغير محمي باستخدام مصادقة صحيحة قد يمكن المهاجم من الوصول للبيانات الشخصية PII والذي قد يؤدي الى تسريب بيانات المستخدمين لتلك الخدمة.
+
+### السيناريو الثالث
+
+ عند اعتراض حركة المرور للبيانات الخاصة بأحد تطبيقات الهواتف المحمولة والتي تستخدم بروتوكول TLS في حركة البيانات ولكن لا تعتمد على التشفير باستخدام TLS عند استخدام واجهة برمجة التطبيقات API وبعد البحث من قبل المهاجم استطاع معرفة ان عملية تحميل ورفع الصور يتم بشكل غير مشفر، فقد وجد المهاجم نمط وطريقة لمعرفة الاستجابة الواردة من قبل الخادم او من قبل مصدر البيانات والتي قد تمكنه بطريقة او بأخرى من تتبع تفضيلات المستخدمين عند تنزيل او عرض تلك الصور.
+
+
+## كيف أمنع هذه الثغرة؟
+
+### دورة حياة واجهة برمجة التطبيقات API لابد ان تشتمل على :
+
+* عملية تعزيز حماية الأنظمة تساهم بشكل كبير في بناء بيئة امنة و موثوقة
+* إيجاد آلية لمراجعة الإعدادات و التحديثات بأكملها ويجب ان تتضمن مراجعة كل من ملفات الحفظ و المزامنة مكونات واجهة برمجة التطبيقات API و الخدمات السحابية.
+* توفير اتصال امن و مشفر لجميع الاتصالات في التعامل مع التطبيق او رفع وتحميل الصور.
+* عملية تقييم امني مستمر لمعرفة مستوى نضج الاعدادات في جميع انحاء البنية التحتية.
+
+### علاوة على ذلك:
+
+* لمنع تتبع الأخطاء التي قد يتم الرد بها بعد عمليات الطلب والتي قد تمكن المهاجم من استعراض البيانات الحساسة يجب ان تكون جميع الردود محدودة ومحصورة بما في ذلك عمليات الاستجابة للأخطاء.
+* تأكد انه لا يمكن الوصول الى واجهة برمجة التطبيقات API الا من خلال احد الطلبات المحددة وعدم السماح بجميع الطلبات الخاصة ببروتوكول HTTP بالعمل بل ويجب تعطيلها مثال (HEAD , TRACE).
+* يجب على واجهات برمجة التطبيقات API التي تتوقع أن يتم الوصول إليها من عملاء يستندون إلى المتصفح على سبيل المثال (الواجهة الامامية لخدمات الويب) يجب تنفيذ سياسة سليمة وموثوقة لمشاركة الموارد عبر (CORS).
+
+
+
المراجع :
+
+* [OWASP Secure Headers Project][1]
+* [OWASP Testing Guide: Configuration Management][2]
+* [OWASP Testing Guide: Testing for Error Codes][3]
+* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9]
+
+المصادر الخارجية :
+
+* [CWE-2: Environmental Security Flaws][4]
+* [CWE-16: Configuration][5]
+* [CWE-388: Error Handling][6]
+* [Guide to General Server Security][7], NIST
+* [Let’s Encrypt: a free, automated, and open Certificate Authority][8]
+
+[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project
+[2]: https://www.owasp.org/index.php/Testing_for_configuration_management
+[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001)
+[4]: https://cwe.mitre.org/data/definitions/2.html
+[5]: https://cwe.mitre.org/data/definitions/16.html
+[6]: https://cwe.mitre.org/data/definitions/388.html
+[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final
+[8]: https://letsencrypt.org/
+[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)
+
+
+
diff --git a/2019/ar/src/0xa8-injection.md b/2019/ar/src/0xa8-injection.md
new file mode 100644
index 000000000..3bc97fe90
--- /dev/null
+++ b/2019/ar/src/0xa8-injection.md
@@ -0,0 +1,95 @@
+
+
+# API8:2019 الحقن
+
+
+| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
+|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|
+| خصائص API : قابلية الاستغلال **3** | الانتشار **2** : قابلية الاكتشاف **3** | التأثر التقني **3** : تأثر الأعمال |
+| يقوم المهاجمون بإرسال بيانات ضارة من خلال واجهة برمجة التطبيقات API وذلك من خلال حقنها بأي طريقة ممكنة ( مثل الإدخال المباشر و التعليمات البرمجية و طرق ربط الخدمات ...الخ) على أمل إرسالها إلى المفسر. | تعتبر ثغرات الحقن منشرة وشائعة في استعلامات SQL و LDAP و NoSQL وأوامر أنظمة التشغيل و XML parsers و ORM. واكتشاف هذه الثغرات يعتبر سهل عن مراجعة الشفرة المصدرية. بإمكان المهاجمين استخدام أدوات الفحص. | يمكن أن يؤدي الحقن إلى إفشاء المعلومات أو مسح وفقدان البيانات. كما يمكن أن يودي إلى حجب الخدمة DoS، أو اختراق كامل للنظام. |
+
+
+
+## هل أنا معرض لهذه الثغرة؟
+
+### قد تكون واجهة برمجة التطبيقات API معرضة للاستغلال بمثل هذه الهجمات عندما :
+
+* لا يتم تصفية البيانات أو التحقق منها في حال كانت مقدمة من المستخدمين من طريق واجهة برمجة التطبيقات.
+* يتم استخدام البيانات بشكل مباشر مع SQL/NoSQL/LDAP queries, OS commands, XML parsers.
+* لا يتم التحقق من صحة البيانات الواردة من أنظمة خارجية مثل (الأنظمة المرتبطة بالخادم) أو تصفيتها أو التحقق منها من قبل واجهة برمجة التطبيقات API قبل عملية استخدامها
+
+## أمثلة على سيناريوهات الهجوم:
+
+### السيناريو الأول:
+
+يقوم نظام جهاز التحكم الأبوي باستخدام المسار `/api/CONFIG/restore`والذي يتوقع أن يستقبل معرف التطبيق appId في أجزاء متعددة.
+فباستخدام برنامج فك وتحويل الشفرات البرمجية(decompile)، يجد المهاجم أن المعرف appId يتم تمريره مباشرة للنظام ومن غير عوامل التصفية المقترحة:
+
+```
+snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d",
+ "/mnt/shares/usr/bin/scripts/", appid, 66);
+system(cmd);
+```
+
+ يسمح الأمر التالي للمهاجم بإغلاق أي جهاز مصاب بتلك الثغرة البرمجية
+
+```
+$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'
+```
+
+### السيناريو الثاني :
+
+
+لدينا تطبيق قائم على وظائف CRUD للتعامل مع الحجوزات، تمكن مهاجم من التعرف على إمكانية حقن NoSQL من خلال الاستعلام بالمعرف الفريد للحجوزات `bookingId` وطلب الحذف بأمر كالتالي: `DELETE /api/bookings?bookingId=678`
+
+خادم واجهة برمجة التطبيقات (API Server) يستخدم الدالة التالية للتعامل مع طلبات الحذف:
+
+```javascript
+router.delete('/bookings', async function (req, res, next) {
+ try {
+ const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});
+ res.status(200);
+ } catch (err) {
+ res.status(400).json({error: 'Unexpected error occured while processing a request'});
+ }
+});
+```
+
+قام المهاجم باعتراض الطلبات الخاصة بالمعرف الفريد `bookingId`وقام بتغير أمر الاستعلام كما هو معروض بالأسفل مما أدى إلى حذف حجز يعود لمستخدم آخر:
+
+```
+DELETE /api/bookings?bookingId[$ne]=678
+```
+
+## كيف أمنع هذه الثغرة؟
+
+لمنع عمليات الحقن انت بحاجة إلى فصل الأوامر والتعليمات البرمجية عن الاستعلامات بشكل صحيح و امن.
+
+* قم بإجراء التحقق من صحة البيانات المدخلة باستخدام مكتبة موحدة وامنه وموثوقة ويتم صيانتها بشكل دوري.
+* تحقق من صحة جميع البيانات المقدمة من المستخدم أو غيرها من البيانات الواردة من الأنظمة المتكاملة وتصفيتها.
+* يجب التعامل مع الأحرف والرموز الخاصة باستخدام الصيغة المحددة للمفسر المستهدف.
+* استخدم واجهة برمجة تطبيقات آمنة (safe API) ذات استعلامات واضحة.
+* ضع حداً لعدد السجلات التي يتم إرجاعها لمنع تسريب البيانات بشكل كبير في حالة نجاح عملية الحقن.
+* تحقق من صحة البيانات الواردة باستخدام عوامل تصفية كافية للسماح فقط بالقيم الصالحة لكل استعلام تم إدخاله.
+* عرف بشكل واضح ومحدد الانماط و أنواع البيانات المستخدمة في الاستعلامات
+
+
+## المراجع
+* [OWASP Injection Flaws][1]
+* [SQL Injection][2]
+* [NoSQL Injection Fun with Objects and Arrays][3]
+* [Command Injection][4]
+
+### مصادر خارجية :
+
+* [CWE-77: Command Injection][5]
+* [CWE-89: SQL Injection][6]
+
+[1]: https://www.owasp.org/index.php/Injection_Flaws
+[2]: https://www.owasp.org/index.php/SQL_Injection
+[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf
+[4]: https://www.owasp.org/index.php/Command_Injection
+[5]: https://cwe.mitre.org/data/definitions/77.html
+[6]: https://cwe.mitre.org/data/definitions/89.html
+
+
diff --git a/2019/ar/src/0xa9-improper-assets-management.md b/2019/ar/src/0xa9-improper-assets-management.md
new file mode 100644
index 000000000..a030f1c8e
--- /dev/null
+++ b/2019/ar/src/0xa9-improper-assets-management.md
@@ -0,0 +1,59 @@
+
+
+# API9:2019 إدارة الأصول بشكل خاطئ
+
+| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
+|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| خصائص API : قابلية الاستغلال **3** | الانتشار **3** : قابلية الاكتشاف **2** | قابلية التأثر التقني **2** : تأثر الأعمال | التأثر التقني و تأثر الأعمال: 2 |
+| إصدارات واجهة برمجة التطبيقات API القديمة غالباً غير مرقعة وتعتبر طريق سهل لاختراق الأنظمة وتجاوز العديد من تقنيات الحماية الحديثة والتي تم تركيبها غالباً لحماية الأنظمة الحديثة و المتطورة من واجهة برمجة التطبيقات API. | وثائق الأنظمة والبرمجيات الغير محدثة تجعل من الصعب تتبع وإصلاح الثغرات. وكذلك عدم وجود جرد للأصول التقنية واستراتيجية للتخلص من الأصول القديمة يؤدي إلى وجود أنظمة تعمل بدون ترقيعات أمنية، وذلك قد يؤدي إلى تسريب للبيانات الحساسة. وكما انه من الشائع رصد واجهة برمجة التطبيقات API متاحة على الإنترنت مع كونها لا تستخدم بسبب المفاهيم الحديثة كالخدمات المصغرة (microservices) والتي تجعل من التطبيقات سهلة النشر ومستقلة على سبيل المثال (الحوسبة السحابية) | قد يتمكن المهاجمون من الوصول إلى بيانات حساسة، أو حتى اختراق الخادم من خلال استغلال احد الثغرات الغير مرقعة لخدمات واجهة برمجة التطبيقات API والتي تستخدم للاتصال بقاعدة البيانات. |
+
+
+
+## هل واجهة برمجة التطبيقات API معرضة لهذه الثغرة؟
+
+### قد تكون واجهة برمجة التطبيقات معرض لمثل هذه الثغرة في حالة :
+
+* الغرض من استخدام واجهة برمجة التطبيقات غير واضح ولا توجد إجابات للأسئلة التالية:
+ - ما هي البيئة التي تعمل فيها واجهة برمجة التطبيقات (على سبيل المثال ، الإنتاج ، التدريج ، الاختبار ، التطوير)؟
+ - من المخول للوصول إلى الشبكة الخاصة بواجهة برمجة التطبيقات (على سبيل المثال ، عام ، داخلي ، شركاء)؟
+ - ما هو إصدار API المستخدم؟
+ - ماهي البيانات التي يتم جمعها بواسطة API؟ وهل هي بيانات شخصية؟
+ - ماهي آلية سير البيانات؟
+* لا توجد وثائق معتمدة أو وثائق قديمة وغير محدثة.
+* لا توجد خطة للتخلص من إصدارة واجهة برمجة التطبيقات القديمة.
+* لا يوجد حصر للأصول أو أنه غير محدث.
+* لا يوجد حصر للخدمات المتصلة بالأنظمة سواء كانت طرف أول أو طرف ثالث أو أنه غير محدث.
+* إصدارات API قديمة وغير محدثة ولا تزال مستخدمة
+
+## أمثلة على سيناريوهات الهجوم:
+
+### السيناريو الأول:
+
+بعد إعادة تصميم التطبيقات لإحدى الخدمات، لم يتم التخلص من الإصدارة القديمة والغير محمية من واجهة برمجة التطبيقات `api.someservice.com/v1` والمتصلة بقاعدة البيانات. وبعد عمليات الفحص من قبل أحد المهاجمين توصل لعنوان واجهة برمجة التطبيقات الجديدة `api.someservice.com/v2`. باستبدال `v2` بـ `v1` تمكن المهاجم من الوصول لواجهة برمجة التطبيقات القديمة والغير محدثة والتي أدت إلى تسريب معلومات شخصية لأكثر من 100 مليون مستخدم.
+
+### السيناريو الثاني:
+
+ قامت منصة للتواصل الاجتماعي باستخدام آلية للحد من عدد محاولات تخمين كلمات المرور. آلية الأمان تلك لم يتم تطبيقها على الشفرة المصدرية الخاصة بواجهة برمجة التطبيقات API، بل قاموا بفصلها لكي تكون ما بين المستخدم وواجهة برمجة التطبيقات (`www.socialnetwork.com`). أحد الباحثين عثر على خادم لنسخة تجريبية (`www.mbasic.beta.socialnetwork.com`) والتي يستطيع من خلالها القيام بنفس المهام التي تقوم بها الواجهة المعتمدة بما في ذلك إعادة تعين كلمات المرور لكن بدون آلية الأمان التي تحد من عدد محاولات التخمين. و باستخدام النسخة التجريبية تمكن الباحث من إعادة تعيين كلمة السر بعد قيامة بعمليات بسيطة لتخمين كلمة المصادقة المكونة من 6 أرقام.
+
+
+
+## كيف أمنع هذه الثغرة؟
+
+* جرد وحصر جميع الأجهزة الخاصة بواجهة برمجة التطبيقات وتوثيق الجوانب الهامة لك واحد منهم، والتركيز بشكل كبير على بيئة API (على سبيل المثال، الإنتاج ، التدريج ، الاختبار ، التطوير)، ومن هم المخولين بالوصول لهم من الشبكة (كشبكة الإنترنت أو الداخلية أو الشركاء).
+* حصر جميع الخدمات المرتبطة بالأنظمة وتوثيق جوانبها المهمة كدورها في النظام ونوعية البيانات التي يتم تداولها من خلالها وحساسية تلك البيانات.
+* توثيق جميع جوانب واجهة برمجة التطبيقات API مثل عمليات التحقق والأخطاء وإعادة التوجيه وسياسة حصر مشاركة الموارد (CORS)، بما في ذلك إعداداتها والطلبات والاستجابة لتلك الطلبات.
+* إنشاء الوثائق بشكل آلي من خلال تبني المعايير المفتوحة. وتضمين عملية بناء الوثائق في خط الإنتاج الخاص باختبار ونشر التطبيقات.
+* التأكد من أن الوثائق متاحة للأشخاص المصرح لهم فقط.
+* التأكد من استخدام التدابير الوقائية اللازمة مثل جدران الحماية الخاصة بواجهة برمجة التطبيقات API لجميع إصدارات واجهة برمجة التطبيقات المتصلة بالأنترنت وليس فقط الإصدارة الحالية.
+* تجنب استخدام بيانات حقيقية من بيئة التشغيل على البيئة التجريبية لواجهة برمجة التطبيقات، وفي حال توجب عليك استخدامها فيجب أن يتم تطبيق جميع المعايير الأمنية نفسها التي يتم تطبيقها على بيئة التشغيل.
+* في حال كانت الإصدارات الحديثة من واجهة برمجة التطبيقات تحتوي على معايير أمان افضل، قم بإجراء تحليل للمخاطر لاتخاذ القرارات والإجراءات التي تخفف من مخاطر الإصدار القديم. على سبيل المثال إذا كان من الممكن إضافة تلك المعايير الأمنية الجديدة للإصدار السابق من دون التأثير على التوافقية مع الأنظمة الأخرى أو أنه لابد من التخلص من الإصدار القديم و إلزام جميع المستخدمين بالانتقال إلى الإصدار الحديث.
+
+
المراجع
+
+
المصادر الخارجية:
+
+* [CWE-1059: Incomplete Documentation][1]
+* [OpenAPI Initiative][2]
+
+[1]: https://cwe.mitre.org/data/definitions/1059.html
+[2]: https://www.openapis.org/
diff --git a/2019/ar/src/0xaa-insufficient-logging-monitoring.md b/2019/ar/src/0xaa-insufficient-logging-monitoring.md
new file mode 100644
index 000000000..d170bd5e8
--- /dev/null
+++ b/2019/ar/src/0xaa-insufficient-logging-monitoring.md
@@ -0,0 +1,58 @@
+
+
+# API10:2019 خلل في طريقة تسجيل الاحداث والمراقبة
+
+| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
+|-------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------|
+| خصائص API : قابلية الاستغلال **2** | الانتشار **3** : قابلية الاكتشاف **1** | التأثر التقني **2** : تأثر الأعمال |
+| يستغل المهاجمون عدم تسجيل الاحداث وحركة مرور البيانات بشكل صحيح للقيام بأنشطة ضارة على الأنظمة من دون أي ملاحظة. | عدم وجود أو خلل في آلية نظام تسجيل الاحداث و مراقبة حركة مرور البيانات ينتج عنه صعوبة في تتبع الأنشطة المشبوة والاستجابة لها في الوقت المناسب. | عدم وجود رؤية كاملة على الانشطة المشبوة التي تحدث تمنح المهاجمين الوقت الكافي لأختراق الأنظمة. |
+
+
+
+## هل أنا معرض لهذه الثغرة؟
+
+### سيكون النظام لديك معرض اذا كان:
+
+* لا يتم استخراج أي سجلات او لم يتم تعيين عمليات التسجيل بالشكل الصحيح او لم يتم جمع السجلات بشكل كافي وناضج.
+* عند عدم ضمان السجلات (على سبيل المثال في حال حقن السجلات بسجلات غير صحيح)
+* لا يتم مراقبة السجلات بشكل مستمر
+* لا يتم مراقبة البنية التحتية لواجهة برمجة التطبيقات API بشكل مستمر.
+
+## امثلة على سيناريوهات الهجوم:
+
+### السيناريو الاول:
+
+ عن طريق الخطأ تم تسريب احد مفاتيح إدارة المستودعات في احد المستودعات العامة، لذا تم أخطار مالك المستودع عن طريق البريد الالكتروني بشأن التسريب المحتمل، ولكن لم يقم مالك المستودع بالتجاوب في خلال 48 ساعة والتصرف بشأن هذا التسريب، وﻷن من المحتمل استخدام هذه المفاتيح في عمليات تسريب البيانات، و بسبب عدم تسجيل الاحداث بشكل صحيح لا تستطيع الشركة تقييم ومعرفة الأصول والبيانات التي تم الوصول لها او في حال تم تسريبها.
+
+### السيناريو الثاني :
+
+ منصة مشاركة ملفات الفيديو تعرضت بشكل واسع الى هجمات محاولة كسر كلمات المرور بأستخدام حسابات مستخدمين صالحة, بالرغم من المحاولات الكثيرة لعمليات تسجيل الدخول الخاطئة لم تظهر أي تنبيهات اثناء الهجوم، في حين قام المستخدمين بالشكوى لدى الشركة بشأن اغلاق حسابتهم بشكل مفاجئ، وبعد تحليل سجلات الخاصة بواجهات برمجة التطبيقات API تبين أن هناك هجوم حدث.لذا قامت الشركة أصدار اعلان لجميع المستخدمين لأعادة تهيئة كلمات المرور الخاصة بهم.
+
+
+## كيف أمنع هذه الثغرة؟
+
+* قم بتسجيل جميع محاولات المصادقة الفاشلة او محاولات رفض الوصول للمجلدات وكذلك جميع المدخلات الخاطئة.
+* يجب كتابة السجلات بشكل متناسق لاستخدامه في عمليات إدارة السجلات ويجب ان تتضمن كافة التفاصيل التي تتيح للمحلل معرفة الأنشطة الضارة ومن قام بها.
+* يجب التعامل مع السجلات باعتبارها بيانات حساسة ويجب ضمان سلامتها اثناء المرور و التخزين.
+* قم بإعداد عمليات المراقبة واجعلها مستمرة ولتشمل البنية التحتية والشبكات و واجهة برمجة التطبيقات API.
+* استخدام أنظمة مركز سجل الأحداث SIEM لإدارة السجلات من جميع المصادر والأنظمة و واجهات برمجة التطبيقات.
+* قم بإعداد لوحة مراقبة مخصصة للتنبيهات الأمنية وقم بتفعيل التواقيع الرقمية لرصد الأنشطة المشبوهة لرصدها في مراحلها الأولية.
+
+## المراجع :
+
+* [OWASP Logging Cheat Sheet][2]
+* [OWASP Proactive Controls: Implement Logging and Intrusion Detection][3]
+* [OWASP Application Security Verification Standard: V7: Error Handling and
+ Logging Verification Requirements][4]
+
+### المصادر الخارجية :
+
+* [CWE-223: Omission of Security-relevant Information][5]
+* [CWE-778: Insufficient Logging][6]
+
+[1]: https://www.owasp.org/index.php/Log_Injection
+[2]: https://www.owasp.org/index.php/Logging_Cheat_Sheet
+[3]: https://www.owasp.org/index.php/OWASP_Proactive_Controls
+[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md
+[5]: https://cwe.mitre.org/data/definitions/223.html
+[6]: https://cwe.mitre.org/data/definitions/778.html
diff --git a/2019/ar/src/0xb0-next-devs.md b/2019/ar/src/0xb0-next-devs.md
new file mode 100644
index 000000000..ecf7eb1f0
--- /dev/null
+++ b/2019/ar/src/0xb0-next-devs.md
@@ -0,0 +1,39 @@
+
+
+# ما التالي للمطورين؟
+
+قد تكون مهمة إنشاء برامج آمنة وصيانتها ، أو إصلاح البرامج الموجودة ، صعبة. وكذلك هو الحال مع واجهات برمجة التطبيقات لا تختلف.
+
+نعتقد أن التعليم والوعي من العوامل الرئيسية لكتابة برامج آمنة. كل شيء آخر من المتطلبات هو لتحقيق الأهداف المنشودة، **وهو بالأساس يعتمد على إنشاء واستخدام عمليات أمنية قابلة للتكرار وضوابط أمنية قياسية**.
+
+لدى OWASP العديد من الموارد المجانية والمفتوحة لمعالجة مشاكل الأمن منذ بداية هذا المشروع. يرجى زيارة صفحة مشاريع أواسب للحصول على [قائمة شاملة بالمشاريع المتاحة][1].
+
+
+| | |
+|------------------------------------ |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **تعليم أمن التطبيقات** | يمكنك البدء في قراءة مواد مشروع OWASP التعليمي وفقًا لمهنتك واهتماماتك. للتعلم العملي ، أضفنا crAPI - Ridiculous API في خارطة الطريق الخاصة بنا. وفي الوقت نفسه ، يمكنك التدرب على WebAppSec باستخدام OWASP DevSlop Pixi Module ، وهو تطبيق ويب ضعيف وخدمة API تهدف إلى تعليم المستخدمين كيفية اختبار تطبيقات الويب الحديثة وواجهات برمجة التطبيقات للتعامل مع مشكلات الأمان ، وكيفية كتابة واجهات برمجة تكون أكثر أمانًا في المستقبل. كما يمكنك أيضًا حضور جلسات OWASP AppSec التدريبية أو الانضمام إلى فرق OWASP المحلية . |
+| **متطلبات أمن التطبيقات** | لإنتاج تطبيقات ويب آمنة، يجب عليك تعريف معنى الأمن بالنسبة للتطبيق. أواسب تنصحك باستخدام مشروع أواسب لمعايير التحقق من أمن التطبيقات، كدليل إرشادي يساعدك في ضبط المتطلبات الأمنية لتطبيقاتك. في حال انجاز المشاريع عبر موارد خارجية، قم بمراجعة ملحق أواسب لعقود البرمجيات الآمنة. |
+| **هيكلة أمن التطبيقات** | يجب أن يظل الأمن مصدر للاهتمام خلال جميع مراحل المشروع. تعد ورقة المرجعية من OWASP (Cheat Sheet) نقطة انطلاق جيدة للإرشادات حول كيفية تصميم الأمان أثناء مرحلة البناء. من بين العديد من الاوراق الأخرى ، ستجد ورقة مراجع الأمان (Security Cheat Sheet) وورقة مراجع التقييم (Assessment Cheat Sheet.) |
+| **أدوات التحكم الأمنية المعيارية** | إن عملية إنشاء أدوات تحكم أمنية قوية ومناسبة للاستخدام هي مهمة صعبة جدا . إن وجود مجموعة من أدوات التحكم الأمنية المعيارية ستسهل –وبشكل جذري- عملية تطوير تطبيقات آمنة. تنصح أواسب بمشروع واجهات التطبيقات البرمجية الأمنية للمنشآت كنموذج لواجهات التطبيقات البرمجية APIs اللازمة لإنتاج تطبيقات ويب آمنة. أيضا يقدم بعض المكتبات والأدوات التي قد تجدها ذات قيمة ، مثل التحقق من صحة أدوات التحكم. |
+| **دورة حياة التطوير الآمنة** | يمكنك استخدام OWASP Software Assurance Maturity Model (SAMM) لتحسين العملية عند إنشاء واجهات برمجة التطبيقات API. تتوفر العديد من مشاريع OWASP الأخرى لمساعدتك خلال مراحل تطوير API المختلفة ، على سبيل المثال ، مشروع مراجعة كود OWASP. |
+
+
+
+[1]: https://www.owasp.org/index.php/Category:OWASP_Project
+[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized
+[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map
+[4]: https://devslop.co/Home/Pixi
+[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference
+[6]: https://www.owasp.org/index.php/OWASP_Chapter
+[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
+[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex
+[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
+[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md
+[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md
+[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018
+[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project
+[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
+
+
+
+
diff --git a/2019/ar/src/0xb1-next-devsecops.md b/2019/ar/src/0xb1-next-devsecops.md
new file mode 100644
index 000000000..532f5b093
--- /dev/null
+++ b/2019/ar/src/0xb1-next-devsecops.md
@@ -0,0 +1,28 @@
+
+
+# ما التالي لمطوري الممارسات الامنية في التطبيقات؟
+
+ نظرًا لأهميتها في بناء التطبيقات الحديثة ، فإن بناء واجهات برمجة آمنة أمر في غاية الأهمية ، ويجب أن يكون الأمن جزءًا من دورة حياة التطوير بأكملها. لم تعد اختبارات الاختراق السنوية كافية.
+ يجب أن تنضم DevSecOps إلى جهود التطوير ، مما يسهل اختبار الأمان المستمر عبر دورة حياة تطوير البرامج بأكملها. هدفهم هو تعزيز طريق التطوير بأتمتة الأمان ، ودون التأثير على سرعة التطوير.
+
+اذا كنت تود الاطلاع والمراجعة ، راجع https://www.devsecops.org/
+
+| فهم نماذج التهديد | تأتي أولويات الاختبار من نماذج التهديد المتوقعة. إذا لم يكن لديك واحد ، ففكر في استخدام OWASP Application Security Verification Standard (ASVS) ، ودليل اختبار OWASP كمدخل. قد يساعد في رفع مستوى الوعي لفريق التطوير. |
+|--------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| فهم دورة حياة التطبيقات | قم بالانضمام الى فريق تطوير البرمجيات لفهم دورة حياة البرامج. حيث ان مساهمتك في اختبار الامان بشكل مستمر ومتوافق مع الادوات والعمليات والاجراءات التي يتفق عليها الجميع وبشكل سلسل. |
+| استراتيجيات الاختبار | لا يجب ان تؤثر اعمالك على سرعة وتيرة التطوير بل يجب أن تختار بحكمة الأسلوب الأفضل (البسيط والأسرع والأكثر دقة) للتحقق من متطلبات الأمان. يمكن أن يكون إطار OWASP للمعرفة الأمنية ومعيار OWASP للتحقق من أمان التطبيقات مصادر جيدة لمتطلبات الأمان الوظيفية وغير الوظيفية. هناك مصادر أخرى للمشاريع والأدوات المشابهة لتلك التي يقدمها مجتمع DevSecOps |
+| تحقيق التغطية والدقة المطلوبة | أنت حلقة الوصل بين المطورين وفرق العمليات. لتحقيق التغطية بالشكل المطلوب ، لا يجب أن تركز فقط على آلية عملها فقط ، ولكن أيضًا على التنسيق بشكل سليم. وذلك من خلال العمل بالقرب من فرق التطوير والعمليات من البداية حتى تتمكن من استغلال الجهود المبذولة. يجب أن تهدف إلى حالة دائمة من تحقيق معايير الأمان بشكل أساسي ومستمر. |
+| ايصال النتائج بشكل واضح | قم بالمشاركة في صنع قيمة مع اقل اختلاف مع فرق العمل. وقم بتسليم النتائج في الوقت المناسب ، باستخدام الأدوات المتاحة من قبل الفريق، انضم إلى فريق التطوير لمعالجة النتائج والمخرجات وقم بشرح ووصف نقاط الضعف بشكل واضح جداً وكيف سيتم إساءة استخدامها وقم بذكر بعض السيناريوهات الحقيقة لاستغلالها . |
+
+
+
+[1]: https://www.devsecops.org/
+[2]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
+[3]: https://www.owasp.org/index.php/OWASP_Testing_Project
+[4]: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework
+[5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
+[6]: http://devsecops.github.io/
+[7]: https://github.com/devsecops/awesome-devsecops
+[8]: http://devsecops.org
+
+
diff --git a/2019/ar/src/0xd0-about-data.md b/2019/ar/src/0xd0-about-data.md
new file mode 100644
index 000000000..d9b38a39c
--- /dev/null
+++ b/2019/ar/src/0xd0-about-data.md
@@ -0,0 +1,31 @@
+
+
+# المنهجية والبيانات
+
+
+## نظرة عامة
+
+نظرًا لأن صناعة برامج آمنة لم تركز بشكل خاص على أحدث بنية وهيكلة للتطبيقات، حيث تلعب واجهات برمجة التطبيقات دورًا مهمًا، فإن تجميع قائمة بأكثر عشرة مخاطر لواجهة برمجة التطبيقات (API)، استنادًا إلى استفتاء عام، كانت من أصعب المهام. على الرغم من عدم وجود مصادر عامة، إلا أن قائمة العشرة مخاطر لا تزال تستند على الاستفتاء، ومساهمات خبراء الأمن المعلوماتي، والمناقشات المفتوحة مع مجتمع الأمنى.
+
+## المنهجية
+
+في المرحلة الأولى، تم جمع البيانات المتاحة من المصادر العامة وحول الحوادث الأمنية لواجهات برمجة التطبيقات API ومراجعتها وتصنيفها من قبل مجموعة من خبراء الأمن. وكما تم جمع هذه البيانات من منصات مكافآت الثغرات وقواعد بيانات الثغرات الأمنية، في إطار زمني مدته عام واحد. تم استخدام تلك البيانات لأغراض إحصائية.
+
+ في المرحلة التالية ، طُلب من الممارسين الأمنيين ذوي الخبرة في اختبار الاختراق حصر اكثر عشر مخاطر امنية خاصة بهم.
+
+تم [استخدام منهجية OWASP][1] لتصنيف المخاطر لإجراء تحليل المخاطر. تمت مناقشة النتائج ومراجعتها بين الممارسين الأمنيين. للحصول على رأي OWASP حول هذه الامور ، يرجى الرجوع إلى قسم [مخاطر أمان API][2].
+
+ نتجت المسودة الأولى من OWASP API Security Top 10 2019 عن توافق بين النتائج الإحصائية من المرحلة الأولى وقوائم الممارسين الأمنيين. ثم تم تقديم هذه المسودة لتقديرها ومراجعتها من قبل مجموعة أخرى من ممارسي الأمن ، من ذوي الخبرة ذات الصلة في مجالات أمان واجهة برمجة التطبيقات.
+
+تم تقديم OWASP API Security Top 10 2019 لأول مرة في حدث OWASP Global AppSec في (مايو 2019). منذ ذلك الحين ، كان متاحًا على GitHub للمناقشة العامة والمساهمات.
+
+[قائمة المساهمين متاحة في قسم الشكر والتقدير][3].
+
+
+[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
+[2]: ./0x10-api-security-risks.md
+[3]: ./0xd1-acknowledgments.md
+
+
+
+
diff --git a/2019/ar/src/0xd1-acknowledgments.md b/2019/ar/src/0xd1-acknowledgments.md
new file mode 100644
index 000000000..d3d597ca7
--- /dev/null
+++ b/2019/ar/src/0xd1-acknowledgments.md
@@ -0,0 +1,53 @@
+
+
+# الإقرار
+
+## المساهمين في صناعة هذا المحتوى
+
+نشكر جميع المشاركين بشكل عام من خلال منصة GitHub وكذلك المشاركين من خلال وسائل ووسائط اخرى وهم :
+
+* 007divyachawla
+* Abid Khan
+* Adam Fisher
+* anotherik
+* bkimminich
+* caseysoftware
+* Chris Westphal
+* dsopas
+* DSotnikov
+* emilva
+* ErezYalon
+* flascelles
+* Guillaume Benats
+* IgorSasovets
+* Inonshk
+* JonnySchnittger
+* jmanico
+* jmdx
+* Keith Casey
+* kozmic
+* LauraRosePorter
+* Matthieu Estrade
+* nathanawmk
+* PauloASilva
+* pentagramz
+* philippederyck
+* pleothaud
+* r00ter
+* Raj kumar
+* Sagar Popat
+* Stephen Gates
+* thomaskonrad
+* xycloops123
+
+### وكذلك المترجمين للغة العربية وهم
+* مالك الدوسري
+* محمد السحيمي
+* صبري حسنية
+* مصطفى الاقصم
+* فهد الدريبي
+* 0xMohammed
+
+
+
+
diff --git a/2019/ar/src/images/cover.jpg b/2019/ar/src/images/cover.jpg
new file mode 100644
index 000000000..5ef93f221
Binary files /dev/null and b/2019/ar/src/images/cover.jpg differ
diff --git a/2019/ar/src/images/front-cc.png b/2019/ar/src/images/front-cc.png
new file mode 100644
index 000000000..45f139804
Binary files /dev/null and b/2019/ar/src/images/front-cc.png differ
diff --git a/2019/ar/src/images/front-wasp.png b/2019/ar/src/images/front-wasp.png
new file mode 100644
index 000000000..5a163dd4b
Binary files /dev/null and b/2019/ar/src/images/front-wasp.png differ
diff --git a/2019/ar/src/images/license.png b/2019/ar/src/images/license.png
new file mode 100644
index 000000000..124d3ba4d
Binary files /dev/null and b/2019/ar/src/images/license.png differ
diff --git a/2019/ar/src/images/owasp-logo.png b/2019/ar/src/images/owasp-logo.png
new file mode 100644
index 000000000..caeb47bdf
Binary files /dev/null and b/2019/ar/src/images/owasp-logo.png differ