diff --git a/5.0/ar/0x00-Header.yaml b/5.0/ar/0x00-Header.yaml
new file mode 100644
index 0000000000..9a0b784331
--- /dev/null
+++ b/5.0/ar/0x00-Header.yaml
@@ -0,0 +1,22 @@
+---
+    title: "معيار التحقق من أمان التطبيقات"
+    subtitle: "الإصدار 5.0.0"
+    date: "مايو 2025"
+    titlepage: true
+    titlepage-rule-height: 0
+    titlepage-logo: "images/owasp_logo_1c_notext.png"
+    table-use-row-colors: true
+    toc: true
+    toc-own-page: true
+    geometry: "left=2cm,right=2cm,top=3cm,bottom=3cm"
+    lang: ar
+    dir: rtl
+    mainfont: "Amiri"
+    sansfont: "Amiri"
+    mainfontoptions:
+    - Script=Arabic
+    - Language=Arabic
+    sansfontoptions:
+    - Script=Arabic
+    - Language=Arabic
+---
diff --git a/5.0/ar/0x01-Frontispiece.md b/5.0/ar/0x01-Frontispiece.md
new file mode 100644
index 0000000000..44b0bc19aa
--- /dev/null
+++ b/5.0/ar/0x01-Frontispiece.md
@@ -0,0 +1,46 @@
+# البداية
+
+## عن المعيار
+
+معيار التحقق من أمان التطبيقات هو قائمة بمتطلبات أمان التطبيقات التي يمكن للمعماريين والمطوّرين والمختبرين ومتخصصي الأمان ومورّدي الأدوات والمستهلكين استخدامها لتحديد التطبيقات الآمنة وبنائها واختبارها والتحقق منها.
+
+## حقوق النشر والترخيص
+
+الإصدار 5.0.0، مايو 2025
+
+![license](../images/license.png)
+
+حقوق النشر © 2008-2025 مؤسسة OWASP.
+
+يُنشر هذا المستند بموجب [ترخيص المشاع الإبداعي: النسبة إلى المُصنَّف - الترخيص بالمثل 4.0 دولي](https://creativecommons.org/licenses/by-sa/4.0/).
+
+عند أي إعادة استخدام أو توزيع، يجب أن توضّح للآخرين شروط ترخيص هذا العمل بجلاء.
+
+## قادة المشروع
+
+|                       |                  |
+|---------------------- |----------------- |
+| Elar Lang             | Josh C Grossman  |
+| Jim Manico            | Daniel Cuthbert  |
+
+## مجموعة العمل
+
+|                 |                   |                    |                  |
+|---------------- |------------------ |------------------- |----------------- |
+| Tobias Ahnoff   | Ralph Andalis     | Ryan Armstrong     | Gabriel Corona   |
+| Meghan Jacquot  | Shanni Prutchi    | Iman Sharafaldin   | Eden Yardeni     |
+
+## مساهمون رئيسيون آخرون
+
+|                   |                   |
+|-------------------|-------------------|
+| Sjoerd Langkemper | Isaac Lewis       |
+| Mark Carney       | Sandro Gauci      |
+
+## مساهمون ومراجعون آخرون
+
+لقد أدرجنا قائمة بالمساهمين الآخرين في الملحق هـ.
+
+إذا كان هناك إسهام غائب عن قائمة الإسهامات للإصدار 5.x، فيُرجى تسجيل تذكرة على GitHub ليُعترف به في تحديثات 5.x المستقبلية.
+
+يبني معيار التحقق من أمان التطبيقات على عمل من شاركوا في إصدارات معيار التحقق من أمان التطبيقات من 1.0 (2008) حتى 4.0 (2019). وقد كُتب في الأصل كثير من البنية والعديد من بنود التحقق التي لا تزال موجودة في معيار التحقق من أمان التطبيقات اليوم على أيدي Andrew van der Stock وMike Boberski وJeff Williams وDave Wichers، إلى جانب عدد كبير من المساهمين الآخرين. شكرًا لكل من ساهم في الماضي. وللحصول على قائمة شاملة بالمساهمين السابقين، يُرجى الرجوع إلى كل إصدار سابق.
diff --git a/5.0/ar/0x02-Preface.md b/5.0/ar/0x02-Preface.md
new file mode 100644
index 0000000000..11ecde6c3d
--- /dev/null
+++ b/5.0/ar/0x02-Preface.md
@@ -0,0 +1,29 @@
+# تمهيد
+
+أهلًا بك في الإصدار 5.0 من معيار التحقق من أمان التطبيقات (ASVS).
+
+## مقدمة
+
+أُطلق معيار التحقق من أمان التطبيقات في الأصل عام 2008 من خلال تعاون مجتمعي عالمي، وهو يحدّد مجموعة شاملة من متطلبات الأمان لتصميم تطبيقات وخدمات الويب الحديثة وتطويرها واختبارها.
+
+بعد إصدار معيار التحقق من أمان التطبيقات 4.0 عام 2019 وتحديثه الطفيف (الإصدار 4.0.3) عام 2021، يمثّل الإصدار 5.0 محطة مهمة—حُدِّث ليجسّد أحدث التطورات في أمان البرمجيات.
+
+معيار التحقق من أمان التطبيقات 5.0 هو نتاج إسهامات واسعة من قادة المشروع وأعضاء مجموعة العمل ومجتمع OWASP الأوسع لتحديث هذا المعيار المهم وتحسينه.
+
+## المبادئ التي يستند إليها الإصدار 5.0
+
+طُوِّرت هذه المراجعة الرئيسية مع مراعاة عدة مبادئ أساسية:
+
+* نطاق وتركيز مُحسَّنان: صُمِّم هذا الإصدار من المعيار ليتوافق بشكل أكثر مباشرة مع الركائز الأساسية في اسمه: التطبيق، والأمان، والتحقق، والمعيار. وقد أُعيدت كتابة المتطلبات للتأكيد على منع العيوب الأمنية بدلًا من إلزام تنفيذات تقنية محدّدة. والمقصود أن تكون نصوص المتطلبات شارحة لنفسها، موضّحةً سبب وجودها.
+
+* دعم القرارات الأمنية الموثّقة: يقدّم معيار التحقق من أمان التطبيقات 5.0 متطلبات لتوثيق القرارات الأمنية الرئيسية. وهذا يعزّز إمكانية التتبّع ويدعم التنفيذات الحسّاسة للسياق، ما يتيح للمؤسسات تكييف وضعها الأمني وفق احتياجاتها ومخاطرها المحدّدة.
+
+* مستويات محدَّثة: مع أن معيار التحقق من أمان التطبيقات يحتفظ بنموذجه ثلاثي الطبقات، فقد تطوّرت تعريفات المستويات لتسهيل تبنّي معيار التحقق من أمان التطبيقات. صُمِّم المستوى 1 كخطوة أولى لتبنّي معيار التحقق من أمان التطبيقات، موفّرًا الطبقة الأولى من الدفاع. ويمثّل المستوى 2 نظرة شاملة لممارسات الأمان القياسية، أما المستوى 3 فيتناول المتطلبات المتقدّمة عالية التوكيد.
+
+* محتوى مُعاد هيكلته وموسّع: يشتمل معيار التحقق من أمان التطبيقات 5.0 على نحو 350 متطلبًا موزّعة على 17 فصلًا. وقد أُعيد تنظيم الفصول لتحقيق الوضوح وسهولة الاستخدام. ويُتاح تخطيط ثنائي الاتجاه بين الإصدارين 4.0 و5.0 لتيسير الانتقال.
+
+## نظرة إلى الأمام
+
+كما أن تأمين التطبيق لا ينتهي حقًا، فكذلك معيار التحقق من أمان التطبيقات. ومع أن الإصدار 5.0 إصدار رئيسي، فإن التطوير مستمر. ويتيح هذا الإصدار للمجتمع الأوسع الاستفادة من التحسينات والإضافات التي تراكمت، لكنه يرسي كذلك الأساس لتحسينات مستقبلية. وقد يشمل ذلك جهودًا يقودها المجتمع لإنشاء إرشادات للتنفيذ والتحقق مبنية على مجموعة المتطلبات الأساسية.
+
+صُمِّم معيار التحقق من أمان التطبيقات 5.0 ليكون أساسًا موثوقًا لتطوير البرمجيات الآمنة. والمجتمع مدعو إلى تبنّي هذا المعيار والإسهام فيه والبناء عليه للنهوض جماعيًا بحالة أمان التطبيقات.
diff --git a/5.0/ar/0x03-What-is-the-ASVS.md b/5.0/ar/0x03-What-is-the-ASVS.md
new file mode 100644
index 0000000000..bb160f51d5
--- /dev/null
+++ b/5.0/ar/0x03-What-is-the-ASVS.md
@@ -0,0 +1,195 @@
+# ما هو معيار التحقق من أمان التطبيقات؟
+
+يحدّد معيار التحقق من أمان التطبيقات (ASVS) متطلبات أمنية لتطبيقات الويب وخدماته، وهو مورد قيّم لكل من يسعى إلى تصميم تطبيقات آمنة وتطويرها وصيانتها أو إلى تقييم أمانها.
+
+ويبيّن هذا الفصل الجوانب الجوهرية لاستخدام معيار التحقق من أمان التطبيقات، بما فيها نطاقه وبنية مستوياته القائمة على الأولوية وحالات الاستخدام الرئيسية للمعيار.
+
+## نطاق معيار التحقق من أمان التطبيقات
+
+يتحدّد نطاق معيار التحقق من أمان التطبيقات باسمه: التطبيق والأمان والتحقق والمعيار. فهو يرسي أي المتطلبات مُدرجة وأيها مستثناة، مع الهدف الشامل لتحديد المبادئ الأمنية التي يجب تحقيقها. ويراعي النطاق كذلك متطلبات التوثيق، التي تشكّل الأساس لمتطلبات التنفيذ.
+
+ولا وجود لشيء يُسمّى نطاقًا بالنسبة إلى المهاجمين. ولذلك ينبغي تقييم متطلبات معيار التحقق من أمان التطبيقات إلى جانب الإرشادات المتعلقة بجوانب أخرى من دورة حياة التطبيق، بما فيها عمليات التكامل والتسليم المستمرين (CI/CD) والاستضافة والأنشطة التشغيلية.
+
+### التطبيق
+
+يُعرّف معيار التحقق من أمان التطبيقات "التطبيق" بأنه المنتج البرمجي قيد التطوير، الذي يجب دمج ضوابط الأمان فيه. ولا يفرض معيار التحقق من أمان التطبيقات أنشطة دورة حياة التطوير ولا يحدّد كيفية بناء التطبيق عبر خط CI/CD؛ بل يحدّد المخرجات الأمنية التي يجب تحقيقها داخل المنتج نفسه.
+
+وقد تُعدّ المكوّنات التي تقدّم حِزَم HTTP أو تعدّلها أو تتحقق منها، مثل جدران حماية تطبيقات الويب (WAFs) أو موازنات الحمل أو الوكلاء، جزءًا من التطبيق لتلك الأغراض بعينها، إذ تعتمد بعض ضوابط الأمان عليها مباشرةً أو يمكن تنفيذها من خلالها. وينبغي مراعاة هذه المكوّنات في المتطلبات المتعلقة بالاستجابات المخزَّنة مؤقتًا أو تحديد المعدّل أو تقييد الاتصالات الواردة والصادرة بناءً على المصدر والمقصد.
+
+وفي المقابل، يستثني معيار التحقق من أمان التطبيقات عمومًا المتطلبات التي ليست ذات صلة مباشرة بالتطبيق أو التي يكون تكوينها خارج مسؤولية التطبيق. على سبيل المثال، تُدار مشكلات نظام أسماء النطاقات (DNS) عادةً بواسطة فريق أو وظيفة منفصلة.
+
+وبالمثل، مع أن التطبيق مسؤول عن كيفية استهلاكه للمدخلات وإنتاجه للمخرجات، فإذا تفاعلت عملية خارجية مع التطبيق أو بياناته، فإنها تُعدّ خارج نطاق معيار التحقق من أمان التطبيقات. فعلى سبيل المثال، يكون النسخ الاحتياطي للتطبيق أو لبياناته عادةً مسؤولية عملية خارجية ولا يتحكّم فيه التطبيق أو مطوّروه.
+
+### الأمان
+
+يجب أن يكون لكل متطلب أثر ملموس على الأمان. ويجب أن يؤدي غياب المتطلب إلى تطبيق أقل أمانًا، ويجب أن يقلّل تنفيذ المتطلب إما احتمال وقوع خطر أمني أو أثره.
+
+أما جميع الاعتبارات الأخرى، مثل الجوانب الوظيفية أو أسلوب كتابة الشيفرة أو متطلبات السياسات، فهي خارج النطاق.
+
+### التحقق
+
+يجب أن يكون المتطلب قابلًا للتحقق، ويجب أن يؤدي التحقق إلى قرار "فشل" أو "نجاح".
+
+### المعيار
+
+صُمِّم معيار التحقق من أمان التطبيقات ليكون مجموعة من المتطلبات الأمنية التي يجب تنفيذها للامتثال للمعيار. ويعني ذلك أن المتطلبات تقتصر على تحديد الهدف الأمني الذي ينبغي تحقيقه. ويمكن بناء المعلومات الأخرى ذات الصلة فوق معيار التحقق من أمان التطبيقات أو ربطها به عبر التخطيطات.
+
+وعلى وجه التحديد، لدى OWASP مشاريع كثيرة، ويتجنّب معيار التحقق من أمان التطبيقات متعمّدًا التداخل مع محتوى المشاريع الأخرى. فعلى سبيل المثال، قد يكون لدى المطوّرين سؤال: "كيف أنفّذ متطلبًا معيّنًا في تقنيتي أو بيئتي بعينها"، وهذا ينبغي أن يغطّيه مشروع Cheat Sheet Series. وقد يكون لدى المدقّقين سؤال: "كيف أختبر هذا المتطلب في هذه البيئة"، وهذا ينبغي أن يغطّيه مشروع Web Security Testing Guide.
+
+ومع أن معيار التحقق من أمان التطبيقات ليس موجّهًا لاستخدام خبراء الأمان وحدهم، فإنه يتوقع من القارئ أن يمتلك معرفة تقنية لفهم المحتوى أو القدرة على البحث في مفاهيم بعينها.
+
+### المتطلب
+
+تُستخدم كلمة متطلب في معيار التحقق من أمان التطبيقات على وجه التحديد لأنها تصف ما يجب تحقيقه لاستيفائه. ولا يحتوي معيار التحقق من أمان التطبيقات إلا على متطلبات (يجب) ولا يحتوي على توصيات (ينبغي) كشرط رئيسي.
+
+وبعبارة أخرى، فإن التوصيات، سواء كانت مجرّد خيار من خيارات ممكنة كثيرة لحل مشكلة أو اعتبارات لأسلوب كتابة الشيفرة، لا تستوفي التعريف لتكون متطلبًا.
+
+والمقصود من متطلبات معيار التحقق من أمان التطبيقات تناول مبادئ أمنية محدّدة دون أن تكون شديدة الخصوصية بالتنفيذ أو التقنية، وأن تكون في الوقت نفسه شارحة لنفسها فيما يخص سبب وجودها. ويعني ذلك كذلك أن المتطلبات ليست مبنية حول طريقة تحقق أو تنفيذ بعينها.
+
+### القرارات الأمنية الموثّقة
+
+في أمان البرمجيات، سيؤدي التخطيط للتصميم الأمني والآليات التي ستُستخدم في وقت مبكر إلى تنفيذ أكثر اتساقًا وموثوقية في المنتج أو الميزة النهائية.
+
+وإضافةً إلى ذلك، سيكون التنفيذ في بعض المتطلبات معقّدًا وخاصًا جدًا باحتياجات التطبيق. ومن الأمثلة الشائعة الصلاحيات والتحقق من صحة المدخلات والضوابط الحمائية حول مستويات مختلفة من البيانات الحساسة.
+
+ولمراعاة ذلك، وبدلًا من عبارات عامة مثل "يجب تشفير جميع البيانات" أو محاولة تغطية كل حالة استخدام ممكنة في متطلب واحد، أُدرجت متطلبات توثيق تُلزم بتوثيق منهج مطوّر التطبيق وتكوينه لهذه الأنواع من الضوابط. ويمكن بعد ذلك مراجعة ذلك للتأكد من ملاءمته، ثم مقارنة التنفيذ الفعلي بالوثائق لتقدير ما إذا كان التنفيذ يطابق التوقعات.
+
+والمقصود من هذه المتطلبات توثيق القرارات التي اتخذتها المؤسسة المطوّرة للتطبيق بشأن كيفية تنفيذ متطلبات أمنية معيّنة.
+
+وتكون متطلبات التوثيق دائمًا في القسم الأول من الفصل (وإن لم يكن لكل فصل متطلبات توثيق)، ويكون لها دائمًا متطلب تنفيذ مرتبط بها ينبغي فيه تطبيق القرارات الموثّقة فعليًا. والمقصد هنا أن التحقق من وجود الوثائق والتحقق من التنفيذ الفعلي نشاطان منفصلان.
+
+وهناك محرّكان رئيسيان لإدراج هذه المتطلبات. المحرّك الأول أن المتطلب الأمني كثيرًا ما يتضمّن إنفاذ قواعد، مثل أنواع الملفات المسموح بتحميلها، وضوابط العمل التي ينبغي إنفاذها، والمحارف المسموح بها في حقل معيّن. وستختلف هذه القواعد في كل تطبيق، ولذلك لا يستطيع معيار التحقق من أمان التطبيقات أن يحدّد إلزاميًا ما ينبغي أن تكون عليه، ولن تفيد ورقة مرجعية أو استجابة أكثر تفصيلًا في هذه الحالة. وبالمثل، فمن دون توثيق هذه القرارات، لن يكون من الممكن إجراء تحقق من المتطلبات التي تنفّذها.
+
+والمحرّك الثاني أنه من المهم، في متطلبات معيّنة، منح جهة تطوير التطبيق مرونة بشأن كيفية تناول تحديات أمنية بعينها. فعلى سبيل المثال، كانت قواعد مهلة الجلسة في إصدارات معيار التحقق من أمان التطبيقات السابقة إلزامية جدًا. ومن الناحية العملية، لدى تطبيقات كثيرة، وخصوصًا الموجّهة إلى المستهلكين، قواعد أكثر تسامحًا بكثير وتفضّل تنفيذ ضوابط تخفيف أخرى بدلًا من ذلك. ولذلك تتيح متطلبات التوثيق مرونة صريحة في هذا الشأن.
+
+ومن الواضح أنه ليس من المتوقع أن يتخذ المطوّرون الأفراد هذه القرارات ويوثّقوها، بل ستتخذها المؤسسة ككل وتتأكد من إبلاغها إلى المطوّرين الذين يحرصون بعد ذلك على اتباعها.
+
+إن تزويد المطوّرين بمواصفات وتصاميم للميزات والوظائف الجديدة جزء معتاد من تطوير البرمجيات. وبالمثل، يُتوقع من المطوّرين استخدام مكوّنات وآليات واجهة مستخدم مشتركة بدلًا من مجرّد اتخاذ قراراتهم الخاصة كل مرة. ولذلك لا ينبغي أن يُنظر إلى توسيع ذلك ليشمل الأمان كأمر مفاجئ أو مثير للجدل.
+
+وهناك مرونة كذلك في كيفية تحقيق ذلك. فقد تُوثَّق القرارات الأمنية في مستند فعلي يُتوقع من المطوّرين الرجوع إليه. وبدلًا من ذلك، قد تُوثَّق القرارات الأمنية وتُنفَّذ في مكتبة شيفرة مشتركة يُلزم جميع المطوّرين باستخدامها. وفي كلتا الحالتين تتحقق النتيجة المرجوة.
+
+## مستويات التحقق من أمان التطبيقات
+
+يحدّد معيار التحقق من أمان التطبيقات ثلاثة مستويات للتحقق الأمني، يتزايد كل مستوى منها في العمق والتعقيد. والهدف العام أن تبدأ المؤسسات بالمستوى الأول لتناول أهم الاعتبارات الأمنية، ثم تنتقل إلى المستويات الأعلى وفق احتياجات المؤسسة والتطبيق. وقد تُعرض المستويات في المستند وفي نصوص المتطلبات بالصور L1 وL2 وL3.
+
+ويشير كل مستوى في معيار التحقق من أمان التطبيقات إلى المتطلبات الأمنية اللازم تحقيقها من ذلك المستوى، مع اعتبار متطلبات المستويات الأعلى المتبقية توصيات.
+
+ولتجنّب المتطلبات المكرّرة أو المتطلبات التي لم تعد ذات صلة في المستويات الأعلى، تنطبق بعض المتطلبات على مستوى معيّن لكن بشروط أكثر صرامة في المستويات الأعلى.
+
+### تقييم المستويات
+
+تُحدَّد المستويات بتقييم قائم على الأولوية لكل متطلب بناءً على الخبرة في تنفيذ المتطلبات الأمنية واختبارها. والتركيز الرئيسي على مقارنة تقليل المخاطر بالجهد اللازم لتنفيذ المتطلب. وهناك عامل رئيسي آخر هو الحفاظ على حاجز دخول منخفض.
+
+ويراعي تقليل المخاطر مدى تقليل المتطلب لمستوى الخطر الأمني في التطبيق، مع مراعاة عوامل الأثر الكلاسيكية للسرية والسلامة والتوافر، وكذلك النظر في ما إذا كان هذا طبقة دفاع أولية أو يُعدّ دفاعًا في العمق.
+
+وقد أدّت المناقشات الدقيقة حول المعايير وقرارات المستويات على حد سواء إلى توزيع ينبغي أن يصحّ في الأغلبية الساحقة من الحالات، مع الإقرار بأنه قد لا يكون ملائمًا بنسبة 100% لكل وضع. ويعني ذلك أن المؤسسات قد ترغب في حالات معيّنة في إعطاء أولوية أبكر لمتطلبات من مستوى أعلى بناءً على اعتباراتها الخاصة للمخاطر.
+
+ويمكن توصيف أنواع المتطلبات في كل مستوى على النحو التالي.
+
+### المستوى 1
+
+يحتوي هذا المستوى على الحد الأدنى من المتطلبات التي ينبغي مراعاتها عند تأمين تطبيق، ويمثّل نقطة انطلاق بالغة الأهمية. ويحتوي هذا المستوى على نحو 20% من متطلبات معيار التحقق من أمان التطبيقات. والهدف من هذا المستوى أن يكون عدد المتطلبات أقل ما يمكن، لتخفيض حاجز الدخول.
+
+وهذه المتطلبات عمومًا حرجة أو أساسية، وهي متطلبات الطبقة الأولى من الدفاع لمنع الهجمات الشائعة التي لا تتطلّب ثغرات أو شروطًا مسبقة أخرى لتكون قابلة للاستغلال.
+
+وإضافةً إلى متطلبات الطبقة الأولى من الدفاع، هناك متطلبات أقل أثرًا في المستويات الأعلى، مثل المتطلبات المتعلقة بكلمات المرور. وهذه أكثر أهمية في المستوى 1، إذ تصبح متطلبات المصادقة متعددة العوامل ذات صلة من المستويات الأعلى.
+
+والمستوى 1 ليس بالضرورة قابلًا لاختبار الاختراق بواسطة مختبر خارجي دون وصول داخلي إلى الوثائق أو الشيفرة (مثل اختبار "الصندوق الأسود")، وإن كان العدد الأقل من المتطلبات ينبغي أن يسهّل التحقق منه.
+
+### المستوى 2
+
+ينبغي أن تسعى معظم التطبيقات إلى تحقيق هذا المستوى من الأمان. فنحو 50% من متطلبات معيار التحقق من أمان التطبيقات هي من المستوى 2، ما يعني أن التطبيق يحتاج إلى تنفيذ نحو 70% من متطلبات معيار التحقق من أمان التطبيقات (جميع متطلبات المستويين 1 و2) للامتثال للمستوى 2.
+
+وتتعلق هذه المتطلبات عمومًا إما بهجمات أقل شيوعًا أو بحماية أكثر تعقيدًا من الهجمات الشائعة. وقد تكون لا تزال طبقة دفاع أولية، أو قد تتطلّب شروطًا مسبقة معيّنة لنجاح الهجوم.
+
+### المستوى 3
+
+ينبغي أن يكون هذا المستوى هدفًا للتطبيقات التي تسعى إلى إظهار أعلى مستويات الأمان، وهو يوفّر النسبة الأخيرة البالغة نحو 30% من المتطلبات اللازمة للامتثال.
+
+والمتطلبات في هذا القسم عمومًا إما آليات دفاع في العمق أو ضوابط أخرى مفيدة لكن صعبة التنفيذ.
+
+### أي مستوى ينبغي تحقيقه
+
+المقصود من المستويات القائمة على الأولوية أن توفّر انعكاسًا لنضج أمان التطبيقات في المؤسسة وفي التطبيق. وبدلًا من أن ينص معيار التحقق من أمان التطبيقات إلزاميًا على المستوى الذي ينبغي أن يكون التطبيق عليه، ينبغي للمؤسسة أن تحلّل مخاطرها وتقرّر المستوى الذي تعتقد أنه ينبغي أن تكون عليه، بحسب حساسية التطبيق، وبالطبع، توقعات مستخدمي التطبيق.
+
+على سبيل المثال، قد تقرّر شركة ناشئة في مرحلة مبكرة لا تجمع سوى بيانات حساسة محدودة أن تركّز على المستوى 1 لأهدافها الأمنية الأولية، لكن مصرفًا قد يجد صعوبة في تبرير أي شيء أدنى من المستوى 3 لعملائه في تطبيقه للخدمات المصرفية عبر الإنترنت.
+
+## كيفية استخدام معيار التحقق من أمان التطبيقات
+
+### بنية معيار التحقق من أمان التطبيقات
+
+يتكوّن معيار التحقق من أمان التطبيقات من نحو 350 متطلبًا إجمالًا مقسّمة على 17 فصلًا، كل منها مقسّم كذلك إلى أقسام.
+
+والهدف من تقسيم الفصول والأقسام تبسيط اختيار الفصول والأقسام أو تصفيتها بناءً على ما هو ذو صلة بالتطبيق. فعلى سبيل المثال، بالنسبة إلى واجهة برمجة تطبيقات من آلة إلى آلة، لن تكون المتطلبات في الفصل V3 المتعلقة بواجهات الويب الأمامية ذات صلة. وإذا لم يكن هناك استخدام لـ OAuth أو WebRTC، فيمكن تجاهل هذين الفصلين كذلك.
+
+### استراتيجية الإصدار
+
+تتبع إصدارات معيار التحقق من أمان التطبيقات النمط "رئيسي.ثانوي.ترقيعي"، وتوفّر الأرقام معلومات عمّا تغيّر في الإصدار. ففي الإصدار الرئيسي يتغيّر الرقم الأول، وفي الإصدار الثانوي يتغيّر الرقم الثاني، وفي الإصدار الترقيعي يتغيّر الرقم الثالث.
+
+* الإصدار الرئيسي - إعادة تنظيم كاملة، وقد يكون كل شيء تقريبًا قد تغيّر، بما في ذلك أرقام المتطلبات. وسيكون من الضروري إعادة التقييم للامتثال (مثلًا من 4.0.3 إلى 5.0.0).
+* الإصدار الثانوي - قد تُضاف متطلبات أو تُزال، لكن الترقيم العام سيبقى كما هو. وسيكون من الضروري إعادة التقييم للامتثال، لكنه ينبغي أن يكون أسهل (مثلًا من 5.0.0 إلى 5.1.0).
+* الإصدار الترقيعي - قد تُزال متطلبات (مثلًا إذا كانت مكرّرة أو متقادمة) أو تُجعل أقل صرامة، لكن التطبيق الذي امتثل للإصدار السابق سيمتثل للإصدار الترقيعي كذلك (مثلًا من 5.0.0 إلى 5.0.1).
+
+وينطبق ما سبق تحديدًا على المتطلبات في معيار التحقق من أمان التطبيقات. أما التغييرات في النص المحيط وغيره من المحتوى مثل الملاحق فلن تُعدّ تغييرًا قاطعًا للتوافق.
+
+### المرونة في معيار التحقق من أمان التطبيقات
+
+توفّر عدة نقاط من الموصوفة أعلاه، مثل متطلبات التوثيق وآلية المستويات، القدرة على استخدام معيار التحقق من أمان التطبيقات بطريقة أكثر مرونة وأكثر خصوصية بالمؤسسة.
+
+وإضافةً إلى ذلك، تُشجَّع المؤسسات بقوة على إنشاء نسخة متفرّعة خاصة بالمؤسسة أو بالمجال تعدّل المتطلبات بناءً على الخصائص ومستويات المخاطر المحدّدة لتطبيقاتها. لكن من المهم الحفاظ على إمكانية التتبّع بحيث يعني استيفاء المتطلب 4.1.1 الشيء نفسه في جميع الإصدارات.
+
+ومن الأفضل أن تنشئ كل مؤسسة نسخة معيار التحقق من أمان التطبيقات مُصمَّمة لها، مع حذف الأقسام غير ذات الصلة (مثل GraphQL وWebSockets وSOAP إذا لم تكن مستخدمة). كما أن نسخة معيار التحقق من أمان التطبيقات الخاصة بالمؤسسة أو ملحقها موضع جيد كذلك لتقديم إرشادات تنفيذ خاصة بالمؤسسة، تبيّن المكتبات أو الموارد التي ينبغي استخدامها عند الامتثال للمتطلبات.
+
+### كيفية الإشارة إلى متطلبات معيار التحقق من أمان التطبيقات
+
+لكل متطلب معرّف بالصيغة `<chapter>.<section>.<requirement>`، حيث كل عنصر رقم. على سبيل المثال، `1.11.3`.
+
+* تقابل قيمة `<chapter>` الفصل الذي يأتي منه المتطلب؛ فعلى سبيل المثال، جميع المتطلبات `1.#.#` هي من فصل 'الترميز والتنقية'.
+* تقابل قيمة `<section>` القسم داخل ذلك الفصل الذي يظهر فيه المتطلب، فعلى سبيل المثال: جميع المتطلبات `1.2.#` هي في قسم 'منع الحقن' من فصل 'الترميز والتنقية'.
+* تحدّد قيمة `<requirement>` المتطلب بعينه داخل الفصل والقسم، فعلى سبيل المثال `1.2.5` الذي هو، منذ الإصدار 5.0.0 من هذا المعيار:
+
+> تحقق من أن التطبيق يحمي من حقن أوامر نظام التشغيل ومن أن استدعاءات نظام التشغيل تستخدم استعلامات مُمعَّمة لنظام التشغيل أو تستخدم ترميزًا سياقيًا لمخرجات سطر الأوامر.
+
+وبما أن المعرّفات قد تتغيّر بين إصدارات المعيار، فمن الأفضل للمستندات أو التقارير أو الأدوات الأخرى استخدام الصيغة التالية: `v<version>-<chapter>.<section>.<requirement>`، حيث 'الإصدار' هو وسم إصدار معيار التحقق من أمان التطبيقات. على سبيل المثال: يُفهم من `v5.0.0-1.2.5` أنه يعني تحديدًا المتطلب الخامس في قسم 'منع الحقن' من فصل 'الترميز والتنقية' من الإصدار 5.0.0. (ويمكن تلخيص ذلك بالصورة `v<version>-<requirement_identifier>`.)
+
+ملاحظة: ينبغي أن يكون الحرف `v` السابق لرقم الإصدار في هذه الصيغة بحرف صغير دائمًا.
+
+وإذا استُخدمت المعرّفات دون إدراج عنصر `v<version>`، فينبغي افتراض أنها تشير إلى أحدث محتوى لمعيار التحقق من أمان التطبيقات. ومع نمو المعيار وتغيّره يصبح ذلك مشكلًا، ولهذا ينبغي للكتّاب أو المطوّرين إدراج عنصر الإصدار.
+
+وتُتاح قوائم متطلبات معيار التحقق من أمان التطبيقات بصيغ CSV وJSON وغيرها، وقد تكون مفيدة للرجوع إليها أو للاستخدام البرمجي.
+
+### تفريع معيار التحقق من أمان التطبيقات
+
+يمكن للمؤسسات أن تستفيد من تبنّي معيار التحقق من أمان التطبيقات باختيار أحد المستويات الثلاثة أو بإنشاء نسخة متفرّعة خاصة بالمجال تعدّل المتطلبات بحسب مستوى مخاطر التطبيق. وهذا النوع من التفريع مُشجَّع، بشرط أن يحافظ على إمكانية التتبّع بحيث يعني استيفاء المتطلب 4.1.1 الشيء نفسه في جميع الإصدارات.
+
+ومن الأفضل أن تنشئ كل مؤسسة نسخة معيار التحقق من أمان التطبيقات مُصمَّمة لها، مع حذف الأقسام غير ذات الصلة (مثل GraphQL وWebsockets وSOAP إذا لم تكن مستخدمة). وينبغي أن يبدأ التفريع بالمستوى 1 من معيار التحقق من أمان التطبيقات كخط أساس، ثم التقدّم إلى المستويين 2 أو 3 بناءً على مخاطر التطبيق.
+
+## حالات استخدام معيار التحقق من أمان التطبيقات
+
+يمكن استخدام معيار التحقق من أمان التطبيقات لتقييم أمان تطبيق، وهذا مستقصى بعمق أكبر في الفصل التالي. لكن هناك عدة استخدامات محتملة أخرى لمعيار التحقق من أمان التطبيقات (أو لنسخة متفرّعة منه) قد حُدّدت.
+
+### كإرشادات مفصّلة لمعمارية الأمان
+
+من الاستخدامات الأكثر شيوعًا لمعيار التحقق من أمان التطبيقات استخدامه كمورد لمعماريي الأمان. فالموارد المتاحة عن كيفية بناء معمارية تطبيق آمنة محدودة، وخصوصًا مع التطبيقات الحديثة. ويمكن استخدام معيار التحقق من أمان التطبيقات لسدّ هذه الفجوات بتمكين معماريي الأمان من اختيار ضوابط أفضل للمشكلات الشائعة، مثل أنماط حماية البيانات واستراتيجيات التحقق من صحة المدخلات. وستكون متطلبات المعمارية والتوثيق مفيدة لذلك على وجه الخصوص.
+
+### كمرجع متخصّص للبرمجة الآمنة
+
+يمكن استخدام معيار التحقق من أمان التطبيقات كأساس لإعداد مرجع للبرمجة الآمنة أثناء تطوير التطبيقات، بما يساعد المطوّرين على التأكد من أنهم يضعون الأمان في اعتبارهم عند بناء البرمجيات. ومع أن معيار التحقق من أمان التطبيقات يمكن أن يكون الأساس، فينبغي للمؤسسات إعداد إرشاداتها الخاصة التي تكون واضحة وموحّدة، ومن الأفضل أن تُعدّ بناءً على توجيه من مهندسي الأمان أو معماريي الأمان. وكامتداد لذلك، تُشجَّع المؤسسات، حيثما أمكن، على إعداد آليات ومكتبات أمنية معتمدة يمكن الإشارة إليها في الإرشادات واستخدامها من قِبل المطوّرين.
+
+### كدليل لاختبارات الوحدة والتكامل المؤتمتة
+
+صُمِّم معيار التحقق من أمان التطبيقات ليكون قابلًا للاختبار بدرجة عالية. وستكون بعض عمليات التحقق تقنية، في حين قد تتطلّب متطلبات أخرى (مثل متطلبات المعمارية والتوثيق) مراجعة للوثائق أو للمعمارية. وببناء اختبارات وحدة وتكامل تختبر وتُشوّش حالات إساءة استخدام محدّدة وذات صلة بالمتطلبات القابلة للتحقق بوسائل تقنية، ينبغي أن يكون أسهل التحقق من أن هذه الضوابط تعمل على نحو صحيح في كل عملية بناء. فعلى سبيل المثال، يمكن صياغة اختبارات إضافية لمجموعة اختبارات متحكّم تسجيل الدخول، لاختبار معامل اسم المستخدم بحثًا عن أسماء المستخدمين الافتراضية الشائعة وتعداد الحسابات والقوة الغاشمة وحقن LDAP وSQL والبرمجة النصية عبر المواقع. وبالمثل، ينبغي أن يشمل اختبار معامل كلمة المرور كلمات المرور الشائعة وطول كلمة المرور وحقن البايت الفارغ وإزالة المعامل والبرمجة النصية عبر المواقع وغير ذلك.
+
+### للتدريب على التطوير الآمن
+
+يمكن استخدام معيار التحقق من أمان التطبيقات كذلك لتحديد خصائص البرمجيات الآمنة. فكثير من دورات "البرمجة الآمنة" هي مجرّد دورات في الاختراق الأخلاقي مع مسحة خفيفة من نصائح البرمجة. وقد لا يساعد ذلك بالضرورة المطوّرين على كتابة شيفرة أكثر أمانًا. وبدلًا من ذلك، يمكن لدورات التطوير الآمن أن تستخدم معيار التحقق من أمان التطبيقات مع تركيز قوي على الآليات الإيجابية الموجودة فيه، بدلًا من التركيز على الأشياء السلبية العشرة الأولى التي لا ينبغي فعلها. كما أن بنية معيار التحقق من أمان التطبيقات توفّر بنية منطقية للتنقّل بين المواضيع المختلفة عند تأمين تطبيق.
+
+### كإطار لتوجيه شراء البرمجيات الآمنة
+
+يُعدّ معيار التحقق من أمان التطبيقات إطارًا ممتازًا للمساعدة في شراء البرمجيات الآمنة أو شراء خدمات تطوير مخصّصة. فيمكن للمشتري ببساطة أن يضع متطلبًا بأن البرمجية التي يرغب في شرائها يجب أن تكون مطوّرة بمستوى معيار التحقق من أمان التطبيقات س، وأن يطلب من البائع إثبات أن البرمجية تستوفي مستوى معيار التحقق من أمان التطبيقات س.
+
+## تطبيق معيار التحقق من أمان التطبيقات عمليًا
+
+للتهديدات المختلفة دوافع مختلفة. ولبعض الصناعات أصول معلوماتية وتقنية فريدة ومتطلبات امتثال تنظيمية خاصة بالمجال.
+
+وتُشجَّع المؤسسات بقوة على النظر بعمق في خصائص مخاطرها الفريدة بناءً على طبيعة عملها، وأن تحدّد بناءً على تلك المخاطر ومتطلبات العمل مستوى معيار التحقق من أمان التطبيقات الملائم.
diff --git a/5.0/ar/0x04-Assessment_and_Certification.md b/5.0/ar/0x04-Assessment_and_Certification.md
new file mode 100644
index 0000000000..f36d0c4e13
--- /dev/null
+++ b/5.0/ar/0x04-Assessment_and_Certification.md
@@ -0,0 +1,47 @@
+# التقييم وإصدار الشهادات
+
+## موقف OWASP من شهادات معيار التحقق من أمان التطبيقات وعلامات الثقة
+
+إن OWASP، كمؤسسة غير ربحية محايدة تجاه المورّدين، لا تمنح شهادات لأي مورّدين أو مدقّقين أو برمجيات. وأي توكيد أو علامة ثقة أو شهادة تدّعي الامتثال لمعيار التحقق من أمان التطبيقات ليست معتمدة رسميًا من OWASP، ولذلك ينبغي للمؤسسات أن تتوخى الحذر من ادعاءات الأطراف الثالثة بالحصول على شهادة معيار التحقق من أمان التطبيقات.
+
+ويمكن للمؤسسات أن تقدّم خدمات توكيد، بشرط ألا تدّعي حصولها على شهادة رسمية من OWASP.
+
+## كيفية التحقق من الامتثال لمعيار التحقق من أمان التطبيقات
+
+إن معيار التحقق من أمان التطبيقات ليس إلزاميًا بشكل متعمّد بخصوص الطريقة الدقيقة للتحقق من الامتثال على مستوى دليل اختبار. ومع ذلك، من المهم إبراز بعض النقاط الرئيسية.
+
+### إعداد تقارير التحقق
+
+تُبلِّغ تقارير اختبار الاختراق التقليدية عن المشكلات "على سبيل الاستثناء"، فتسرد حالات الفشل فقط. أما تقرير شهادة معيار التحقق من أمان التطبيقات فينبغي أن يشتمل على النطاق، وملخّص لجميع المتطلبات التي فُحصت، والمتطلبات التي رُصدت فيها استثناءات، وإرشادات لمعالجة المشكلات. وقد تكون بعض المتطلبات غير منطبقة (مثل إدارة الجلسات في واجهات برمجة التطبيقات عديمة الحالة)، ويجب الإشارة إلى ذلك في التقرير.
+
+### نطاق التحقق
+
+لن تنفّذ المؤسسة التي تطوّر تطبيقًا جميع المتطلبات عادةً، إذ قد يكون بعضها غير ذي صلة أو أقل أهمية بحسب وظائف التطبيق. وينبغي للمدقّق أن يوضّح نطاق التحقق، بما في ذلك المستوى الذي تسعى المؤسسة إلى تحقيقه والمتطلبات التي أُدرجت. وينبغي أن يكون ذلك من منظور ما أُدرج بدلًا من ما لم يُدرج. كما ينبغي له أن يقدّم رأيًا في مبرّرات استثناء المتطلبات التي لم تُنفَّذ.
+
+وهذا ينبغي أن يمكّن مستهلك تقرير التحقق من فهم سياق التحقق واتخاذ قرار مستنير بشأن مستوى الثقة الذي يمكن أن يوليه للتطبيق.
+
+ويمكن للمؤسسات المانحة للشهادات أن تختار طرائق اختبارها، لكن ينبغي لها الإفصاح عنها في التقرير، ومن المستحسن أن تكون قابلة للتكرار. وقد تُستخدم طرائق مختلفة، مثل اختبارات الاختراق اليدوية أو تحليل الشيفرة المصدرية، للتحقق من جوانب مثل التحقق من صحة المدخلات، وذلك بحسب التطبيق والمتطلبات.
+
+### آليات التحقق
+
+هناك عدد من التقنيات المختلفة التي قد تكون لازمة للتحقق من متطلبات معيار التحقق من أمان التطبيقات المحدّدة. وإلى جانب اختبار الاختراق (باستخدام بيانات اعتماد صحيحة للحصول على تغطية كاملة للتطبيق)، قد يتطلّب التحقق من متطلبات معيار التحقق من أمان التطبيقات الوصول إلى الوثائق والشيفرة المصدرية والتكوين والأشخاص المشاركين في عملية التطوير. وخصوصًا للتحقق من متطلبات المستويين 2 و3. ومن الممارسات المتّبعة تقديم أدلة قوية على النتائج مع توثيق مفصّل، قد يشمل أوراق العمل ولقطات الشاشة والنصوص البرمجية وسجلات الاختبار. ولا يكفي مجرّد تشغيل أداة مؤتمتة دون اختبار شامل للحصول على الشهادة، إذ يجب اختبار كل متطلب على نحو قابل للتحقق.
+
+إن استخدام الأتمتة للتحقق من متطلبات معيار التحقق من أمان التطبيقات موضوع يثير الاهتمام باستمرار. ولذلك من المهم توضيح بعض النقاط المتعلقة بالاختبار المؤتمت واختبار الصندوق الأسود.
+
+#### دور أدوات اختبار الأمان المؤتمتة
+
+عندما تُنفَّذ أدوات اختبار الأمان المؤتمتة، مثل أدوات الاختبار الديناميكي والساكن لأمان التطبيقات (DAST وSAST)، تنفيذًا صحيحًا في خط بناء البرمجيات، فقد تتمكّن من تحديد بعض المشكلات الأمنية التي لا ينبغي أن توجد أبدًا. لكنها من دون تكوين وضبط دقيقين لن توفّر التغطية المطلوبة، وسيمنع مستوى الضجيج تحديد المشكلات الأمنية الحقيقية والتخفيف منها.
+
+ومع أن ذلك قد يوفّر تغطية لبعض المتطلبات التقنية الأبسط والأكثر مباشرة، مثل تلك المتعلقة بترميز المخرجات أو التنقية، فمن الأهمية البالغة ملاحظة أن هذه الأدوات ستكون عاجزة تمامًا عن التحقق من كثير من متطلبات معيار التحقق من أمان التطبيقات الأكثر تعقيدًا أو تلك المتعلقة بمنطق العمل والتحكم في الوصول.
+
+وبالنسبة إلى المتطلبات الأقل مباشرة، من المرجّح أنه لا يزال بالإمكان الاستفادة من الأتمتة، لكن سيتعيّن كتابة عمليات تحقق خاصة بالتطبيق لتحقيق ذلك. وقد تكون هذه مشابهة لاختبارات الوحدة والتكامل التي ربما تستخدمها المؤسسة بالفعل. ولذلك قد يكون من الممكن استخدام هذه البنية التحتية القائمة لأتمتة الاختبارات في كتابة اختبارات معيار التحقق من أمان التطبيقات هذه. ومع أن القيام بذلك سيتطلّب استثمارًا قصير الأجل، فإن الفوائد طويلة الأجل للقدرة على التحقق المستمر من متطلبات معيار التحقق من أمان التطبيقات هذه ستكون كبيرة.
+
+وخلاصة القول، القابلية للاختبار باستخدام الأتمتة لا تساوي تشغيل أداة جاهزة.
+
+#### دور اختبار الاختراق
+
+مع أن المستوى 1 في الإصدار 4.0 كان مُهيّأً لإجراء اختبار "الصندوق الأسود" (دون وثائق ودون شيفرة مصدرية)، فقد كان المعيار واضحًا حتى في ذلك الحين في أن هذا ليس نشاط توكيد فعّالًا وينبغي الإثناء عنه بفعالية.
+
+إن الاختبار دون الوصول إلى المعلومات الإضافية اللازمة آلية غير كفؤة وغير فعّالة للتحقق الأمني، إذ يفوّت إمكانية مراجعة الشيفرة المصدرية وتحديد التهديدات والضوابط المفقودة وإجراء اختبار أكثر شمولًا بكثير في إطار زمني أقصر.
+
+ويُشجَّع بقوة على إجراء اختبار اختراق مبني على الوثائق أو الشيفرة المصدرية (هجين)، يتيح وصولًا كاملًا إلى مطوّري التطبيق ووثائق التطبيق، بدلًا من اختبارات الاختراق التقليدية. وسيكون ذلك ضروريًا بالتأكيد للتحقق من كثير من متطلبات معيار التحقق من أمان التطبيقات.
diff --git a/5.0/ar/0x05-For-Users-Of-4.0.md b/5.0/ar/0x05-For-Users-Of-4.0.md
new file mode 100644
index 0000000000..5dac810404
--- /dev/null
+++ b/5.0/ar/0x05-For-Users-Of-4.0.md
@@ -0,0 +1,90 @@
+# التغييرات مقارنةً بالإصدار 4.x
+
+## مقدمة
+
+قد يجد المستخدمون المعتادون على الإصدار 4.x من المعيار أنه من المفيد مراجعة التغييرات الرئيسية المُدخلة في الإصدار 5.0، بما فيها التحديثات في المحتوى والنطاق والفلسفة الأساسية.
+
+ومن بين 286 متطلبًا في الإصدار 4.0.3، بقي 11 متطلبًا فقط دون تغيير، في حين خضع 15 متطلبًا لتعديلات نحوية طفيفة دون تغيير معناها. وإجمالًا، لم يعد 109 متطلبات (38%) متطلبات منفصلة في الإصدار 5.0، إذ حُذف 50 منها ببساطة، وأُزيل 28 كمكرّرات، ودُمج 31 في متطلبات أخرى. أما الباقي فقد نُقّح بصورة ما. وحتى المتطلبات التي لم تُعدَّل جوهريًا لها معرّفات مختلفة بسبب إعادة الترتيب أو إعادة الهيكلة.
+
+ولتيسير تبنّي الإصدار 5.0، تُوفَّر مستندات تخطيط لمساعدة المستخدمين على تتبّع كيفية تقابل متطلبات الإصدار 4.x مع متطلبات الإصدار 5.0. وهذه التخطيطات غير مرتبطة بترقيم الإصدارات وقد تُحدَّث أو تُوضَّح حسب الحاجة.
+
+## فلسفة المتطلبات
+
+### النطاق والتركيز
+
+اشتمل الإصدار 4.x على متطلبات لم تتوافق مع النطاق المقصود للمعيار؛ وقد أُزيلت هذه المتطلبات. كما استُثنيت المتطلبات التي لم تستوف معايير النطاق للإصدار 5.0 أو التي لم تكن قابلة للتحقق.
+
+### التأكيد على الأهداف الأمنية بدلًا من الآليات
+
+في الإصدار 4.x، ركّز كثير من المتطلبات على آليات معيّنة بدلًا من الأهداف الأمنية الأساسية. وفي الإصدار 5.0، تتمحور المتطلبات حول الأهداف الأمنية، مع الإشارة إلى آليات بعينها فقط عندما تكون الحل العملي الوحيد، أو تقديمها كأمثلة أو إرشادات تكميلية.
+
+ويقرّ هذا المنهج بأنه قد توجد طرائق متعددة لتحقيق هدف أمني معيّن، ويتجنّب الإلزام غير الضروري الذي قد يحدّ من مرونة المؤسسات.
+
+وإضافةً إلى ذلك، دُمجت المتطلبات التي تتناول الشأن الأمني نفسه حيث كان ذلك ملائمًا.
+
+### القرارات الأمنية الموثّقة
+
+مع أن مفهوم القرارات الأمنية الموثّقة قد يبدو جديدًا في الإصدار 5.0، فهو تطوّر لمتطلبات سابقة متعلقة بتطبيق السياسات ونمذجة التهديدات في الإصدار 4.0. فقد كانت بعض المتطلبات سابقًا تقتضي ضمنيًا إجراء تحليل لتوجيه تنفيذ ضوابط الأمان، مثل تحديد اتصالات الشبكة المسموح بها.
+
+وللتأكد من توافر المعلومات اللازمة للتنفيذ والتحقق، صارت هذه التوقعات مُعرَّفة صراحةً كمتطلبات توثيق، ما يجعلها واضحة وقابلة للتنفيذ وقابلة للتحقق.
+
+## التغييرات الهيكلية والفصول الجديدة
+
+تقدّم عدة فصول في الإصدار 5.0 محتوى جديدًا كليًا:
+
+* OAuth وOIDC – نظرًا للتبنّي الواسع لهذين البروتوكولين لتفويض الوصول والدخول الموحّد، أُضيفت متطلبات مخصّصة لتناول السيناريوهات المتنوعة التي قد يواجهها المطوّرون. وقد يتطوّر هذا المجال في النهاية إلى معيار قائم بذاته، على نحو شبيه بمعالجة متطلبات الأجهزة المحمولة وإنترنت الأشياء في الإصدارات السابقة.
+* WebRTC – مع تزايد شعبية هذه التقنية، تُتناول الآن اعتباراتها وتحدياتها الأمنية الفريدة في قسم مخصّص.
+
+وقد بُذلت جهود كذلك للتأكد من أن الفصول والأقسام منظّمة حول مجموعات متسقة من المتطلبات المترابطة.
+
+وقد أدّت إعادة الهيكلة هذه إلى إنشاء فصول إضافية:
+
+* الرموز المميزة المكتفية بذاتها – كانت مصنّفة سابقًا تحت إدارة الجلسات، وصارت الرموز المميزة المكتفية بذاتها تُعدّ الآن آلية متمايزة وعنصرًا أساسيًا للاتصال عديم الحالة (كما في OAuth وOIDC). ونظرًا لتبعاتها الأمنية الفريدة، تُتناول في فصل مخصّص، مع إدخال بعض المتطلبات الجديدة في الإصدار 5.x.
+* أمان واجهة الويب الأمامية – مع تزايد تعقيد التطبيقات القائمة على المتصفح وصعود المعماريات القائمة على واجهات برمجة التطبيقات فقط، فُصلت متطلبات أمان الواجهة الأمامية في فصل خاص بها.
+* البرمجة الآمنة والمعمارية – جُمعت هنا المتطلبات الجديدة التي تتناول ممارسات أمنية عامة لم تكن تندرج في الفصول القائمة.
+
+وقد أُجريت تغييرات تنظيمية أخرى في الإصدار 5.0 لتوضيح المقصد. على سبيل المثال، نُقلت متطلبات التحقق من صحة المدخلات إلى جانب منطق العمل، بما يجسّد دورها في إنفاذ قواعد العمل، بدلًا من تصنيفها مع التنقية والترميز.
+
+وقد أُزيل فصل V1 المعمارية السابق. فقد احتوى قسمه الأول على متطلبات كانت خارج النطاق، في حين أُعيد توزيع الأقسام اللاحقة على الفصول المعنية، مع إزالة تكرار المتطلبات وتوضيحها حسب الضرورة.
+
+## إزالة التخطيطات المباشرة إلى المعايير الأخرى
+
+أُزيلت التخطيطات المباشرة إلى المعايير الأخرى من المتن الرئيسي للمعيار. والهدف إعداد تخطيط مع مشروع تعداد المتطلبات المشتركة (CRE) الخاص بـ OWASP، والذي سيربط بدوره معيار التحقق من أمان التطبيقات بمجموعة من مشاريع OWASP والمعايير الخارجية.
+
+ولم تعد التخطيطات المباشرة إلى CWE وNIST مُصانة، على النحو الموضّح أدناه.
+
+### تقليل الارتباط بإرشادات الهوية الرقمية من NIST
+
+لطالما شكّلت [إرشادات الهوية الرقمية (SP 800-63)](https://pages.nist.gov/800-63-3/) الصادرة عن NIST مرجعًا لضوابط المصادقة والتخويل. وفي الإصدار 4.x، كانت فصول معيّنة متوافقة على نحو وثيق مع بنية NIST ومصطلحاتها.
+
+ومع أن هذه الإرشادات تبقى مرجعًا مهمًا، فقد أدّى التوافق الصارم إلى تحديات، منها مصطلحات أقل شيوعًا في التعارف، وتكرار متطلبات متشابهة، وتخطيطات غير كاملة. ويبتعد الإصدار 5.0 عن هذا المنهج لتحسين الوضوح والصلة.
+
+### الابتعاد عن تعداد نقاط الضعف الشائعة (CWE)
+
+يوفّر [تعداد نقاط الضعف الشائعة (CWE)](https://cwe.mitre.org/) تصنيفًا مفيدًا لنقاط ضعف أمان البرمجيات. لكن تحديات مثل مُدخلات CWE التي هي فئات فقط، وصعوبات تخطيط المتطلبات إلى CWE واحد، ووجود تخطيطات غير دقيقة في الإصدار 4.x، أدّت إلى قرار إيقاف التخطيطات المباشرة إلى CWE في الإصدار 5.0.
+
+## إعادة النظر في تعريفات المستويات
+
+وصف الإصدار 4.x المستويات بأنها المستوى 1 ("الأدنى") والمستوى 2 ("القياسي") والمستوى 3 ("المتقدّم")، مع ما يفهم منه أن جميع التطبيقات التي تتعامل مع بيانات حساسة ينبغي أن تستوفي المستوى 2 على الأقل.
+
+ويعالج الإصدار 5.0 عدة مشكلات في هذا المنهج، وهي موصوفة في الفقرات التالية.
+
+ومن الناحية العملية، في حين استخدم الإصدار 4.x علامات الاختيار كمؤشرات للمستويات، يستخدم الإصدار 5.x رقمًا بسيطًا في جميع صيغ المعيار، بما فيها markdown وPDF وDOCX وCSV وJSON وXML. وللتوافق مع الإصدارات السابقة، تُولَّد كذلك إصدارات قديمة من مخرجات CSV وJSON وXML التي لا تزال تستخدم علامات الاختيار.
+
+### مستوى دخول أسهل
+
+أشارت التعليقات إلى أن العدد الكبير من متطلبات المستوى 1 (نحو 120)، مقترنًا بتصنيفه كالمستوى "الأدنى" الذي لا يكفي لمعظم التطبيقات، قد أثنى عن التبنّي. ويهدف الإصدار 5.0 إلى تخفيض هذا الحاجز بتعريف المستوى 1 أساسًا حول متطلبات الدفاع في الطبقة الأولى، ما ينتج عنه متطلبات أوضح وأقل عددًا في ذلك المستوى. ولبيان ذلك عدديًا، كان في الإصدار 4.0.3 عدد 128 متطلبًا للمستوى 1 من أصل 278 متطلبًا، أي ما يمثّل 46%. وفي الإصدار 5.0.0 هناك 70 متطلبًا للمستوى 1 من أصل 345 متطلبًا، أي ما يمثّل 20%.
+
+### مغالطة القابلية للاختبار
+
+كان أحد العوامل الرئيسية في انتقاء الضوابط للمستوى 1 في الإصدار 4.x ملاءمتها للتقييم عن طريق اختبار الاختراق الخارجي بمنهج "الصندوق الأسود". لكن هذا المنهج لم يتوافق تمامًا مع مقصد المستوى 1 كالمجموعة الأدنى من ضوابط الأمان. فقد رأى بعض المستخدمين أن المستوى 1 غير كافٍ لتأمين التطبيقات، في حين وجده آخرون صعب الاختبار للغاية.
+
+والتعويل على القابلية للاختبار كمعيار أمر نسبي ومُضلِّل أحيانًا. فكون المتطلب قابلًا للاختبار لا يضمن إمكانية اختباره بطريقة مؤتمتة أو مباشرة. وعلاوة على ذلك، ليست المتطلبات الأسهل اختبارًا هي دائمًا تلك ذات الأثر الأمني الأكبر أو الأبسط تنفيذًا.
+
+ولذلك، في الإصدار 5.0، اتُّخذت قرارات المستويات أساسًا على أساس تقليل المخاطر، مع مراعاة الجهد اللازم للتنفيذ كذلك.
+
+### ليس الأمر متعلقًا بالمخاطر وحدها
+
+لقد ثبت أن استخدام مستويات إلزامية مبنية على المخاطر تفرض مستوى معيّنًا لتطبيقات بعينها مفرط الصلابة. فمن الناحية العملية، يعتمد ترتيب أولويات ضوابط الأمان وتنفيذها على عوامل متعددة، منها تقليل المخاطر والجهد اللازم للتنفيذ على حد سواء.
+
+ولذلك تُشجَّع المؤسسات على تحقيق المستوى الذي تشعر أنه ينبغي لها تحقيقه بناءً على نضجها والرسالة التي تريد إيصالها إلى مستخدميها.
diff --git a/5.0/ar/0x10-V1-Encoding-and-Sanitization.md b/5.0/ar/0x10-V1-Encoding-and-Sanitization.md
new file mode 100644
index 0000000000..574a03ebed
--- /dev/null
+++ b/5.0/ar/0x10-V1-Encoding-and-Sanitization.md
@@ -0,0 +1,103 @@
+# V1 الترميز والتنقية
+
+## الهدف من ضوابط الأمان
+
+يتناول هذا الفصل أكثر نقاط ضعف أمان تطبيقات الويب شيوعًا فيما يتصل بالمعالجة غير الآمنة للبيانات غير الموثوقة. ويمكن أن تؤدي نقاط الضعف هذه إلى ثغرات تقنية متنوعة، تُفسَّر فيها البيانات غير الموثوقة وفق قواعد صياغة المُفسِّر المعني.
+
+وبالنسبة إلى تطبيقات الويب الحديثة، من الأفضل دائمًا استخدام واجهات برمجة تطبيقات أكثر أمانًا، مثل الاستعلامات المُمعَّمة أو الإفلات التلقائي أو أُطر القوالب. وبخلاف ذلك، يصبح الترميز أو الإفلات أو التنقية المُنفَّذة بعناية على المخرجات أمرًا بالغ الأهمية لأمان التطبيق.
+
+ويعمل التحقق من صحة المدخلات كآلية دفاع في العمق للحماية من المحتوى غير المتوقع أو الخطير. لكن، بما أن غرضه الأساسي هو ضمان تطابق المحتوى الوارد مع التوقعات الوظيفية والتجارية، فإن المتطلبات المتعلقة بذلك يمكن العثور عليها في فصل "التحقق من الصحة ومنطق العمل".
+
+## V1.1 معمارية الترميز والتنقية
+
+في الأقسام أدناه، تُقدَّم متطلبات خاصة بالصياغة أو بالمُفسِّر لمعالجة المحتوى غير الآمن بأمان لتجنّب الثغرات الأمنية. وتتناول متطلبات هذا القسم الترتيب الذي ينبغي أن تحدث به هذه المعالجة والموضع الذي ينبغي أن تحدث فيه. وتهدف كذلك إلى ضمان أن البيانات، عند تخزينها، تبقى في حالتها الأصلية ولا تُخزَّن في صورة مُرمَّزة أو مُفلَتة (مثل ترميز HTML)، وذلك لمنع مشكلات الترميز المزدوج.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **1.1.1** | تحقق من أن المدخلات تُفكّ ترميزها أو يُلغى إفلاتها إلى صورة قياسية مرة واحدة فقط، ومن أنها لا تُفكّ إلا عندما تكون البيانات المُرمَّزة بهذه الصورة متوقعة، ومن أن ذلك يحدث قبل معالجة المدخلات أكثر، أي أنه لا يُنفَّذ بعد التحقق من صحة المدخلات أو تنقيتها. | 2 |
+| **1.1.2** | تحقق من أن التطبيق ينفّذ ترميز المخرجات وإفلاتها إما كخطوة أخيرة قبل استخدامها بواسطة المُفسِّر المقصود لها أو بواسطة المُفسِّر نفسه. | 2 |
+
+## V1.2 منع الحقن
+
+إن ترميز المخرجات أو إفلاتها، المُنفَّذ قريبًا من سياق خطير محتمل أو ملاصقًا له، بالغ الأهمية لأمان أي تطبيق. وعادةً لا يُحفَظ ترميز المخرجات وإفلاتها، بل يُستخدمان لجعل المخرجات آمنة للاستخدام الفوري في المُفسِّر الملائم. وقد تؤدي محاولة تنفيذ ذلك مبكرًا جدًا إلى محتوى مشوّه أو إلى جعل الترميز أو الإفلات غير فعّال.
+
+وفي حالات كثيرة، تتضمّن مكتبات البرمجيات دوالّ آمنة أو أكثر أمانًا تنفّذ ذلك تلقائيًا، وإن كان من الضروري التأكد من صحتها للسياق الراهن.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **1.2.1** | تحقق من أن ترميز المخرجات لاستجابة HTTP أو مستند HTML أو مستند XML ملائم للسياق المطلوب، مثل ترميز المحارف المعنية لعناصر HTML أو سماتها أو تعليقاتها أو لـ CSS أو حقول ترويسة HTTP، وذلك لتجنّب تغيير بنية الرسالة أو المستند. | 1 |
+| **1.2.2** | تحقق من أن البيانات غير الموثوقة، عند بناء عناوين URL ديناميكيًا، تُرمَّز وفق سياقها (مثل ترميز URL أو ترميز base64url لمعاملات الاستعلام أو المسار). وتأكّد من أن بروتوكولات URL الآمنة هي وحدها المسموح بها (مثلًا منع javascript: أو data:). | 1 |
+| **1.2.3** | تحقق من استخدام ترميز المخرجات أو إفلاتها عند بناء محتوى JavaScript ديناميكيًا (بما في ذلك JSON)، وذلك لتجنّب تغيير بنية الرسالة أو المستند (لتجنّب حقن JavaScript وJSON). | 1 |
+| **1.2.4** | تحقق من أن انتقاء البيانات أو استعلامات قواعد البيانات (مثل SQL وHQL وNoSQL وCypher) تستخدم استعلامات مُمعَّمة أو أنظمة ORM أو أُطر الكيانات، أو أنها محمية بطريقة أخرى من حقن SQL وغيره من هجمات حقن قواعد البيانات. وهذا ذو صلة كذلك عند كتابة الإجراءات المخزَّنة. | 1 |
+| **1.2.5** | تحقق من أن التطبيق يحمي من حقن أوامر نظام التشغيل ومن أن استدعاءات نظام التشغيل تستخدم استعلامات مُمعَّمة لنظام التشغيل أو تستخدم ترميزًا سياقيًا لمخرجات سطر الأوامر. | 1 |
+| **1.2.6** | تحقق من أن التطبيق يحمي من ثغرات حقن LDAP، أو من أن ضوابط أمنية محدّدة لمنع حقن LDAP قد نُفِّذت. | 2 |
+| **1.2.7** | تحقق من أن التطبيق محمي من هجمات حقن XPath باستخدام تمعيم الاستعلامات أو الاستعلامات المُصرَّفة مسبقًا. | 2 |
+| **1.2.8** | تحقق من أن معالجات LaTeX مُهيّأة بأمان (مثل عدم استخدام العَلَم "--shell-escape") ومن استخدام قائمة سماح بالأوامر لمنع هجمات حقن LaTeX. | 2 |
+| **1.2.9** | تحقق من أن التطبيق يُفلت المحارف الخاصة في التعبيرات النمطية (عادةً باستخدام شرطة مائلة عكسية) لمنع تفسيرها خطأً كمحارف وصفية. | 2 |
+| **1.2.10** | تحقق من أن التطبيق محمي من حقن CSV والصيغ. ويجب أن يتّبع التطبيق قواعد الإفلات المحدّدة في RFC 4180 القسمين 2.6 و2.7 عند تصدير محتوى CSV. وإضافةً إلى ذلك، عند التصدير إلى CSV أو غيره من صيغ جداول البيانات (مثل XLS أو XLSX أو ODF)، يجب إفلات المحارف الخاصة (بما فيها '=' و'+' و'-' و'@' و'\t' (مسافة جدولة) و'\0' (محرف فارغ)) بعلامة اقتباس مفردة إذا ظهرت كأول محرف في قيمة حقل. | 3 |
+
+ملاحظة: استخدام الاستعلامات المُمعَّمة أو إفلات SQL ليس كافيًا دائمًا. فأجزاء الاستعلام مثل أسماء الجداول والأعمدة (بما فيها أسماء أعمدة "ORDER BY") لا يمكن إفلاتها. وإدراج بيانات مُفلَتة مقدَّمة من المستخدم في هذه الحقول يؤدي إلى استعلامات فاشلة أو إلى حقن SQL.
+
+## V1.3 التنقية
+
+الحماية المثالية من استخدام محتوى غير موثوق في سياق غير آمن هي استخدام ترميز أو إفلات خاص بالسياق، يحافظ على المعنى الدلالي نفسه للمحتوى غير الآمن لكنه يجعله آمنًا للاستخدام في ذلك السياق بعينه، على النحو المبيّن بتفصيل أكبر في القسم السابق.
+
+وحيث لا يكون ذلك ممكنًا، تصبح التنقية ضرورية، بإزالة المحارف أو المحتوى الخطير المحتمل. وقد يغيّر ذلك في بعض الحالات المعنى الدلالي للمُدخل، لكن لأسباب أمنية قد لا يكون هناك بديل.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **1.3.1** | تحقق من أن جميع مدخلات HTML غير الموثوقة الواردة من محرّرات "ما تراه هو ما تحصل عليه" أو ما شابهها تُنقّى باستخدام مكتبة تنقية HTML معروفة وآمنة أو ميزة في إطار العمل. | 1 |
+| **1.3.2** | تحقق من أن التطبيق يتجنّب استخدام eval() أو غيره من ميزات تنفيذ الشيفرة الديناميكية مثل لغة تعبيرات Spring (SpEL). وحيث لا يوجد بديل، يجب تنقية أي مدخلات مستخدم تُضمَّن قبل تنفيذها. | 1 |
+| **1.3.3** | تحقق من أن البيانات المُمرَّرة إلى سياق خطير محتمل تُنقّى مسبقًا لإنفاذ تدابير السلامة، مثل السماح بالمحارف الآمنة لهذا السياق فقط وتقليم المدخلات المفرطة الطول. | 2 |
+| **1.3.4** | تحقق من أن محتوى الرسوميات المتجهية القابلة للتحجيم (SVG) القابل للبرمجة والمقدَّم من المستخدم يُتحقَّق من صحته أو يُنقّى بحيث لا يحتوي إلا على الوسوم والسمات (مثل رسم الرسوميات) الآمنة للتطبيق، أي مثلًا لا يحتوي على نصوص برمجية أو foreignObject. | 2 |
+| **1.3.5** | تحقق من أن التطبيق يُنقّي أو يعطّل المحتوى القابل للبرمجة أو محتوى لغات قوالب التعبيرات المقدَّم من المستخدم، مثل Markdown أو أوراق أنماط CSS أو XSL أو BBCode أو ما شابهها. | 2 |
+| **1.3.6** | تحقق من أن التطبيق يحمي من هجمات تزوير الطلب من جانب الخادم (SSRF)، وذلك بالتحقق من البيانات غير الموثوقة مقابل قائمة سماح بالبروتوكولات والنطاقات والمسارات والمنافذ، وتنقية المحارف الخطيرة المحتملة قبل استخدام البيانات لاستدعاء خدمة أخرى. | 2 |
+| **1.3.7** | تحقق من أن التطبيق يحمي من هجمات حقن القوالب بعدم السماح ببناء القوالب على أساس مدخلات غير موثوقة. وحيث لا يوجد بديل، يجب تنقية أي مدخلات غير موثوقة تُضمَّن ديناميكيًا أثناء إنشاء القالب أو التحقق منها بصرامة. | 2 |
+| **1.3.8** | تحقق من أن التطبيق يُنقّي المدخلات غير الموثوقة على النحو الملائم قبل استخدامها في استعلامات واجهة التسمية والدليل في Java (JNDI)، ومن أن JNDI مُهيّأة بأمان لمنع هجمات حقن JNDI. | 2 |
+| **1.3.9** | تحقق من أن التطبيق يُنقّي المحتوى قبل إرساله إلى memcache لمنع هجمات الحقن. | 2 |
+| **1.3.10** | تحقق من أن سلاسل التنسيق التي قد تُحلّ بطريقة غير متوقعة أو خبيثة عند استخدامها تُنقّى قبل معالجتها. | 2 |
+| **1.3.11** | تحقق من أن التطبيق يُنقّي مدخلات المستخدم قبل تمريرها إلى أنظمة البريد للحماية من حقن SMTP أو IMAP. | 2 |
+| **1.3.12** | تحقق من أن التعبيرات النمطية خالية من العناصر المسبّبة للتراجع الأُسّي، وتأكّد من تنقية المدخلات غير الموثوقة للتخفيف من هجمات ReDoS أو التعبيرات النمطية الشاردة. | 3 |
+
+## V1.4 الذاكرة والسلاسل والشيفرة غير المُدارة
+
+تتناول المتطلبات التالية المخاطر المرتبطة بالاستخدام غير الآمن للذاكرة، وهي تنطبق عمومًا عندما يستخدم التطبيق لغة أنظمة أو شيفرة غير مُدارة.
+
+وقد يكون من الممكن في بعض الحالات تحقيق ذلك بضبط أعلام المُصرِّف التي تُمكّن الحماية من فيضان المخزن المؤقت والتحذيرات، بما في ذلك عشوائية المكدّس ومنع تنفيذ البيانات، والتي تُفشل عملية البناء إذا وُجدت عمليات غير آمنة على المؤشرات أو الذاكرة أو سلاسل التنسيق أو الأعداد الصحيحة أو السلاسل.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **1.4.1** | تحقق من أن التطبيق يستخدم سلاسل آمنة للذاكرة ونسخًا أكثر أمانًا للذاكرة وحسابًا للمؤشرات لكشف فيضانات المكدّس أو المخزن المؤقت أو الكومة أو منعها. | 2 |
+| **1.4.2** | تحقق من استخدام تقنيات التحقق من الإشارة والنطاق والمدخلات لمنع فيضان الأعداد الصحيحة. | 2 |
+| **1.4.3** | تحقق من تحرير الذاكرة والموارد المخصّصة ديناميكيًا، ومن إزالة المراجع أو المؤشرات إلى الذاكرة المُحرَّرة أو تعيينها إلى null لمنع المؤشرات المعلّقة وثغرات الاستخدام بعد التحرير. | 2 |
+
+## V1.5 فك التسلسل الآمن
+
+إن تحويل البيانات من صورة مخزَّنة أو منقولة إلى كائنات تطبيق فعلية (فك التسلسل) كان تاريخيًا سببًا لثغرات حقن شيفرة متنوعة. ومن المهم تنفيذ هذه العملية بعناية وأمان لتجنّب هذه الأنواع من المشكلات.
+
+وعلى وجه الخصوص، حُدّدت طرائق معيّنة لفك التسلسل في وثائق لغات البرمجة أو أُطر العمل بأنها غير آمنة ولا يمكن جعلها آمنة مع البيانات غير الموثوقة. ولكل آلية قيد الاستخدام، ينبغي إجراء تحرٍّ دقيق.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **1.5.1** | تحقق من أن التطبيق يهيّئ مُحلِّلات XML لاستخدام تكوين تقييدي ومن أن الميزات غير الآمنة، مثل حلّ الكيانات الخارجية، معطّلة لمنع هجمات كيان XML الخارجي (XXE). | 1 |
+| **1.5.2** | تحقق من أن فك تسلسل البيانات غير الموثوقة يُنفِذ معالجة آمنة للمدخلات، مثل استخدام قائمة سماح بأنواع الكائنات أو تقييد أنواع الكائنات التي يحدّدها العميل، وذلك لمنع هجمات فك التسلسل. ويجب ألا تُستخدم آليات فك التسلسل المُعرَّفة صراحةً بأنها غير آمنة مع مدخلات غير موثوقة. | 2 |
+| **1.5.3** | تحقق من أن المُحلِّلات المختلفة المستخدمة في التطبيق لنوع البيانات نفسه (مثل مُحلِّلات JSON ومُحلِّلات XML ومُحلِّلات URL) تُنفِّذ التحليل بطريقة متسقة وتستخدم آلية ترميز المحارف نفسها، وذلك لتجنّب مشكلات مثل ثغرات قابلية التشغيل المتبادل في JSON أو استغلال اختلاف سلوك تحليل معرّفات الموارد أو الملفات في هجمات تضمين الملفات البعيدة (RFI) أو تزوير الطلب من جانب الخادم (SSRF). | 3 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP LDAP Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html)
+* [OWASP Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
+* [OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html)
+* [OWASP XML External Entity Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html)
+* [OWASP Web Security Testing Guide: Client-Side Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing)
+* [OWASP Java Encoding Project](https://owasp.org/owasp-java-encoder/)
+* [DOMPurify - Client-side HTML Sanitization Library](https://github.com/cure53/DOMPurify)
+* [RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files](https://datatracker.ietf.org/doc/html/rfc4180#section-2)
+
+ولمزيد من المعلومات، وتحديدًا عن مشكلات فك التسلسل أو التحليل، يُرجى الاطلاع على:
+
+* [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)
+* [An Exploration of JSON Interoperability Vulnerabilities](https://bishopfox.com/blog/json-interoperability-vulnerabilities)
+* [Orange Tsai - A New Era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf)
diff --git a/5.0/ar/0x11-V2-Validation-and-Business-Logic.md b/5.0/ar/0x11-V2-Validation-and-Business-Logic.md
new file mode 100644
index 0000000000..611d653a76
--- /dev/null
+++ b/5.0/ar/0x11-V2-Validation-and-Business-Logic.md
@@ -0,0 +1,73 @@
+# V2 التحقق من الصحة ومنطق العمل
+
+## الهدف من ضوابط الأمان
+
+يهدف هذا الفصل إلى ضمان أن التطبيق المتحقَّق منه يحقّق الأهداف الرفيعة المستوى التالية:
+
+* أن تتوافق المدخلات التي يستقبلها التطبيق مع التوقعات التجارية أو الوظيفية.
+* أن يكون سير منطق العمل تسلسليًا، ويُعالَج بالترتيب، ولا يمكن تجاوزه.
+* أن يشتمل منطق العمل على حدود وضوابط لكشف الهجمات المؤتمتة ومنعها، مثل التحويلات المالية الصغيرة المتواصلة أو إضافة مليون صديق واحدًا تلو الآخر.
+* أن تكون مسارات منطق العمل عالية القيمة قد راعت حالات إساءة الاستخدام والجهات الخبيثة، وأن تتوافر لها حماية من هجمات التنكّر والتلاعب وكشف المعلومات وتصعيد الصلاحيات.
+
+## V2.1 توثيق التحقق من الصحة ومنطق العمل
+
+ينبغي أن يحدّد توثيق التحقق من الصحة ومنطق العمل بوضوح حدود منطق العمل وقواعد التحقق من الصحة والاتساق السياقي لعناصر البيانات المجتمعة، بحيث يكون واضحًا ما يلزم تنفيذه في التطبيق.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **2.1.1** | تحقق من أن وثائق التطبيق تحدّد قواعد التحقق من صحة المدخلات لبيان كيفية فحص صلاحية عناصر البيانات مقابل بنية متوقعة. وقد تكون هذه صيغ بيانات شائعة مثل أرقام بطاقات الائتمان أو عناوين البريد الإلكتروني أو أرقام الهاتف، أو قد تكون صيغة بيانات داخلية. | 1 |
+| **2.1.2** | تحقق من أن وثائق التطبيق تحدّد كيفية التحقق من الاتساق المنطقي والسياقي لعناصر البيانات المجتمعة، مثل فحص تطابق الحي والرمز البريدي. | 2 |
+| **2.1.3** | تحقق من أن التوقعات الخاصة بحدود منطق العمل وعمليات التحقق من الصحة موثّقة، بما يشمل المستوى الخاص بكل مستخدم والمستوى العام على نطاق التطبيق. | 2 |
+
+## V2.2 التحقق من صحة المدخلات
+
+تُنفِذ ضوابط التحقق الفعّالة من صحة المدخلات التوقعات التجارية أو الوظيفية بشأن نوع البيانات التي يتوقع التطبيق استقبالها. وهذا يضمن جودة البيانات ويقلّل سطح الهجوم. لكنه لا يزيل الحاجة إلى استخدام الترميز أو التمعيم أو التنقية الصحيحة عند استخدام البيانات في مكوّن آخر أو عند عرضها كمخرجات، ولا يحلّ محلها.
+
+وفي هذا السياق، قد تأتي "المدخلات" من مصادر متنوعة كثيرة، منها حقول نماذج HTML وطلبات REST ومعاملات URL وحقول ترويسة HTTP وملفات تعريف الارتباط والملفات على القرص وقواعد البيانات وواجهات برمجة التطبيقات الخارجية.
+
+قد يفحص ضابط لمنطق العمل أن مُدخلًا معيّنًا هو رقم أقل من 100. وقد يفحص توقّع وظيفي أن رقمًا ما دون حد معيّن، لأن ذلك الرقم يتحكم في عدد مرات تنفيذ حلقة معيّنة، وقد يؤدي رقم كبير إلى معالجة مفرطة واحتمال حدوث حالة حجب خدمة.
+
+ومع أن التحقق من الصحة عبر المخطّط ليس إلزاميًا صراحةً، فقد يكون الآلية الأكثر فعالية لتغطية التحقق الكامل لواجهات برمجة تطبيقات HTTP أو غيرها من الواجهات التي تستخدم JSON أو XML.
+
+يُرجى ملاحظة النقاط التالية بشأن التحقق من الصحة عبر المخطّط:
+
+* يُعدّ "الإصدار المنشور" من مواصفة التحقق من الصحة عبر مخطّط JSON جاهزًا للإنتاج، لكنه ليس "مستقرًا" بالمعنى الدقيق. وعند استخدام التحقق عبر مخطّط JSON، تأكّد من عدم وجود فجوات مقارنةً بالإرشادات الواردة في المتطلبات أدناه.
+* ينبغي كذلك مراقبة أي مكتبات للتحقق من الصحة عبر مخطّط JSON قيد الاستخدام وتحديثها إذا لزم الأمر بعد إقرار المعيار رسميًا.
+* لا ينبغي استخدام التحقق عبر DTD، وينبغي تعطيل تقييم DTD في أُطر العمل، لتجنّب المشكلات المتعلقة بهجمات XXE على DTD.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **2.2.1** | تحقق من أن المدخلات يتم التحقق من صحتها لإنفاذ التوقعات التجارية أو الوظيفية الخاصة بها. وينبغي أن يستخدم ذلك إما تحققًا إيجابيًا مقابل قائمة سماح بالقيم والأنماط والنطاقات، أو أن يستند إلى مقارنة المُدخل ببنية متوقعة وحدود منطقية وفق قواعد محدّدة مسبقًا. وبالنسبة إلى المستوى 1، يمكن أن يركّز ذلك على المدخلات المستخدمة في اتخاذ قرارات تجارية أو أمنية محدّدة. أما للمستوى 2 وما فوق، فينبغي أن ينطبق على جميع المدخلات. | 1 |
+| **2.2.2** | تحقق من أن التطبيق مصمّم لإنفاذ التحقق من صحة المدخلات في طبقة خدمة موثوقة. ومع أن التحقق من جانب العميل يحسّن قابلية الاستخدام وينبغي تشجيعه، فيجب ألا يُعتمد عليه كضابط أمني. | 1 |
+| **2.2.3** | تحقق من أن التطبيق يضمن أن تكون تركيبات عناصر البيانات المترابطة معقولة وفق القواعد المحدّدة مسبقًا. | 2 |
+
+## V2.3 أمان منطق العمل
+
+يتناول هذا القسم المتطلبات الرئيسية للتأكد من أن التطبيق يُنفِذ عمليات منطق العمل على النحو الصحيح وأنه غير معرّض للهجمات التي تستغل منطق التطبيق وسير عمله.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **2.3.1** | تحقق من أن التطبيق لن يعالج مسارات منطق العمل للمستخدم نفسه إلا بترتيب الخطوات التسلسلي المتوقع ودون تخطّي خطوات. | 1 |
+| **2.3.2** | تحقق من أن حدود منطق العمل مُنفَّذة وفق وثائق التطبيق لتجنّب استغلال عيوب منطق العمل. | 2 |
+| **2.3.3** | تحقق من استخدام المعاملات على مستوى منطق العمل بحيث تنجح عملية منطق العمل بكاملها أو تُرجَع إلى الحالة الصحيحة السابقة. | 2 |
+| **2.3.4** | تحقق من استخدام آليات القفل على مستوى منطق العمل للتأكد من أن الموارد محدودة الكمية (مثل مقاعد المسرح أو فترات التوصيل) لا يمكن حجزها مرتين عن طريق التلاعب بمنطق التطبيق. | 2 |
+| **2.3.5** | تحقق من أن مسارات منطق العمل عالية القيمة تتطلّب موافقة متعددة المستخدمين لمنع الإجراءات غير المصرَّح بها أو العارضة. وقد يشمل ذلك، على سبيل المثال لا الحصر، التحويلات المالية الكبيرة أو الموافقات على العقود أو الوصول إلى المعلومات المصنّفة أو تجاوزات السلامة في التصنيع. | 3 |
+
+## V2.4 مكافحة الأتمتة
+
+يشتمل هذا القسم على ضوابط لمكافحة الأتمتة للتأكد من اشتراط تفاعلات شبيهة بالبشرية ومنع الطلبات المؤتمتة المفرطة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **2.4.1** | تحقق من وجود ضوابط لمكافحة الأتمتة للحماية من الاستدعاءات المفرطة لوظائف التطبيق التي قد تؤدي إلى تسريب البيانات أو إنشاء بيانات غير مفيدة أو استنفاد الحصص أو تجاوز حدود المعدّل أو حجب الخدمة أو الاستخدام المفرط للموارد المكلفة. | 2 |
+| **2.4.2** | تحقق من أن مسارات منطق العمل تتطلّب توقيتًا بشريًا واقعيًا، بما يمنع تقديم المعاملات بسرعة مفرطة. | 3 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP Web Security Testing Guide: Input Validation Testing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/README.html)
+* [OWASP Web Security Testing Guide: Business Logic Testing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/10-Business_Logic_Testing/README)
+* يمكن تحقيق مكافحة الأتمتة بطرائق كثيرة، منها استخدام [OWASP Automated Threats to Web Applications](https://owasp.org/www-project-automated-threats-to-web-applications/)
+* [OWASP Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)
+* [JSON Schema](https://json-schema.org/specification.html)
diff --git a/5.0/ar/0x12-V3-Web-Frontend-Security.md b/5.0/ar/0x12-V3-Web-Frontend-Security.md
new file mode 100644
index 0000000000..4933e19240
--- /dev/null
+++ b/5.0/ar/0x12-V3-Web-Frontend-Security.md
@@ -0,0 +1,100 @@
+# V3 أمان واجهة الويب الأمامية
+
+## الهدف من ضوابط الأمان
+
+تركّز هذه الفئة على المتطلبات المصمّمة للحماية من الهجمات التي تُنفَّذ عبر واجهة ويب أمامية. ولا تنطبق هذه المتطلبات على الحلول من آلة إلى آلة.
+
+## V3.1 توثيق أمان واجهة الويب الأمامية
+
+يبيّن هذا القسم ميزات أمان المتصفح التي ينبغي تحديدها في وثائق التطبيق.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **3.1.1** | تحقق من أن وثائق التطبيق تنص على ميزات الأمان المتوقعة التي يجب أن تدعمها المتصفحات المستخدمة للتطبيق (مثل HTTPS وأمان النقل الصارم عبر HTTP (HSTS) وسياسة أمان المحتوى (CSP) وغيرها من آليات أمان HTTP المعنية). ويجب أن تحدّد كذلك كيف يجب أن يتصرّف التطبيق عندما تكون بعض هذه الميزات غير متاحة (مثل تحذير المستخدم أو حجب الوصول). | 3 |
+
+## V3.2 التفسير غير المقصود للمحتوى
+
+يمكن أن يؤدي عرض المحتوى أو الوظائف في سياق غير صحيح إلى تنفيذ محتوى ضار أو عرضه.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **3.2.1** | تحقق من وجود ضوابط أمنية لمنع المتصفحات من عرض المحتوى أو الوظائف في استجابات HTTP في سياق غير صحيح (مثلًا عند طلب واجهة برمجة تطبيقات أو ملف حمّله المستخدم أو مورد آخر مباشرةً). وقد تشمل الضوابط الممكنة: عدم تقديم المحتوى إلا إذا أشارت حقول ترويسة طلب HTTP (مثل Sec-Fetch-\*) إلى أنه السياق الصحيح، أو استخدام توجيه sandbox في حقل ترويسة Content-Security-Policy، أو استخدام نوع الترتيب attachment في حقل ترويسة Content-Disposition. | 1 |
+| **3.2.2** | تحقق من أن المحتوى المقصود عرضه كنص، بدلًا من عرضه كـ HTML، يُعالَج باستخدام دوالّ عرض آمنة (مثل createTextNode أو textContent) لمنع التنفيذ غير المقصود لمحتوى مثل HTML أو JavaScript. | 1 |
+| **3.2.3** | تحقق من أن التطبيق يتجنّب إغراق DOM عند استخدام JavaScript من جانب العميل، وذلك باستخدام تصريحات صريحة للمتغيرات وإجراء فحص صارم للأنواع وتجنّب تخزين المتغيرات العامة على كائن document وتنفيذ عزل لمساحات الأسماء. | 3 |
+
+## V3.3 إعداد ملفات تعريف الارتباط
+
+يبيّن هذا القسم متطلبات التهيئة الآمنة لملفات تعريف الارتباط الحساسة لتوفير مستوى أعلى من التوكيد بأنها أُنشئت بواسطة التطبيق نفسه، ولمنع تسريب محتوياتها أو تعديلها على نحو غير ملائم.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **3.3.1** | تحقق من أن ملفات تعريف الارتباط لها السمة 'Secure' مضبوطة، وإذا لم تُستخدم البادئة '\__Host-' لاسم ملف تعريف الارتباط، فيجب استخدام البادئة '__Secure-' لاسمه. | 1 |
+| **3.3.2** | تحقق من أن قيمة السمة 'SameSite' لكل ملف تعريف ارتباط مضبوطة وفق الغرض منه، للحد من التعرّض لهجمات إعادة تلبيس واجهة المستخدم وهجمات تزوير الطلبات القائمة على المتصفح، المعروفة عمومًا بتزوير الطلبات عبر المواقع (CSRF). | 2 |
+| **3.3.3** | تحقق من أن ملفات تعريف الارتباط تحمل البادئة '__Host-' في اسمها، إلا إذا كانت مصمّمة صراحةً لمشاركتها مع مضيفين آخرين. | 2 |
+| **3.3.4** | تحقق من أنه، إذا لم يكن المقصود أن تكون قيمة ملف تعريف الارتباط متاحة للنصوص البرمجية من جانب العميل (مثل رمز الجلسة)، فيجب أن تكون السمة 'HttpOnly' مضبوطة لملف تعريف الارتباط، ويجب ألا تُنقل القيمة نفسها (مثل رمز الجلسة) إلى العميل إلا عبر حقل ترويسة 'Set-Cookie'. | 2 |
+| **3.3.5** | تحقق من أن التطبيق، عند كتابته ملف تعريف ارتباط، لا يتجاوز مجموع طول اسمه وقيمته 4096 بايت. فملفات تعريف الارتباط المفرطة الحجم لن يخزّنها المتصفح ومن ثم لن تُرسل مع الطلبات، ما يمنع المستخدم من استخدام وظائف التطبيق التي تعتمد على ذلك الملف. | 3 |
+
+## V3.4 ترويسات آليات أمان المتصفح
+
+يوضّح هذا القسم ترويسات الأمان التي ينبغي ضبطها على استجابات HTTP لتمكين ميزات أمان المتصفح وقيوده عند التعامل مع استجابات التطبيق.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **3.4.1** | تحقق من إدراج حقل ترويسة Strict-Transport-Security في جميع الاستجابات لإنفاذ سياسة أمان النقل الصارم عبر HTTP (HSTS). ويجب تحديد عمر أقصى لا يقل عن سنة واحدة، وللمستوى 2 وما فوق يجب أن تنطبق السياسة على جميع النطاقات الفرعية كذلك. | 1 |
+| **3.4.2** | تحقق من أن حقل ترويسة Access-Control-Allow-Origin الخاص بمشاركة الموارد عبر الأصول (CORS) قيمة ثابتة يحدّدها التطبيق، أو أنه، في حال استخدام قيمة حقل ترويسة طلب HTTP المسمّى Origin، يُتحقَّق منها مقابل قائمة سماح بالأصول الموثوقة. وعندما يلزم استخدام 'Access-Control-Allow-Origin: *'، تحقق من أن الاستجابة لا تشتمل على أي معلومات حساسة. | 1 |
+| **3.4.3** | تحقق من أن استجابات HTTP تشتمل على حقل ترويسة استجابة Content-Security-Policy يحدّد توجيهات تضمن ألا يحمّل المتصفح وينفّذ إلا المحتوى أو الموارد الموثوقة، وذلك للحد من تنفيذ JavaScript الضارة. وكحد أدنى، يجب استخدام سياسة عامة تشتمل على التوجيهين object-src 'none' وbase-uri 'none' وتحدّد إما قائمة سماح أو تستخدم قيمًا عشوائية لمرة واحدة أو تلبيدات. وبالنسبة إلى تطبيق من المستوى 3، يجب تحديد سياسة لكل استجابة تستخدم قيمًا عشوائية لمرة واحدة أو تلبيدات. | 2 |
+| **3.4.4** | تحقق من أن جميع استجابات HTTP تحتوي على حقل ترويسة 'X-Content-Type-Options: nosniff'. وهذا يوجّه المتصفحات إلى عدم استخدام استشعار المحتوى وتخمين نوع MIME للاستجابة المعنية، وإلى اشتراط تطابق قيمة حقل ترويسة Content-Type للاستجابة مع المورد المقصود. على سبيل المثال، لا تُقبل الاستجابة لطلب نمط إلا إذا كان Content-Type للاستجابة هو 'text/css'. وهذا يُمكّن كذلك استخدام وظيفة حجب القراءة عبر الأصول (CORB) في المتصفح. | 2 |
+| **3.4.5** | تحقق من أن التطبيق يضبط سياسة للمُحيل لمنع تسريب البيانات الحساسة تقنيًا إلى خدمات الأطراف الثالثة عبر حقل ترويسة طلب HTTP المسمّى 'Referer'. ويمكن تحقيق ذلك باستخدام حقل ترويسة استجابة HTTP المسمّى Referrer-Policy أو عبر سمات عناصر HTML. وقد تشمل البيانات الحساسة بيانات المسار والاستعلام في عنوان URL، وكذلك اسم المضيف في التطبيقات الداخلية غير العامة. | 2 |
+| **3.4.6** | تحقق من أن تطبيق الويب يستخدم توجيه frame-ancestors في حقل ترويسة Content-Security-Policy لكل استجابة HTTP لضمان عدم إمكانية تضمينه افتراضيًا، وأن تضمين موارد معيّنة مسموح به عند الضرورة فقط. ولاحظ أن حقل ترويسة X-Frame-Options، وإن كانت المتصفحات تدعمه، صار متقادمًا ولا يجوز التعويل عليه. | 2 |
+| **3.4.7** | تحقق من أن حقل ترويسة Content-Security-Policy يحدّد موقعًا للإبلاغ عن الانتهاكات. | 3 |
+| **3.4.8** | تحقق من أن جميع استجابات HTTP التي تستهل عرض مستند (مثل الاستجابات ذات Content-Type من نوع text/html) تشتمل على حقل ترويسة Cross-Origin-Opener-Policy مع توجيه same-origin أو توجيه same-origin-allow-popups حسب المطلوب. وهذا يمنع الهجمات التي تسيء استغلال الوصول المشترك إلى كائنات Window، مثل انتحال علامات التبويب وعدّ الإطارات. | 3 |
+
+## V3.5 فصل الأصول في المتصفح
+
+عند قبول طلب لوظيفة حساسة من جانب الخادم، يحتاج التطبيق إلى التأكد من أن الطلب قد استهلّه التطبيق نفسه أو طرف موثوق وأنه لم يُزوَّر بواسطة مهاجم.
+
+وقد تشمل الوظائف الحساسة في هذا السياق قبول إرسال النماذج للمستخدمين المصادَق عليهم وغير المصادَق عليهم (مثل طلب مصادقة)، أو العمليات المغيّرة للحالة، أو الوظائف المطلوبة للموارد بكثافة (مثل تصدير البيانات).
+
+وأهم الحماية هنا هي سياسات أمان المتصفح مثل سياسة الأصل الواحد الخاصة بـ JavaScript وكذلك منطق SameSite الخاص بملفات تعريف الارتباط. وهناك حماية شائعة أخرى هي آلية CORS التمهيدية. وستكون هذه الآلية بالغة الأهمية لنقاط النهاية المصمّمة لاستدعائها من أصل مختلف، لكنها قد تكون كذلك آلية مفيدة لمنع تزوير الطلبات لنقاط النهاية غير المصمّمة لاستدعائها من أصل مختلف.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **3.5.1** | تحقق من أنه، إذا كان التطبيق لا يعوّل على آلية CORS التمهيدية لمنع الطلبات غير المسموح بها عبر الأصول من استخدام وظائف حساسة، فإن هذه الطلبات يُتحقَّق منها للتأكد من أنها صادرة عن التطبيق نفسه. ويمكن تحقيق ذلك باستخدام رموز الحماية من التزوير والتحقق منها، أو باشتراط حقول ترويسة HTTP إضافية ليست من حقول ترويسة الطلب المدرجة في قائمة CORS الآمنة. والغرض من ذلك الدفاع عن هجمات تزوير الطلبات القائمة على المتصفح، المعروفة عمومًا بتزوير الطلبات عبر المواقع (CSRF). | 1 |
+| **3.5.2** | تحقق من أنه، إذا كان التطبيق يعوّل على آلية CORS التمهيدية لمنع الاستخدام غير المسموح به للوظائف الحساسة عبر الأصول، فلا يمكن استدعاء الوظيفة بطلب لا يُشغّل طلبًا تمهيديًا لـ CORS. وقد يقتضي ذلك فحص قيمتي حقلي ترويسة الطلب 'Origin' و'Content-Type' أو استخدام حقل ترويسة إضافي ليس من حقول الترويسة المدرجة في قائمة CORS الآمنة. | 1 |
+| **3.5.3** | تحقق من أن طلبات HTTP الموجّهة إلى الوظائف الحساسة تستخدم طرائق HTTP ملائمة مثل POST أو PUT أو PATCH أو DELETE، وليس الطرائق التي تعرّفها مواصفة HTTP بأنها "آمنة" مثل HEAD أو OPTIONS أو GET. وبدلًا من ذلك، يمكن استخدام تحقق صارم من حقول ترويسة الطلب Sec-Fetch-* للتأكد من أن الطلب لم يصدر عن استدعاء غير ملائم عبر الأصول أو عن طلب تنقّل أو تحميل مورد (مثل مصدر صورة) حيث لا يكون ذلك متوقعًا. | 1 |
+| **3.5.4** | تحقق من أن التطبيقات المنفصلة مستضافة على أسماء مضيفين مختلفة للاستفادة من القيود التي توفّرها سياسة الأصل الواحد، بما في ذلك كيفية تفاعل المستندات أو النصوص البرمجية التي يحمّلها أصل ما مع موارد من أصل آخر، والقيود المبنية على اسم المضيف الخاصة بملفات تعريف الارتباط. | 2 |
+| **3.5.5** | تحقق من أن الرسائل التي تستقبلها واجهة postMessage تُهمَل إذا كان أصل الرسالة غير موثوق، أو إذا كانت صياغة الرسالة غير صحيحة. | 2 |
+| **3.5.6** | تحقق من أن وظيفة JSONP غير مُمكَّنة في أي مكان في التطبيق، وذلك لتجنّب هجمات تضمين النصوص البرمجية عبر المواقع (XSSI). | 3 |
+| **3.5.7** | تحقق من أن البيانات التي تتطلّب تخويلًا غير مدرجة في استجابات موارد النصوص البرمجية، مثل ملفات JavaScript، وذلك لمنع هجمات تضمين النصوص البرمجية عبر المواقع (XSSI). | 3 |
+| **3.5.8** | تحقق من أن الموارد المصادَق عليها (مثل الصور ومقاطع الفيديو والنصوص البرمجية والمستندات الأخرى) لا يمكن تحميلها أو تضمينها بالنيابة عن المستخدم إلا عند القصد. ويمكن تحقيق ذلك بتحقق صارم من حقول ترويسة طلب HTTP المسمّاة Sec-Fetch-* للتأكد من أن الطلب لم يصدر عن استدعاء غير ملائم عبر الأصول، أو بضبط حقل ترويسة استجابة HTTP المسمّى Cross-Origin-Resource-Policy ضبطًا تقييديًا لتوجيه المتصفح إلى حجب المحتوى المُعاد. | 3 |
+
+## V3.6 سلامة الموارد الخارجية
+
+يوفّر هذا القسم إرشادات للاستضافة الآمنة للمحتوى على مواقع الأطراف الثالثة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **3.6.1** | تحقق من أن أصول جانب العميل، مثل مكتبات JavaScript أو CSS أو خطوط الويب، لا تُستضاف خارجيًا (مثلًا على شبكة توصيل محتوى) إلا إذا كان المورد ساكنًا ومُصدَّرًا بإصدار، واستُخدمت سلامة الموارد الفرعية (SRI) للتحقق من سلامة الأصل. وإذا لم يكن ذلك ممكنًا، فينبغي أن يكون هناك قرار أمني موثّق لتبرير ذلك لكل مورد. | 3 |
+
+## V3.7 اعتبارات أخرى لأمان المتصفح
+
+يشتمل هذا القسم على ضوابط أمنية أخرى متنوعة وميزات أمان المتصفحات الحديثة اللازمة لأمان المتصفح من جانب العميل.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **3.7.1** | تحقق من أن التطبيق لا يستخدم إلا تقنيات جانب العميل التي لا تزال مدعومة وتُعدّ آمنة. ومن أمثلة التقنيات التي لا تستوفي هذا المتطلب إضافات NSAPI وFlash وShockwave وActiveX وSilverlight وNACL أو تطبيقات Java الصغيرة من جانب العميل. | 2 |
+| **3.7.2** | تحقق من أن التطبيق لن يعيد توجيه المستخدم تلقائيًا إلى اسم مضيف أو نطاق مختلف (لا يتحكم فيه التطبيق) إلا إذا كانت الجهة المقصودة مدرجة في قائمة سماح. | 2 |
+| **3.7.3** | تحقق من أن التطبيق يعرض إشعارًا عند إعادة توجيه المستخدم إلى عنوان URL خارج نطاق سيطرة التطبيق، مع خيار إلغاء التنقّل. | 3 |
+| **3.7.4** | تحقق من إضافة النطاق الأعلى للتطبيق (مثل site.tld) إلى قائمة التحميل المسبق العامة الخاصة بأمان النقل الصارم عبر HTTP (HSTS). وهذا يضمن أن استخدام TLS للتطبيق مدمج مباشرةً في المتصفحات الرئيسية، بدلًا من التعويل على حقل ترويسة استجابة Strict-Transport-Security فقط. | 3 |
+| **3.7.5** | تحقق من أن التطبيق يتصرّف على النحو الموثّق (مثل تحذير المستخدم أو حجب الوصول) إذا كان المتصفح المستخدم للوصول إلى التطبيق لا يدعم ميزات الأمان المتوقعة. | 3 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [Set-Cookie __Host- prefix details](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes)
+* [OWASP Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)
+* [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/)
+* [OWASP Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)
+* [HSTS Browser Preload List submission form](https://hstspreload.org/)
+* [OWASP DOM Clobbering Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html)
diff --git a/5.0/ar/0x13-V4-API-and-Web-Service.md b/5.0/ar/0x13-V4-API-and-Web-Service.md
new file mode 100644
index 0000000000..889e6f2d3b
--- /dev/null
+++ b/5.0/ar/0x13-V4-API-and-Web-Service.md
@@ -0,0 +1,64 @@
+# V4 واجهات برمجة التطبيقات وخدمات الويب
+
+## الهدف من ضوابط الأمان
+
+تنطبق عدة اعتبارات بشكل خاص على التطبيقات التي تعرض واجهات برمجة التطبيقات (APIs) لاستخدامها من قِبل متصفحات الويب أو غيرها من المستهلكين (باستخدام JSON أو XML أو GraphQL في الغالب). يغطي هذا الفصل التكوينات والآليات الأمنية ذات الصلة التي ينبغي تطبيقها.
+
+لاحظ أن الاعتبارات المتعلقة بالمصادقة وإدارة الجلسات والتحقق من صحة المدخلات الواردة في فصول أخرى تنطبق كذلك على واجهات برمجة التطبيقات، ولذلك لا يمكن أخذ هذا الفصل خارج سياقه أو اختباره بمعزل عن غيره.
+
+## V4.1 الأمان العام لخدمات الويب
+
+يتناول هذا القسم الاعتبارات الأمنية العامة لخدمات الويب، وبالتالي الممارسات الأساسية للسلامة الأمنية في خدمات الويب.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **4.1.1** | تحقق من أن كل استجابة HTTP تحتوي على متن رسالة تشتمل على حقل ترويسة Content-Type يطابق المحتوى الفعلي للاستجابة، بما في ذلك معامل charset لتحديد ترميز محارف آمن (مثل UTF-8 أو ISO-8859-1) وفقًا لأنواع الوسائط المعتمدة من IANA، مثل "text/" و"/+xml" و"/xml". | 1 |
+| **4.1.2** | تحقق من أن نقاط النهاية الموجهة للمستخدم فقط (المخصصة للوصول اليدوي عبر متصفح الويب) هي التي تعيد التوجيه تلقائيًا من HTTP إلى HTTPS، بينما لا تنفّذ الخدمات أو نقاط النهاية الأخرى إعادة توجيه شفافة. والغرض من ذلك تجنب الحالة التي يرسل فيها العميل طلبات HTTP غير مشفّرة عن طريق الخطأ، ولكن نظرًا لإعادة توجيه هذه الطلبات تلقائيًا إلى HTTPS، يبقى تسريب البيانات الحساسة غير مكتشف. | 2 |
+| **4.1.3** | تحقق من أن أي حقل ترويسة HTTP يستخدمه التطبيق ويُضبط بواسطة طبقة وسيطة، مثل موازن الحمل أو وكيل الويب أو خدمة الواجهة الخلفية للواجهة الأمامية، لا يمكن للمستخدم النهائي تجاوزه. ومن أمثلة الترويسات X-Real-IP أو X-Forwarded-* أو X-User-ID. | 2 |
+| **4.1.4** | تحقق من أنه لا يمكن استخدام سوى طرائق HTTP المدعومة صراحةً من قِبل التطبيق أو واجهة برمجة التطبيقات الخاصة به (بما في ذلك OPTIONS أثناء الطلبات التمهيدية)، وأن الطرائق غير المستخدمة محجوبة. | 3 |
+| **4.1.5** | تحقق من استخدام التوقيعات الرقمية لكل رسالة لتوفير ضمان إضافي فوق حماية طبقة النقل للطلبات أو المعاملات البالغة الحساسية أو التي تمر عبر عدد من الأنظمة. | 3 |
+
+## V4.2 التحقق من بنية رسائل HTTP
+
+يوضح هذا القسم كيف ينبغي التحقق من بنية رسالة HTTP وحقول ترويستها لمنع هجمات مثل تهريب الطلبات وتقسيم الاستجابة وحقن الترويسات وحجب الخدمة عن طريق رسائل HTTP المفرطة الطول.
+
+هذه المتطلبات ذات صلة بمعالجة رسائل HTTP وتوليدها بشكل عام، لكنها مهمة على وجه الخصوص عند تحويل رسائل HTTP بين إصدارات HTTP المختلفة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **4.2.1** | تحقق من أن جميع مكوّنات التطبيق (بما في ذلك موازنات الحمل والجدران النارية وخوادم التطبيقات) تحدّد حدود رسائل HTTP الواردة باستخدام الآلية المناسبة لإصدار HTTP لمنع تهريب طلبات HTTP. في HTTP/1.x، إذا كان حقل الترويسة Transfer-Encoding موجودًا، فيجب تجاهل ترويسة Content-Length وفقًا لـ RFC 2616. وعند استخدام HTTP/2 أو HTTP/3، إذا كان حقل الترويسة Content-Length موجودًا، فيجب على المستقبِل التأكد من توافقه مع طول أُطر DATA. | 2 |
+| **4.2.2** | تحقق من أن حقل الترويسة Content-Length، عند توليد رسائل HTTP، لا يتعارض مع طول المحتوى كما تحدده أُطر بروتوكول HTTP، وذلك لمنع هجمات تهريب الطلبات. | 3 |
+| **4.2.3** | تحقق من أن التطبيق لا يرسل ولا يقبل رسائل HTTP/2 أو HTTP/3 التي تحتوي على حقول ترويسة خاصة بالاتصال مثل Transfer-Encoding، وذلك لمنع هجمات تقسيم الاستجابة وحقن الترويسات. | 3 |
+| **4.2.4** | تحقق من أن التطبيق لا يقبل سوى طلبات HTTP/2 وHTTP/3 التي لا تحتوي حقول ترويستها وقيمها على أي متتاليات CR (\r) أو LF (\n) أو CRLF (\r\n)، وذلك لمنع هجمات حقن الترويسات. | 3 |
+| **4.2.5** | تحقق من أن التطبيق، إذا كان يبني الطلبات ويرسلها (في الواجهة الخلفية أو الأمامية)، يستخدم التحقق من الصحة أو التنقية أو آليات أخرى لتجنب إنشاء معرّفات موارد موحّدة (URIs) (مثل تلك الخاصة باستدعاءات واجهة برمجة التطبيقات) أو حقول ترويسة طلب HTTP (مثل Authorization أو Cookie) تكون أطول من أن يقبلها المكوّن المستقبِل. وقد يؤدي ذلك إلى حجب الخدمة، كما يحدث عند إرسال طلب مفرط الطول (مثل حقل ترويسة cookie طويل)، ما ينتج عنه رد الخادم دائمًا بحالة خطأ. | 3 |
+
+## V4.3 GraphQL
+
+أصبح GraphQL أكثر شيوعًا كوسيلة لإنشاء عملاء غنيين بالبيانات وغير مرتبطين ارتباطًا وثيقًا بمجموعة متنوعة من خدمات الواجهة الخلفية. يغطي هذا القسم الاعتبارات الأمنية الخاصة بـ GraphQL.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **4.3.1** | تحقق من استخدام قائمة سماح للاستعلامات أو تحديد العمق أو تحديد الكمية أو تحليل تكلفة الاستعلام لمنع حجب الخدمة (DoS) في GraphQL أو في تعبيرات طبقة البيانات نتيجة الاستعلامات المتداخلة والمكلفة. | 2 |
+| **4.3.2** | تحقق من تعطيل استعلامات الاستبطان (introspection) في GraphQL في بيئة الإنتاج، إلا إذا كان الغرض من واجهة برمجة تطبيقات GraphQL أن تستخدمها أطراف أخرى. | 2 |
+
+## V4.4 WebSocket
+
+WebSocket هو بروتوكول اتصالات يوفّر قناة اتصال ثنائية الاتجاه متزامنة عبر اتصال TCP واحد. وقد وضعته IETF كمعيار في RFC 6455 عام 2011، وهو مختلف عن HTTP، على الرغم من أنه مصمّم للعمل عبر منفذي HTTP رقم 443 و80.
+
+يوفّر هذا القسم متطلبات أمنية أساسية لمنع الهجمات المتعلقة بأمان الاتصال وإدارة الجلسات التي تستغل تحديدًا قناة الاتصال الفوري هذه.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **4.4.1** | تحقق من استخدام WebSocket عبر TLS (WSS) في جميع اتصالات WebSocket. | 1 |
+| **4.4.2** | تحقق من أن حقل الترويسة Origin، أثناء مصافحة WebSocket الأولية عبر HTTP، يُفحص مقابل قائمة بالأصول المسموح بها للتطبيق. | 2 |
+| **4.4.3** | تحقق من أنه، في حال عدم إمكانية استخدام إدارة الجلسات القياسية الخاصة بالتطبيق، تُستخدم رموز مميزة مخصّصة لهذا الغرض، تمتثل لمتطلبات أمان إدارة الجلسات ذات الصلة. | 2 |
+| **4.4.4** | تحقق من أن الرموز المميزة المخصّصة لإدارة جلسات WebSocket يتم الحصول عليها أو التحقق منها مبدئيًا من خلال جلسة HTTPS المصادَق عليها مسبقًا عند تحويل جلسة HTTPS قائمة إلى قناة WebSocket. | 2 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html)
+* موارد عن التخويل في GraphQL من [graphql.org](https://graphql.org/learn/authorization/) و[Apollo](https://www.apollographql.com/docs/apollo-server/security/authentication/#authorization-methods).
+* [OWASP Web Security Testing Guide: GraphQL Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL)
+* [OWASP Web Security Testing Guide: Testing WebSockets](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing/10-Testing_WebSockets)
diff --git a/5.0/ar/0x14-V5-File-Handling.md b/5.0/ar/0x14-V5-File-Handling.md
new file mode 100644
index 0000000000..a83b933a7d
--- /dev/null
+++ b/5.0/ar/0x14-V5-File-Handling.md
@@ -0,0 +1,54 @@
+# V5 التعامل مع الملفات
+
+## الهدف من ضوابط الأمان
+
+يمكن أن يمثّل استخدام الملفات مخاطر متنوعة للتطبيق، منها حجب الخدمة والوصول غير المصرَّح به واستنفاد مساحة التخزين. ويشتمل هذا الفصل على متطلبات لمعالجة هذه المخاطر.
+
+## V5.1 توثيق التعامل مع الملفات
+
+يشتمل هذا القسم على متطلب لتوثيق الخصائص المتوقعة للملفات التي يقبلها التطبيق، كشرط مسبق ضروري لتطوير الفحوص الأمنية ذات الصلة والتحقق منها.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **5.1.1** | تحقق من أن الوثائق تحدّد أنواع الملفات المسموح بها وامتدادات الملفات المتوقعة والحجم الأقصى (بما في ذلك الحجم بعد فك الحزم) لكل ميزة تحميل. وإضافةً إلى ذلك، تأكّد من أن الوثائق تحدّد كيف تُجعل الملفات آمنة للمستخدمين النهائيين لتنزيلها ومعالجتها، مثل كيفية تصرّف التطبيق عند اكتشاف ملف ضار. | 2 |
+
+## V5.2 تحميل الملفات ومحتواها
+
+تُعدّ وظيفة تحميل الملفات مصدرًا رئيسيًا للملفات غير الموثوقة. ويبيّن هذا القسم المتطلبات اللازمة للتأكد من أن وجود هذه الملفات أو حجمها أو محتواها لا يمكن أن يضرّ بالتطبيق.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **5.2.1** | تحقق من أن التطبيق لن يقبل سوى الملفات ذات الحجم الذي يمكنه معالجته دون التسبب في فقدان الأداء أو هجوم حجب الخدمة. | 1 |
+| **5.2.2** | تحقق من أن التطبيق، عند قبوله ملفًا، سواء بمفرده أو داخل أرشيف مثل ملف zip، يفحص ما إذا كان امتداد الملف يطابق امتدادًا متوقعًا ويتحقق من أن المحتويات تتوافق مع النوع الذي يمثّله الامتداد. ويشمل ذلك، على سبيل المثال لا الحصر، فحص "البايتات السحرية" الأولية، وإجراء إعادة كتابة للصور، واستخدام مكتبات متخصّصة للتحقق من محتوى الملفات. وبالنسبة إلى المستوى 1، يمكن أن يركّز ذلك على الملفات المستخدمة في اتخاذ قرارات تجارية أو أمنية محدّدة فقط. أما للمستوى 2 وما فوق، فيجب أن ينطبق على جميع الملفات المقبولة. | 1 |
+| **5.2.3** | تحقق من أن التطبيق يفحص الملفات المضغوطة (مثل zip وgz وdocx وodt) مقابل الحجم الأقصى المسموح به بعد فك الضغط ومقابل العدد الأقصى للملفات قبل فك ضغط الملف. | 2 |
+| **5.2.4** | تحقق من إنفاذ حصة لحجم الملفات وعدد أقصى للملفات لكل مستخدم للتأكد من أن مستخدمًا واحدًا لا يمكنه إشغال مساحة التخزين بعدد كبير جدًا من الملفات أو بملفات كبيرة الحجم بشكل مفرط. | 3 |
+| **5.2.5** | تحقق من أن التطبيق لا يسمح بتحميل ملفات مضغوطة تحتوي على روابط رمزية إلا إذا كان ذلك مطلوبًا تحديدًا (وفي هذه الحالة سيكون من الضروري إنفاذ قائمة سماح بالملفات التي يمكن الربط الرمزي إليها). | 3 |
+| **5.2.6** | تحقق من أن التطبيق يرفض الصور المحمَّلة التي يتجاوز حجمها بالبكسل الحد الأقصى المسموح به، وذلك لمنع هجمات إغراق البكسل. | 3 |
+
+## V5.3 تخزين الملفات
+
+يشتمل هذا القسم على متطلبات لمنع تنفيذ الملفات على نحو غير ملائم بعد تحميلها، ولكشف المحتوى الخطير، ولتجنّب استخدام بيانات غير موثوقة في التحكم بمكان تخزين الملفات.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **5.3.1** | تحقق من أن الملفات المحمَّلة أو المُولَّدة بمدخلات غير موثوقة والمخزَّنة في مجلد عام لا تُنفَّذ كشيفرة برنامج من جانب الخادم عند الوصول إليها مباشرةً بطلب HTTP. | 1 |
+| **5.3.2** | تحقق من أن التطبيق، عند إنشائه مسارات ملفات لعمليات الملفات، يستخدم بيانات مُولَّدة داخليًا أو موثوقة بدلًا من أسماء الملفات المقدَّمة من المستخدم، أو إذا كان لا بد من استخدام أسماء الملفات أو بياناتها الوصفية المقدَّمة من المستخدم، فيجب تطبيق تحقق صارم وتنقية. والغرض من ذلك الحماية من هجمات اجتياز المسار وتضمين الملفات المحلية أو البعيدة (LFI وRFI) وتزوير الطلب من جانب الخادم (SSRF). | 1 |
+| **5.3.3** | تحقق من أن معالجة الملفات من جانب الخادم، مثل فك ضغط الملفات، تتجاهل معلومات المسار المقدَّمة من المستخدم لمنع ثغرات مثل zip slip. | 3 |
+
+## V5.4 تنزيل الملفات
+
+يحتوي هذا القسم على متطلبات للتخفيف من المخاطر عند تقديم الملفات للتنزيل، بما في ذلك اجتياز المسار وهجمات الحقن. ويشمل ذلك أيضًا التأكد من أنها لا تحتوي على محتوى خطير.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **5.4.1** | تحقق من أن التطبيق يتحقق من أسماء الملفات المقدَّمة من المستخدم أو يتجاهلها، بما في ذلك الواردة في JSON أو JSONP أو معامل URL، وأنه يحدّد اسم ملف في حقل ترويسة Content-Disposition في الاستجابة. | 2 |
+| **5.4.2** | تحقق من أن أسماء الملفات المقدَّمة (مثلًا في حقول ترويسة استجابة HTTP أو مرفقات البريد الإلكتروني) مُرمَّزة أو مُنقّاة (مثلًا وفقًا لـ RFC 6266) للحفاظ على بنية المستند ومنع هجمات الحقن. | 2 |
+| **5.4.3** | تحقق من أن الملفات التي تُجلب من مصادر غير موثوقة تُفحص بواسطة برامج مكافحة الفيروسات لمنع تقديم محتوى ضار معروف. | 2 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)
+* [Example of using symlinks for arbitrary file read](https://hackerone.com/reports/1439593)
+* [Explanation of "Magic Bytes" from Wikipedia](https://en.wikipedia.org/wiki/List_of_file_signatures)
diff --git a/5.0/ar/0x15-V6-Authentication.md b/5.0/ar/0x15-V6-Authentication.md
new file mode 100644
index 0000000000..745954e380
--- /dev/null
+++ b/5.0/ar/0x15-V6-Authentication.md
@@ -0,0 +1,166 @@
+# V6 المصادقة
+
+## الهدف من ضوابط الأمان
+
+المصادقة هي عملية إرساء أو تأكيد أصالة فرد أو جهاز. وهي تتضمّن التحقق من المطالبات التي يقدّمها شخص أو التي تُقدَّم عن جهاز، وضمان المقاومة لانتحال الهوية، ومنع استعادة كلمات المرور أو اعتراضها.
+
+إن [NIST SP 800-63](https://pages.nist.gov/800-63-3/) معيار حديث قائم على الأدلة وقيّم للمؤسسات في جميع أنحاء العالم، لكنه وثيق الصلة على وجه الخصوص بالوكالات الأمريكية وبمن يتعامل معها.
+
+ومع أن كثيرًا من المتطلبات في هذا الفصل مبنية على القسم الثاني من ذلك المعيار (المعروف بـ NIST SP 800-63B "إرشادات الهوية الرقمية - المصادقة وإدارة دورة الحياة")، فإن الفصل يركّز على التهديدات الشائعة ونقاط ضعف المصادقة الشائعة الاستغلال. وهو لا يحاول تغطية كل نقطة في المعيار تغطيةً شاملة. وللحالات التي يكون فيها الامتثال الكامل لـ NIST SP 800-63 ضروريًا، يُرجى الرجوع إلى NIST SP 800-63.
+
+وإضافةً إلى ذلك، قد تختلف مصطلحات NIST SP 800-63 أحيانًا، ويستخدم هذا الفصل غالبًا مصطلحات أكثر شيوعًا في الفهم لتحسين الوضوح.
+
+ومن السمات الشائعة في التطبيقات الأكثر تقدّمًا القدرة على تكييف مراحل المصادقة المطلوبة بناءً على عوامل مخاطر متنوعة. وهذه السمة مشمولة في فصل "التخويل"، إذ يلزم مراعاة هذه الآليات في قرارات التخويل كذلك.
+
+## V6.1 توثيق المصادقة
+
+يحتوي هذا القسم على متطلبات تبيّن توثيق المصادقة الذي ينبغي الاحتفاظ به لتطبيق ما. وهذا بالغ الأهمية لتنفيذ ضوابط المصادقة المعنية وتقدير كيفية تهيئتها.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **6.1.1** | تحقق من أن وثائق التطبيق تحدّد كيفية استخدام ضوابط مثل تحديد المعدّل ومكافحة الأتمتة والاستجابة التكيّفية للدفاع عن هجمات مثل حشو بيانات الاعتماد والقوة الغاشمة على كلمات المرور. ويجب أن توضّح الوثائق كيفية تهيئة هذه الضوابط ومنع الإغلاق الخبيث للحسابات. | 1 |
+| **6.1.2** | تحقق من توثيق قائمة بالكلمات الخاصة بالسياق لمنع استخدامها في كلمات المرور. وقد تشتمل القائمة على تصاريف أسماء المؤسسة وأسماء المنتجات ومعرّفات الأنظمة والأسماء الرمزية للمشاريع وأسماء الأقسام أو الأدوار وما شابهها. | 2 |
+| **6.1.3** | تحقق من أنه، إذا كان التطبيق يشتمل على مسارات مصادقة متعددة، فإنها موثّقة جميعًا إلى جانب ضوابط الأمان وقوة المصادقة التي يجب إنفاذها باتساق فيها كلها. | 2 |
+
+## V6.2 أمان كلمات المرور
+
+كلمات المرور، التي يسمّيها NIST SP 800-63 "الأسرار المحفوظة"، تشمل كلمات المرور وعبارات المرور وأرقام التعريف الشخصية وأنماط إلغاء القفل واختيار الهُريرة الصحيحة أو عنصر صورة آخر. وتُعدّ عمومًا "شيئًا تعرفه" وتُستخدم غالبًا كآلية مصادقة أحادية العامل.
+
+ولذلك يحتوي هذا القسم على متطلبات للتأكد من إنشاء كلمات المرور والتعامل معها بأمان. ومعظم المتطلبات من المستوى 1 لأنها أكثر أهمية في ذلك المستوى. ومن المستوى 2 وما بعده، تكون آليات المصادقة متعددة العوامل مطلوبة، وقد تكون كلمات المرور أحد تلك العوامل.
+
+وتتعلق المتطلبات في هذا القسم في معظمها بـ [&sect; 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html).
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **6.2.1** | تحقق من أن كلمات المرور التي يعيّنها المستخدم لا تقل عن 8 محارف طولًا، وإن كان يُوصى بقوة بحد أدنى قدره 15 محرفًا. | 1 |
+| **6.2.2** | تحقق من أن المستخدمين يمكنهم تغيير كلمة مرورهم. | 1 |
+| **6.2.3** | تحقق من أن وظيفة تغيير كلمة المرور تتطلّب كلمة مرور المستخدم الحالية والجديدة. | 1 |
+| **6.2.4** | تحقق من أن كلمات المرور المُقدَّمة أثناء تسجيل الحساب أو تغيير كلمة المرور تُفحص مقابل مجموعة متاحة تشمل، على الأقل، أشهر 3000 كلمة مرور مطابقة لسياسة كلمات المرور في التطبيق، مثل الحد الأدنى للطول. | 1 |
+| **6.2.5** | تحقق من إمكانية استخدام كلمات مرور بأي تركيب، دون قواعد تحدّ من نوع المحارف المسموح بها. ويجب ألا يكون هناك اشتراط لعدد أدنى من الأحرف الكبيرة أو الصغيرة أو الأرقام أو المحارف الخاصة. | 1 |
+| **6.2.6** | تحقق من أن حقول إدخال كلمة المرور تستخدم type=password لإخفاء الإدخال. وقد تسمح التطبيقات للمستخدم بعرض كلمة المرور المخفية بالكامل مؤقتًا، أو آخر محرف مكتوب منها. | 1 |
+| **6.2.7** | تحقق من السماح بوظيفة "اللصق" ومساعدات كلمات المرور في المتصفح ومديري كلمات المرور الخارجيين. | 1 |
+| **6.2.8** | تحقق من أن التطبيق يتحقق من كلمة مرور المستخدم كما استُلمت منه بالضبط، دون أي تعديلات مثل الاقتطاع أو تحويل حالة الأحرف. | 1 |
+| **6.2.9** | تحقق من السماح بكلمات مرور لا يقل طولها عن 64 محرفًا. | 2 |
+| **6.2.10** | تحقق من أن كلمة مرور المستخدم تبقى صالحة حتى يُكتشف أنها مخترقة أو يبدّلها المستخدم. ويجب ألا يشترط التطبيق تدويرًا دوريًا لبيانات الاعتماد. | 2 |
+| **6.2.11** | تحقق من استخدام القائمة الموثّقة للكلمات الخاصة بالسياق لمنع إنشاء كلمات مرور سهلة التخمين. | 2 |
+| **6.2.12** | تحقق من أن كلمات المرور المُقدَّمة أثناء تسجيل الحساب أو تغييرها تُفحص مقابل مجموعة من كلمات المرور المسرّبة. | 2 |
+
+## V6.3 الأمان العام للمصادقة
+
+يحتوي هذا القسم على متطلبات عامة لأمان آليات المصادقة، وكذلك على بيان التوقعات المختلفة للمستويات. فيجب على تطبيقات المستوى 2 أن تُلزم باستخدام المصادقة متعددة العوامل (MFA). ويجب على تطبيقات المستوى 3 أن تستخدم مصادقة قائمة على العتاد، تُنفَّذ في بيئة تنفيذ موثوقة ومُصدَّقة (TEE). وقد يشمل ذلك مفاتيح المرور المرتبطة بالجهاز، أو مُصادِقات مُنفَذة بمستوى توكيد عالٍ وفق eIDAS (LoA High)، أو مُصادِقات بمستوى توكيد المُصادِق الثالث وفق NIST (AAL3)، أو آلية مكافئة.
+
+ومع أن هذا موقف صارم نسبيًا بشأن المصادقة متعددة العوامل، فمن الأهمية البالغة رفع مستوى الصعوبة في هذا الشأن لحماية المستخدمين، وينبغي أن تكون أي محاولة لتخفيف هذه المتطلبات مصحوبة بخطة واضحة عن كيفية التخفيف من المخاطر المتعلقة بالمصادقة، مع مراعاة إرشادات NIST وأبحاثها في الموضوع.
+
+ولاحظ أن NIST SP 800-63، في وقت الإصدار، يعتبر البريد الإلكتروني [غير مقبول](https://pages.nist.gov/800-63-FAQ/#q-b11) كآلية مصادقة ([نسخة محفوظة](https://web.archive.org/web/20250330115328/https://pages.nist.gov/800-63-FAQ/#q-b11)).
+
+وتتعلق المتطلبات في هذا القسم بأقسام متنوعة من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html)، منها: [&sect; 4.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#421-permitted-authenticator-types) و[&sect; 4.3.1](https://pages.nist.gov/800-63-3/sp800-63b.html#431-permitted-authenticator-types) و[&sect; 5.2.2](https://pages.nist.gov/800-63-3/sp800-63b.html#522-rate-limiting-throttling) و[&sect; 6.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-612-post-enrollment-binding).
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **6.3.1** | تحقق من تنفيذ ضوابط لمنع هجمات مثل حشو بيانات الاعتماد والقوة الغاشمة على كلمات المرور وفق وثائق أمان التطبيق. | 1 |
+| **6.3.2** | تحقق من أن حسابات المستخدمين الافتراضية (مثل "root" أو "admin" أو "sa") غير موجودة في التطبيق أو أنها معطّلة. | 1 |
+| **6.3.3** | تحقق من أنه يجب استخدام إما آلية مصادقة متعددة العوامل أو تركيبة من آليات المصادقة أحادية العامل للوصول إلى التطبيق. وبالنسبة إلى المستوى 3، يجب أن يكون أحد العوامل آلية مصادقة قائمة على العتاد توفّر مقاومة للاختراق وانتحال الهوية أمام هجمات التصيّد، مع التحقق من نية المصادقة باشتراط إجراء يبدأه المستخدم (مثل الضغط على زر في مفتاح FIDO عتادي أو في هاتف محمول). وأي تخفيف لأي من الاعتبارات في هذا المتطلب يقتضي مبرّرًا موثّقًا بالكامل ومجموعة شاملة من الضوابط المخفِّفة. | 2 |
+| **6.3.4** | تحقق من أنه، إذا كان التطبيق يشتمل على مسارات مصادقة متعددة، فلا توجد مسارات غير موثّقة، ومن أن ضوابط الأمان وقوة المصادقة مُنفَذة باتساق. | 2 |
+| **6.3.5** | تحقق من إبلاغ المستخدمين بمحاولات المصادقة المشبوهة (الناجحة أو غير الناجحة). وقد يشمل ذلك محاولات المصادقة من موقع أو عميل غير معتاد، أو المصادقة الناجحة جزئيًا (أحد عوامل متعددة فقط)، أو محاولة مصادقة بعد فترة طويلة من عدم النشاط، أو مصادقة ناجحة بعد عدة محاولات غير ناجحة. | 3 |
+| **6.3.6** | تحقق من أن البريد الإلكتروني لا يُستخدم كآلية مصادقة أحادية العامل ولا متعددة العوامل. | 3 |
+| **6.3.7** | تحقق من إبلاغ المستخدمين بعد التحديثات على تفاصيل المصادقة، مثل إعادة تعيين بيانات الاعتماد أو تعديل اسم المستخدم أو عنوان البريد الإلكتروني. | 3 |
+| **6.3.8** | تحقق من عدم إمكانية استنتاج المستخدمين الصحيحين من تحديات المصادقة الفاشلة، مثل الاستناد إلى رسائل الأخطاء أو رموز استجابة HTTP أو اختلاف أوقات الاستجابة. ويجب أن تتوافر هذه الحماية كذلك في وظيفتي التسجيل ونسيان كلمة المرور. | 3 |
+
+## V6.4 دورة حياة عوامل المصادقة واستعادتها
+
+قد تشمل عوامل المصادقة كلمات المرور والرموز البرمجية والرموز العتادية وأجهزة القياسات الحيوية. والتعامل الآمن مع دورة حياة هذه الآليات بالغ الأهمية لأمان التطبيق، ويشتمل هذا القسم على متطلبات متعلقة بذلك.
+
+وتتعلق المتطلبات في هذا القسم في معظمها بـ [&sect; 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) أو [&sect; 6.1.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#replacement) من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html).
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **6.4.1** | تحقق من أن كلمات المرور الأولية أو رموز التنشيط التي يولّدها النظام تُولَّد عشوائيًا بأمان، وتتّبع سياسة كلمات المرور القائمة، وتنتهي صلاحيتها بعد فترة قصيرة أو بعد استخدامها أول مرة. ويجب ألا يُسمح لهذه الأسرار الأولية بأن تصبح كلمة المرور طويلة الأجل. | 1 |
+| **6.4.2** | تحقق من عدم وجود تلميحات لكلمات المرور أو مصادقة قائمة على المعرفة (ما يُسمّى "الأسئلة السرّية"). | 1 |
+| **6.4.3** | تحقق من تنفيذ عملية آمنة لإعادة تعيين كلمة مرور منسيّة، لا تتجاوز أي آليات مصادقة متعددة العوامل مُمكَّنة. | 2 |
+| **6.4.4** | تحقق من أنه، في حال فقدان أحد عوامل المصادقة متعددة العوامل، يُجرى إثبات للهوية بالمستوى نفسه المتّبع أثناء التسجيل. | 2 |
+| **6.4.5** | تحقق من أن تعليمات التجديد لآليات المصادقة التي تنتهي صلاحيتها تُرسل بوقت كافٍ لتنفيذها قبل انتهاء صلاحية آلية المصادقة القديمة، مع تهيئة تذكيرات مؤتمتة إذا لزم الأمر. | 3 |
+| **6.4.6** | تحقق من أن المستخدمين الإداريين يمكنهم بدء عملية إعادة تعيين كلمة المرور للمستخدم، لكن دون أن يتيح ذلك لهم تغيير كلمة مرور المستخدم أو اختيارها. وهذا يمنع وضعًا يعرفون فيه كلمة مرور المستخدم. | 3 |
+
+## V6.5 المتطلبات العامة للمصادقة متعددة العوامل
+
+يوفّر هذا القسم إرشادات عامة تكون ذات صلة بطرائق مصادقة متعددة العوامل مختلفة ومتنوعة.
+
+وتشمل الآليات ما يلي:
+
+* أسرار البحث
+* كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs)
+* الآليات خارج النطاق
+
+أسرار البحث هي قوائم مُولَّدة مسبقًا من الرموز السرّية، شبيهة بأرقام تخويل المعاملات (TAN) أو رموز استعادة وسائل التواصل الاجتماعي أو شبكة تحتوي على مجموعة من القيم العشوائية. ويُعدّ هذا النوع من آليات المصادقة "شيئًا تملكه" لأن الرموز غير قابلة للحفظ متعمّدًا ولذلك سيلزم تخزينها في مكان ما.
+
+وكلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) هي رموز فيزيائية أو برمجية تعرض تحديًا شبه عشوائي لمرة واحدة يتغيّر باستمرار. ويُعدّ هذا النوع من آليات المصادقة "شيئًا تملكه". وكلمات المرور لمرة واحدة متعددة العوامل شبيهة بأحادية العامل، لكنها تتطلّب إدخال رقم تعريف شخصي صحيح أو إلغاء قفل بالقياسات الحيوية أو إدخال USB أو إقران NFC أو قيمة إضافية (مثل حاسبات توقيع المعاملات) لإنشاء كلمة المرور لمرة واحدة النهائية (OTP).
+
+وستُقدَّم تفاصيل عن الآليات خارج النطاق في القسم التالي.
+
+وتتعلق المتطلبات في هذه الأقسام في معظمها بـ [&sect; 5.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-512-look-up-secrets) و[&sect; 5.1.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-513-out-of-band-devices) و[&sect; 5.1.4.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5142-single-factor-otp-verifiers) و[&sect; 5.1.5.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5152-multi-factor-otp-verifiers) و[&sect; 5.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#521-physical-authenticators) و[&sect; 5.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#523-use-of-biometrics) من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html).
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **6.5.1** | تحقق من أن أسرار البحث وطلبات أو رموز المصادقة خارج النطاق وكلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) لا يمكن استخدامها بنجاح إلا مرة واحدة. | 2 |
+| **6.5.2** | تحقق من أن أسرار البحث التي تقل عشوائيتها عن 112 بتًا (19 محرفًا أبجديًا رقميًا عشوائيًا أو 34 رقمًا عشوائيًا)، عند تخزينها في الواجهة الخلفية للتطبيق، تُلبَّد بخوارزمية تلبيد معتمدة لتخزين كلمات المرور تشتمل على ملح عشوائي بطول 32 بتًا. ويمكن استخدام دالة تلبيد قياسية إذا كانت عشوائية السر 112 بتًا أو أكثر. | 2 |
+| **6.5.3** | تحقق من أن أسرار البحث ورموز المصادقة خارج النطاق وبذور كلمات المرور لمرة واحدة المعتمدة على الوقت تُولَّد باستخدام مولّد أعداد شبه عشوائية آمن تشفيريًا (CSPRNG) لتجنّب القيم القابلة للتوقع. | 2 |
+| **6.5.4** | تحقق من أن أسرار البحث ورموز المصادقة خارج النطاق تمتلك 20 بتًا على الأقل من العشوائية (وعادةً يكفي 4 محارف أبجدية رقمية عشوائية أو 6 أرقام عشوائية). | 2 |
+| **6.5.5** | تحقق من أن طلبات أو رموز أو رموز المصادقة خارج النطاق المميزة، وكذلك كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs)، لها عمر محدّد. ويجب أن يكون للطلبات خارج النطاق عمر أقصى قدره 10 دقائق، ولكلمات المرور لمرة واحدة المعتمدة على الوقت عمر أقصى قدره 30 ثانية. | 2 |
+| **6.5.6** | تحقق من إمكانية إبطال أي عامل مصادقة (بما فيها الأجهزة الفيزيائية) في حال السرقة أو أي فقدان آخر. | 3 |
+| **6.5.7** | تحقق من أن آليات المصادقة بالقياسات الحيوية لا تُستخدم إلا كعوامل ثانوية إلى جانب إما شيء تملكه أو شيء تعرفه. | 3 |
+| **6.5.8** | تحقق من أن كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) تُفحص بناءً على مصدر وقت من خدمة موثوقة وليس من وقت غير موثوق أو مقدَّم من العميل. | 3 |
+
+## V6.6 آليات المصادقة خارج النطاق
+
+يتضمّن ذلك عادةً تواصل خادم المصادقة مع جهاز فيزيائي عبر قناة ثانوية آمنة. على سبيل المثال، إرسال إشعارات دفع إلى الأجهزة المحمولة. ويُعدّ هذا النوع من آليات المصادقة "شيئًا تملكه".
+
+ولا يُسمح بآليات المصادقة خارج النطاق غير الآمنة مثل البريد الإلكتروني والصوت عبر الإنترنت (VOIP). وتُعدّ المصادقة عبر شبكة الهاتف العمومية المبدّلة والرسائل القصيرة حاليًا [آليات مصادقة "مقيّدة"](https://pages.nist.gov/800-63-FAQ/#q-b01) لدى NIST وينبغي إيقافها لصالح كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) أو آلية تشفيرية أو ما شابه. ويوصي NIST SP 800-63B في [&sect; 5.1.3.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-5133-authentication-using-the-public-switched-telephone-network) بمعالجة مخاطر تبديل الجهاز أو تغيير بطاقة SIM أو نقل الرقم أو أي سلوك شاذ آخر، إذا كان لا بد من دعم المصادقة خارج النطاق عبر الهاتف أو الرسائل القصيرة. ومع أن هذا القسم من معيار التحقق من أمان التطبيقات لا يُلزم بذلك كمتطلب، فإن عدم اتخاذ هذه الاحتياطات في تطبيق حساس من المستوى 2 أو في تطبيق من المستوى 3 ينبغي أن يُنظر إليه كعلامة تحذير كبيرة.
+
+ولاحظ أن NIST قدّم كذلك مؤخرًا إرشادات [تثني عن استخدام إشعارات الدفع](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/#fig-3). ومع أن هذا القسم من معيار التحقق من أمان التطبيقات لا يفعل ذلك، فمن المهم الوعي بمخاطر "إغراق إشعارات الدفع".
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **6.6.1** | تحقق من أن آليات المصادقة التي تستخدم شبكة الهاتف العمومية المبدّلة (PSTN) لتسليم كلمات المرور لمرة واحدة (OTPs) عبر الهاتف أو الرسائل القصيرة لا تُقدَّم إلا إذا كان رقم الهاتف قد تم التحقق منه مسبقًا، وتُقدَّم كذلك طرائق بديلة أقوى (مثل كلمات المرور لمرة واحدة المعتمدة على الوقت)، وتوفّر الخدمة معلومات للمستخدمين عن مخاطرها الأمنية. وبالنسبة إلى تطبيقات المستوى 3، يجب ألا يكون الهاتف والرسائل القصيرة متاحين كخيارين. | 2 |
+| **6.6.2** | تحقق من أن طلبات أو رموز المصادقة خارج النطاق أو الرموز المميزة مرتبطة بطلب المصادقة الأصلي الذي وُلّدت من أجله وأنها غير قابلة للاستخدام في طلب سابق أو لاحق. | 2 |
+| **6.6.3** | تحقق من أن آلية المصادقة خارج النطاق القائمة على رمز محمية من هجمات القوة الغاشمة باستخدام تحديد المعدّل. وينبغي كذلك النظر في استخدام رمز بعشوائية لا تقل عن 64 بتًا. | 2 |
+| **6.6.4** | تحقق من أنه، حيث تُستخدم إشعارات الدفع للمصادقة متعددة العوامل، يُستخدم تحديد المعدّل لمنع هجمات إغراق إشعارات الدفع. وقد يخفّف مطابقة الأرقام من هذا الخطر كذلك. | 3 |
+
+## V6.7 آلية المصادقة التشفيرية
+
+تشمل آليات المصادقة التشفيرية البطاقات الذكية أو مفاتيح FIDO، حيث يتعيّن على المستخدم إدخال الجهاز التشفيري أو إقرانه بالحاسوب لإتمام المصادقة. ويرسل خادم المصادقة قيمة عشوائية للتحدي إلى الجهاز أو البرمجية التشفيرية، فيحسب الجهاز أو البرمجية استجابة بناءً على مفتاح تشفيري مخزَّن بأمان. وتوفّر المتطلبات في هذا القسم إرشادات خاصة بالتنفيذ لهذه الآليات، أما الإرشادات المتعلقة بخوارزميات التشفير فهي مشمولة في فصل "التشفير".
+
+وحيث تُستخدم مفاتيح مشتركة أو سرّية للمصادقة التشفيرية، ينبغي تخزينها باستخدام الآليات نفسها المستخدمة لأسرار النظام الأخرى، على النحو الموثّق في قسم "إدارة الأسرار" في فصل "التكوين".
+
+وتتعلق المتطلبات في هذا القسم في معظمها بـ [&sect; 5.1.7.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sfcdv) من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html).
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **6.7.1** | تحقق من أن الشهادات المستخدمة للتحقق من تأكيدات المصادقة التشفيرية مخزَّنة بطريقة تحميها من التعديل. | 3 |
+| **6.7.2** | تحقق من أن قيمة التحدي العشوائية لا يقل طولها عن 64 بتًا، وأنها فريدة إحصائيًا أو فريدة على مدى عمر الجهاز التشفيري. | 3 |
+
+## V6.8 المصادقة عبر مزوّد هوية
+
+يوفّر مزوّدو الهوية (IdPs) هوية اتحادية للمستخدمين. وكثيرًا ما يكون للمستخدمين أكثر من هوية لدى مزوّدي هوية متعددين، مثل هوية مؤسسية باستخدام Azure AD أو Okta أو Ping Identity أو Google، أو هوية استهلاكية باستخدام Facebook أو Twitter أو Google أو WeChat، على سبيل الذكر لبعض البدائل الشائعة. وهذه القائمة ليست تزكية لهذه الشركات أو الخدمات، بل مجرّد تشجيع للمطوّرين على مراعاة واقع أن كثيرًا من المستخدمين لديهم هويات مُرسَّخة كثيرة. وينبغي للمؤسسات النظر في التكامل مع هويات المستخدمين القائمة، وفق ملف مخاطر قوة إثبات الهوية لدى مزوّد الهوية. فعلى سبيل المثال، من غير المرجّح أن تقبل مؤسسة حكومية هوية من وسائل التواصل الاجتماعي كوسيلة دخول إلى أنظمة حساسة، إذ يسهل إنشاء هويات مزيّفة أو للاستخدام مرة واحدة، في حين قد تحتاج شركة ألعاب محمولة فعلًا إلى التكامل مع منصات التواصل الاجتماعي الكبرى لتنمية قاعدة لاعبيها النشطين.
+
+ويقتضي الاستخدام الآمن لمزوّدي الهوية الخارجيين تهيئة وتحققًا دقيقين لمنع انتحال الهوية أو تزوير التأكيدات. ويوفّر هذا القسم متطلبات لمعالجة هذه المخاطر.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **6.8.1** | تحقق من أنه، إذا كان التطبيق يدعم مزوّدي هوية متعددين (IdPs)، فلا يمكن انتحال هوية المستخدم عبر مزوّد هوية مدعوم آخر (مثلًا باستخدام معرّف المستخدم نفسه). والتخفيف القياسي أن يسجّل التطبيق المستخدم ويعرّفه باستخدام تركيبة من معرّف مزوّد الهوية (بوصفه مساحة أسماء) ومعرّف المستخدم لدى ذلك المزوّد. | 2 |
+| **6.8.2** | تحقق من أن وجود التوقيعات الرقمية على تأكيدات المصادقة وسلامتها (مثلًا على رموز JWT أو تأكيدات SAML) يُتحقَّق منهما دائمًا، مع رفض أي تأكيدات غير موقّعة أو ذات توقيعات غير صحيحة. | 2 |
+| **6.8.3** | تحقق من أن تأكيدات SAML تُعالَج على نحو فريد وتُستخدم مرة واحدة فقط خلال مدة الصلاحية لمنع هجمات إعادة الإرسال. | 2 |
+| **6.8.4** | تحقق من أنه، إذا كان التطبيق يستخدم مزوّد هوية منفصلًا (IdP) ويتوقع قوة أو طرائق أو حداثة مصادقة معيّنة لوظائف بعينها، فإن التطبيق يتحقق من ذلك باستخدام المعلومات التي يعيدها مزوّد الهوية. فعلى سبيل المثال، إذا استُخدم OIDC، فقد يتحقق ذلك بالتحقق من مطالبات رمز الهوية مثل 'acr' و'amr' و'auth_time' (إن وُجدت). وإذا لم يوفّر مزوّد الهوية هذه المعلومات، فيجب أن يكون للتطبيق منهج احتياطي موثّق يفترض أن آلية المصادقة الأدنى قوة قد استُخدمت (مثلًا مصادقة أحادية العامل باستخدام اسم المستخدم وكلمة المرور). | 2 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [NIST SP 800-63 - Digital Identity Guidelines](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf)
+* [NIST SP 800-63B - Authentication and Lifecycle Management](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf)
+* [NIST SP 800-63 FAQ](https://pages.nist.gov/800-63-FAQ/)
+* [OWASP Web Security Testing Guide: Testing for Authentication](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing)
+* [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)
+* [OWASP Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html)
+* [OWASP Choosing and Using Security Questions Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html)
+* [CISA Guidance on "Number Matching"](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf)
+* [Details on the FIDO Alliance](https://fidoalliance.org/)
diff --git a/5.0/ar/0x16-V7-Session-Management.md b/5.0/ar/0x16-V7-Session-Management.md
new file mode 100644
index 0000000000..d47e25c8d5
--- /dev/null
+++ b/5.0/ar/0x16-V7-Session-Management.md
@@ -0,0 +1,91 @@
+# V7 إدارة الجلسات
+
+## الهدف من ضوابط الأمان
+
+تتيح آليات إدارة الجلسات للتطبيقات ربط تفاعلات المستخدم والجهاز على مدار الزمن، حتى عند استخدام بروتوكولات اتصال عديمة الحالة (مثل HTTP). وقد تستخدم التطبيقات الحديثة رموز جلسة متعددة بخصائص وأغراض متمايزة. ونظام إدارة الجلسات الآمن هو الذي يمنع المهاجمين من الحصول على جلسة الضحية أو استخدامها أو إساءة استغلالها بأي صورة أخرى. ويجب على التطبيقات التي تحتفظ بجلسات أن تضمن استيفاء متطلبات إدارة الجلسات الرفيعة المستوى التالية:
+
+* أن تكون الجلسات فريدة لكل فرد ولا يمكن تخمينها أو مشاركتها.
+* أن تُبطل الجلسات عندما لا تعد لازمة وأن تنتهي مهلتها في فترات عدم النشاط.
+
+ويتعلق كثير من المتطلبات في هذا الفصل بضوابط مختارة من [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/)، مع التركيز على التهديدات الشائعة ونقاط ضعف المصادقة الشائعة الاستغلال.
+
+ولاحظ أن متطلبات تفاصيل التنفيذ المحدّدة لبعض آليات إدارة الجلسات يمكن العثور عليها في مواضع أخرى:
+
+* تُعدّ ملفات تعريف ارتباط HTTP آلية شائعة لتأمين رموز الجلسة. ويمكن العثور على المتطلبات الأمنية المحدّدة لملفات تعريف الارتباط في فصل "أمان واجهة الويب الأمامية".
+* تُستخدم الرموز المميزة المكتفية بذاتها كثيرًا كوسيلة للحفاظ على الجلسات. ويمكن العثور على المتطلبات الأمنية المحدّدة في فصل "الرموز المميزة المكتفية بذاتها".
+
+## V7.1 توثيق إدارة الجلسات
+
+لا يوجد نمط واحد يناسب جميع التطبيقات. ولذلك ليس من الممكن تحديد حدود وقيود عامة تناسب جميع الحالات. ويجب إجراء تحليل للمخاطر مع قرارات أمنية موثّقة متعلقة بالتعامل مع الجلسات كشرط مسبق للتنفيذ والاختبار. وهذا يضمن أن نظام إدارة الجلسات مُصمَّم وفق المتطلبات المحدّدة للتطبيق.
+
+وبصرف النظر عن اختيار آلية جلسة ذات حالة أو "عديمة الحالة"، يجب أن يكون التحليل كاملًا وموثّقًا لإثبات أن الحل المختار قادر على تلبية جميع المتطلبات الأمنية ذات الصلة. وينبغي كذلك مراعاة التفاعل مع أي آليات للدخول الموحّد (SSO) قيد الاستخدام.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **7.1.1** | تحقق من أن مهلة عدم نشاط جلسة المستخدم والعمر الأقصى المطلق للجلسة موثّقان، وملائمان بالاقتران مع ضوابط أخرى، ومن أن الوثائق تشتمل على تبرير لأي انحرافات عن متطلبات إعادة المصادقة في NIST SP 800-63B. | 2 |
+| **7.1.2** | تحقق من أن الوثائق تحدّد عدد الجلسات المتزامنة (المتوازية) المسموح بها لحساب واحد، وكذلك التصرّفات والإجراءات المقصودة التي ستُتّخذ عند بلوغ العدد الأقصى للجلسات النشطة. | 2 |
+| **7.1.3** | تحقق من توثيق جميع الأنظمة التي تنشئ جلسات المستخدمين وتديرها كجزء من منظومة إدارة هوية اتحادية (مثل أنظمة الدخول الموحّد)، إلى جانب الضوابط اللازمة لتنسيق أعمار الجلسات وإنهائها وأي شروط أخرى تقتضي إعادة المصادقة. | 2 |
+
+## V7.2 الأمان الأساسي لإدارة الجلسات
+
+يلبّي هذا القسم المتطلبات الجوهرية للجلسات الآمنة بالتحقق من أن رموز الجلسة تُولَّد ويُتحقَّق منها بأمان.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **7.2.1** | تحقق من أن التطبيق ينفّذ جميع عمليات التحقق من رموز الجلسة باستخدام خدمة موثوقة في الواجهة الخلفية. | 1 |
+| **7.2.2** | تحقق من أن التطبيق يستخدم رموزًا مكتفية بذاتها أو رموزًا مرجعية تُولَّد ديناميكيًا لإدارة الجلسات، أي أنه لا يستخدم أسرارًا ومفاتيح ثابتة لواجهات برمجة التطبيقات. | 1 |
+| **7.2.3** | تحقق من أنه، إذا استُخدمت الرموز المرجعية لتمثيل جلسات المستخدمين، فإنها فريدة ومُولَّدة باستخدام مولّد أعداد شبه عشوائية آمن تشفيريًا (CSPRNG) وتمتلك 128 بتًا على الأقل من العشوائية. | 1 |
+| **7.2.4** | تحقق من أن التطبيق يولّد رمز جلسة جديدًا عند مصادقة المستخدم، بما في ذلك إعادة المصادقة، وينهي رمز الجلسة الحالي. | 1 |
+
+## V7.3 مهلة الجلسة
+
+تخدم آليات مهلة الجلسة غرض تقليص نافذة الفرصة لاختطاف الجلسة وغيره من أشكال إساءة استغلال الجلسة. ويجب أن تلبّي المهل القرارات الأمنية الموثّقة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **7.3.1** | تحقق من وجود مهلة لعدم النشاط بحيث تُنفَذ إعادة المصادقة وفق تحليل المخاطر والقرارات الأمنية الموثّقة. | 2 |
+| **7.3.2** | تحقق من وجود عمر أقصى مطلق للجلسة بحيث تُنفَذ إعادة المصادقة وفق تحليل المخاطر والقرارات الأمنية الموثّقة. | 2 |
+
+## V7.4 إنهاء الجلسة
+
+قد يتولى إنهاء الجلسة التطبيق نفسه أو مزوّد الدخول الموحّد إذا كان المزوّد هو من يتولى إدارة الجلسات بدلًا من التطبيق. وقد يكون من الضروري تحديد ما إذا كان مزوّد الدخول الموحّد داخلًا في النطاق عند النظر في متطلبات هذا القسم، إذ قد يتحكّم المزوّد في بعضها.
+
+وينبغي أن يؤدي إنهاء الجلسة إلى اشتراط إعادة المصادقة وأن يكون نافذًا على امتداد التطبيق وتسجيل الدخول الاتحادي (إن وُجد) وأي أطراف معوِّلة.
+
+وبالنسبة إلى آليات الجلسات ذات الحالة، يتضمّن الإنهاء عادةً إبطال الجلسة في الواجهة الخلفية. أما في حالة الرموز المميزة المكتفية بذاتها، فيلزم اتخاذ تدابير إضافية لإبطال هذه الرموز أو حجبها، إذ قد تبقى صالحة حتى انتهاء صلاحيتها.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **7.4.1** | تحقق من أن التطبيق، عند تشغيل إنهاء الجلسة (مثل تسجيل الخروج أو انتهاء الصلاحية)، يمنع أي استخدام إضافي للجلسة. وبالنسبة إلى الرموز المرجعية أو الجلسات ذات الحالة، يعني ذلك إبطال بيانات الجلسة في الواجهة الخلفية للتطبيق. أما التطبيقات التي تستخدم رموزًا مكتفية بذاتها فستحتاج إلى حل مثل الاحتفاظ بقائمة بالرموز المنتهية، أو منع الرموز المُنتَجة قبل تاريخ ووقت محدّدين لكل مستخدم، أو تدوير مفتاح توقيع خاص بكل مستخدم. | 1 |
+| **7.4.2** | تحقق من أن التطبيق ينهي جميع الجلسات النشطة عند تعطيل حساب مستخدم أو حذفه (مثل مغادرة موظف للشركة). | 1 |
+| **7.4.3** | تحقق من أن التطبيق يمنح خيار إنهاء جميع الجلسات النشطة الأخرى بعد نجاح تغيير أي عامل مصادقة أو إزالته (بما في ذلك تغيير كلمة المرور عن طريق إعادة التعيين أو الاستعادة، وتحديث إعدادات المصادقة متعددة العوامل إن وُجدت). | 2 |
+| **7.4.4** | تحقق من أن جميع الصفحات التي تتطلّب مصادقة تتيح وصولًا سهلًا وظاهرًا إلى وظيفة تسجيل الخروج. | 2 |
+| **7.4.5** | تحقق من أن مسؤولي التطبيق قادرون على إنهاء الجلسات النشطة لمستخدم فردي أو لجميع المستخدمين. | 2 |
+
+## V7.5 الدفاعات ضد إساءة استغلال الجلسة
+
+يوفّر هذا القسم متطلبات للتخفيف من المخاطر التي تمثّلها الجلسات النشطة التي تُختطَف أو يُساء استغلالها عبر متجهات تعتمد على وجود جلسات المستخدمين النشطة وقدراتها. على سبيل المثال، استخدام تنفيذ محتوى ضار لإجبار متصفح ضحية مصادَق عليه على تنفيذ إجراء باستخدام جلسة الضحية.
+
+ولاحظ أنه ينبغي مراعاة الإرشادات الخاصة بالمستويات في فصل "المصادقة" عند النظر في متطلبات هذا القسم.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **7.5.1** | تحقق من أن التطبيق يتطلّب إعادة مصادقة كاملة قبل السماح بتعديل سمات الحساب الحساسة التي قد تؤثّر في المصادقة، مثل عنوان البريد الإلكتروني أو رقم الهاتف أو تكوين المصادقة متعددة العوامل أو غيرها من المعلومات المستخدمة في استعادة الحساب. | 2 |
+| **7.5.2** | تحقق من أن المستخدمين قادرون على عرض أي من الجلسات النشطة حاليًا أو جميعها وإنهائها (بعد إعادة المصادقة بعامل واحد على الأقل). | 2 |
+| **7.5.3** | تحقق من أن التطبيق يتطلّب مصادقة إضافية بعامل واحد على الأقل أو تحققًا ثانويًا قبل تنفيذ المعاملات أو العمليات البالغة الحساسية. | 3 |
+
+## V7.6 إعادة المصادقة الاتحادية
+
+يتعلق هذا القسم بمن يكتبون شيفرة الطرف المعوِّل (RP) أو مزوّد الهوية (IdP). وهذه المتطلبات مستقاة من [NIST SP 800-63C](https://pages.nist.gov/800-63-4/sp800-63c.html) الخاص بالاتحاد والتأكيدات.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **7.6.1** | تحقق من أن عمر الجلسة وإنهاءها بين الأطراف المعوِّلة (RPs) ومزوّدي الهوية (IdPs) يسلكان على النحو الموثّق، مع اشتراط إعادة المصادقة عند الضرورة، مثل بلوغ الحد الأقصى للمدة بين أحداث المصادقة لدى مزوّد الهوية. | 2 |
+| **7.6.2** | تحقق من أن إنشاء الجلسة يتطلّب إما موافقة المستخدم أو إجراءً صريحًا، بما يمنع إنشاء جلسات تطبيق جديدة دون تفاعل المستخدم. | 2 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP Web Security Testing Guide: Session Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing)
+* [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)
diff --git a/5.0/ar/0x17-V8-Authorization.md b/5.0/ar/0x17-V8-Authorization.md
new file mode 100644
index 0000000000..d504092c31
--- /dev/null
+++ b/5.0/ar/0x17-V8-Authorization.md
@@ -0,0 +1,56 @@
+# V8 التخويل
+
+## الهدف من ضوابط الأمان
+
+يضمن التخويل أن الوصول لا يُمنح إلا للمستهلكين المسموح لهم (المستخدمون والخوادم والعملاء الآخرون). ولإنفاذ مبدأ الحد الأدنى من الصلاحيات (POLP)، يجب أن تستوفي التطبيقات المتحقَّق منها المتطلبات الرفيعة المستوى التالية:
+
+* توثيق قواعد التخويل، بما في ذلك عوامل اتخاذ القرار والسياقات البيئية.
+* ينبغي أن يكون للمستهلكين وصول إلى الموارد التي تسمح بها استحقاقاتهم المحدّدة فقط.
+
+## V8.1 توثيق التخويل
+
+إن التوثيق الشامل للتخويل ضروري للتأكد من أن القرارات الأمنية تُطبَّق باتساق وقابلة للتدقيق ومتوافقة مع سياسات المؤسسة. وهذا يقلّل خطر الوصول غير المصرَّح به بجعل متطلبات الأمان واضحة وقابلة للتنفيذ للمطوّرين والمسؤولين والمختبرين.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **8.1.1** | تحقق من أن توثيق التخويل يحدّد قواعد لتقييد الوصول على مستوى الوظائف والوصول الخاص بالبيانات بناءً على صلاحيات المستهلك وسمات الموارد. | 1 |
+| **8.1.2** | تحقق من أن توثيق التخويل يحدّد قواعد لتقييد الوصول على مستوى الحقول (للقراءة والكتابة على حد سواء) بناءً على صلاحيات المستهلك وسمات الموارد. ولاحظ أن هذه القواعد قد تعتمد على قيم سمات أخرى لكائن البيانات المعني، مثل الحالة أو الوضع. | 2 |
+| **8.1.3** | تحقق من أن وثائق التطبيق تحدّد السمات البيئية والسياقية (بما في ذلك، على سبيل المثال لا الحصر، وقت اليوم أو موقع المستخدم أو عنوان IP أو الجهاز) المستخدمة في التطبيق لاتخاذ القرارات الأمنية، بما فيها القرارات المتعلقة بالمصادقة والتخويل. | 3 |
+| **8.1.4** | تحقق من أن وثائق المصادقة والتخويل تحدّد كيفية استخدام العوامل البيئية والسياقية في اتخاذ القرار، إضافةً إلى التخويل على مستوى الوظائف والبيانات والحقول. وينبغي أن يشمل ذلك السمات التي تُقيَّم وحدود المخاطر والإجراءات المتّخذة (مثل السماح أو التحدي أو المنع أو المصادقة المعزّزة). | 3 |
+
+## V8.2 التصميم العام للتخويل
+
+إن تنفيذ ضوابط تخويل دقيقة على مستويات الوظائف والبيانات والحقول يضمن أن المستهلكين لا يمكنهم الوصول إلا إلى ما مُنح لهم صراحةً.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **8.2.1** | تحقق من أن التطبيق يضمن أن الوصول على مستوى الوظائف مقصور على المستهلكين ذوي الصلاحيات الصريحة. | 1 |
+| **8.2.2** | تحقق من أن التطبيق يضمن أن الوصول الخاص بالبيانات مقصور على المستهلكين ذوي الصلاحيات الصريحة لعناصر بيانات محدّدة، وذلك للتخفيف من الإشارة المباشرة غير الآمنة إلى الكائنات (IDOR) والتخويل المعطوب على مستوى الكائن (BOLA). | 1 |
+| **8.2.3** | تحقق من أن التطبيق يضمن أن الوصول على مستوى الحقول مقصور على المستهلكين ذوي الصلاحيات الصريحة لحقول محدّدة، وذلك للتخفيف من التخويل المعطوب على مستوى خصائص الكائن (BOPLA). | 2 |
+| **8.2.4** | تحقق من تنفيذ ضوابط أمنية تكيّفية مبنية على السمات البيئية والسياقية للمستهلك (مثل وقت اليوم أو الموقع أو عنوان IP أو الجهاز) لقرارات المصادقة والتخويل، على النحو المحدّد في وثائق التطبيق. ويجب تطبيق هذه الضوابط عندما يحاول المستهلك بدء جلسة جديدة وكذلك أثناء جلسة قائمة. | 3 |
+
+## V8.3 التخويل على مستوى العمليات
+
+إن التطبيق الفوري لتغييرات التخويل في الطبقة المناسبة من معمارية التطبيق أمر بالغ الأهمية لمنع الإجراءات غير المصرَّح بها، وخصوصًا في البيئات الديناميكية.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **8.3.1** | تحقق من أن التطبيق يُنفِذ قواعد التخويل في طبقة خدمة موثوقة ولا يعتمد على ضوابط يمكن لمستهلك غير موثوق التلاعب بها، مثل JavaScript من جانب العميل. | 1 |
+| **8.3.2** | تحقق من أن التغييرات في القيم التي تُتخذ على أساسها قرارات التخويل تُطبَّق فورًا. وحيث لا يمكن تطبيق التغييرات فورًا (مثل حالة الاعتماد على بيانات في رموز مميزة مكتفية بذاتها)، يجب أن توجد ضوابط مخفِّفة للتنبيه عندما ينفّذ المستهلك إجراءً لم يعد مصرَّحًا له بتنفيذه، ولإرجاع التغيير. ولاحظ أن هذا البديل لن يخفّف من تسريب المعلومات. | 3 |
+| **8.3.3** | تحقق من أن الوصول إلى كائن يستند إلى صلاحيات الذات الأصلية (مثل المستهلك)، وليس إلى صلاحيات أي وسيط أو خدمة تعمل بالنيابة عنه. على سبيل المثال، إذا استدعى مستهلك خدمة ويب باستخدام رمز مميز مكتفٍ بذاته للمصادقة، ثم طلبت الخدمة بيانات من خدمة أخرى، فستستخدم الخدمة الثانية رمز المستهلك، وليس رمزًا من آلة إلى آلة من الخدمة الأولى، لاتخاذ قرارات الصلاحيات. | 3 |
+
+## V8.4 اعتبارات أخرى للتخويل
+
+تساعد الاعتبارات الإضافية للتخويل، وخصوصًا لواجهات الإدارة والبيئات متعددة المستأجرين، على منع الوصول غير المصرَّح به.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **8.4.1** | تحقق من أن التطبيقات متعددة المستأجرين تستخدم ضوابط عبر المستأجرين للتأكد من أن عمليات المستهلك لن تؤثر أبدًا في مستأجرين لا يمتلك صلاحيات التفاعل معهم. | 2 |
+| **8.4.2** | تحقق من أن الوصول إلى واجهات الإدارة يشتمل على طبقات أمان متعددة، بما في ذلك التحقق المستمر من هوية المستهلك وتقييم الوضع الأمني للجهاز وتحليل المخاطر السياقي، بما يضمن ألا يكون موقع الشبكة أو نقاط النهاية الموثوقة العوامل الوحيدة للتخويل، وإن كانت قد تقلّل احتمال الوصول غير المصرَّح به. | 3 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP Web Security Testing Guide: Authorization](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/05-Authorization_Testing)
+* [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
diff --git a/5.0/ar/0x18-V9-Self-contained-Tokens.md b/5.0/ar/0x18-V9-Self-contained-Tokens.md
new file mode 100644
index 0000000000..a983db5811
--- /dev/null
+++ b/5.0/ar/0x18-V9-Self-contained-Tokens.md
@@ -0,0 +1,36 @@
+# V9 الرموز المميزة المكتفية بذاتها
+
+## الهدف من ضوابط الأمان
+
+ورد مفهوم الرمز المميز المكتفي بذاته في الأصل في RFC 6749 الخاص بـ OAuth 2.0 لعام 2012. وهو يشير إلى رمز مميز يحتوي على بيانات أو مطالبات تعوّل عليها خدمة مستقبِلة لاتخاذ قرارات أمنية. وينبغي تمييز ذلك عن رمز مميز بسيط يحتوي على معرّف فقط، تستخدمه الخدمة المستقبِلة للبحث عن البيانات محليًا. وأشهر أمثلة الرموز المميزة المكتفية بذاتها هي رموز JSON Web Tokens (JWTs) وتأكيدات SAML.
+
+أصبح استخدام الرموز المميزة المكتفية بذاتها واسع الانتشار جدًا، حتى خارج نطاق OAuth وOIDC. وفي الوقت نفسه، يعتمد أمان هذه الآلية على القدرة على التحقق من سلامة الرمز والتأكد من أنه صالح لسياق معيّن. وهناك مزالق كثيرة في هذه العملية، ويوفّر هذا الفصل تفاصيل محدّدة عن الآليات التي ينبغي أن تتوافر في التطبيقات لمنعها.
+
+## V9.1 مصدر الرمز المميز وسلامته
+
+يشتمل هذا القسم على متطلبات للتأكد من أن الرمز المميز قد أنتجه طرف موثوق وأنه لم يُتلاعب به.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **9.1.1** | تحقق من أن الرموز المميزة المكتفية بذاتها يتم التحقق منها باستخدام توقيعها الرقمي أو رمز مصادقة الرسالة (MAC) للحماية من التلاعب قبل قبول محتوياتها. | 1 |
+| **9.1.2** | تحقق من أن الخوارزميات المدرجة في قائمة سماح هي وحدها التي يمكن استخدامها لإنشاء الرموز المميزة المكتفية بذاتها والتحقق منها، في سياق معيّن. ويجب أن تتضمّن قائمة السماح الخوارزميات المسموح بها، ومن الأفضل أن تكون خوارزميات متناظرة فقط أو غير متناظرة فقط، ويجب ألا تتضمّن الخوارزمية 'None'. وإذا كان يجب دعم النوعين المتناظر وغير المتناظر، فستكون هناك حاجة إلى ضوابط إضافية لمنع الالتباس في المفاتيح. | 1 |
+| **9.1.3** | تحقق من أن مادة المفاتيح المستخدمة للتحقق من الرموز المميزة المكتفية بذاتها تأتي من مصادر موثوقة مُهيّأة مسبقًا لجهة إصدار الرمز، ما يمنع المهاجمين من تحديد مصادر ومفاتيح غير موثوقة. وبالنسبة إلى رموز JWT وغيرها من بِنى JWS، يجب التحقق من ترويسات مثل 'jku' و'x5u' و'jwk' مقابل قائمة سماح بالمصادر الموثوقة. | 1 |
+
+## V9.2 محتوى الرمز المميز
+
+قبل اتخاذ قرارات أمنية بناءً على محتوى رمز مميز مكتفٍ بذاته، من الضروري التحقق من أن الرمز قد قُدّم خلال مدة صلاحيته وأنه مخصّص للاستخدام من قِبل الخدمة المستقبِلة وللغرض الذي قُدّم من أجله. وهذا يساعد على تجنّب الاستخدام المتقاطع غير الآمن بين خدمات مختلفة أو مع أنواع رموز مختلفة من الجهة المُصدِرة نفسها.
+
+أما المتطلبات الخاصة بـ OAuth وOIDC فهي مشمولة في الفصل المخصّص لها.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **9.2.1** | تحقق من أنه، في حال وجود مدة صلاحية في بيانات الرمز المميز، لا يُقبل الرمز ومحتواه إلا إذا كان وقت التحقق واقعًا داخل مدة الصلاحية هذه. على سبيل المثال، بالنسبة إلى رموز JWT، يجب التحقق من المطالبتين 'nbf' و'exp'. | 1 |
+| **9.2.2** | تحقق من أن الخدمة التي تستقبل رمزًا مميزًا تتحقق من أنه من النوع الصحيح وأنه مخصّص للغرض المقصود قبل قبول محتوياته. على سبيل المثال، لا يمكن قبول سوى رموز الوصول لقرارات التخويل، ولا يمكن استخدام سوى رموز الهوية (ID Tokens) لإثبات مصادقة المستخدم. | 2 |
+| **9.2.3** | تحقق من أن الخدمة لا تقبل سوى الرموز المميزة المخصّصة للاستخدام معها (الجهة المستهدفة). وبالنسبة إلى رموز JWT، يمكن تحقيق ذلك بالتحقق من مطالبة 'aud' مقابل قائمة سماح محدّدة في الخدمة. | 2 |
+| **9.2.4** | تحقق من أنه، إذا كانت جهة إصدار الرموز تستخدم المفتاح الخاص نفسه لإصدار رموز لجهات مستهدفة مختلفة، فإن الرموز الصادرة تحتوي على قيد للجهة المستهدفة يعرّف الجهات المقصودة تعريفًا فريدًا. وهذا سيمنع إعادة استخدام الرمز مع جهة مستهدفة غير مقصودة. وإذا كان معرّف الجهة المستهدفة يُمنح ديناميكيًا، فيجب على جهة إصدار الرموز التحقق من هذه الجهات للتأكد من أنها لا تؤدي إلى انتحال هوية الجهة المستهدفة. | 2 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP JSON Web Token Cheat Sheet for Java Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (لكنه يتضمّن إرشادات عامة مفيدة)
diff --git a/5.0/ar/0x19-V10-OAuth-and-OIDC.md b/5.0/ar/0x19-V10-OAuth-and-OIDC.md
new file mode 100644
index 0000000000..6177b21e84
--- /dev/null
+++ b/5.0/ar/0x19-V10-OAuth-and-OIDC.md
@@ -0,0 +1,169 @@
+# V10 معياري OAuth وOIDC
+
+## الهدف من ضوابط الأمان
+
+إن OAuth2 (المشار إليه بـ OAuth في هذا الفصل) إطار عمل معياري في الصناعة للتخويل المفوَّض. فعلى سبيل المثال، يمكن لتطبيق عميل، باستخدام OAuth، أن يحصل على وصول إلى واجهات برمجة التطبيقات (موارد الخادم) بالنيابة عن مستخدم، بشرط أن يكون المستخدم قد خوّل تطبيق العميل بذلك.
+
+وليس OAuth بحد ذاته مصمّمًا لمصادقة المستخدمين. ويوسّع إطار عمل OpenID Connect (OIDC) نطاق OAuth بإضافة طبقة هوية للمستخدم فوقه. ويوفّر OIDC دعمًا لميزات منها معلومات المستخدم الموحّدة والدخول الموحّد (SSO) وإدارة الجلسات. وبما أن OIDC امتداد لـ OAuth، فإن متطلبات OAuth في هذا الفصل تنطبق على OIDC كذلك.
+
+وتُعرَّف الأدوار التالية في OAuth:
+
+* عميل OAuth هو التطبيق الذي يحاول الحصول على وصول إلى موارد الخادم (مثلًا باستدعاء واجهة برمجة تطبيقات باستخدام رمز الوصول الصادر). وعميل OAuth كثيرًا ما يكون تطبيقًا من جانب الخادم.
+    * العميل السرّي هو عميل قادر على الحفاظ على سرّية بيانات الاعتماد التي يستخدمها للمصادقة على نفسه لدى خادم التخويل.
+    * العميل العام غير قادر على الحفاظ على سرّية بيانات الاعتماد اللازمة للمصادقة لدى خادم التخويل. ولذلك، فبدلًا من المصادقة على نفسه (مثلًا باستخدام المعاملين 'client_id' و'client_secret')، فإنه يعرّف نفسه فقط (باستخدام المعامل 'client_id').
+* خادم موارد OAuth (RS) هو واجهة برمجة تطبيقات الخادم التي تعرض الموارد لعملاء OAuth.
+* خادم تخويل OAuth (AS) هو تطبيق خادم يُصدر رموز الوصول لعملاء OAuth. وتتيح رموز الوصول هذه لعملاء OAuth الوصول إلى موارد خادم الموارد، إما بالنيابة عن مستخدم نهائي أو بالنيابة عن عميل OAuth نفسه. وكثيرًا ما يكون خادم التخويل تطبيقًا منفصلًا، لكنه قد يكون (إذا كان ذلك ملائمًا) مدمجًا في خادم موارد مناسب.
+* مالك الموارد (RO) هو المستخدم النهائي الذي يخوّل عملاء OAuth للحصول على وصول محدود إلى الموارد المستضافة على خادم الموارد بالنيابة عنه. ويوافق مالك الموارد على هذا التخويل المفوَّض بالتفاعل مع خادم التخويل.
+
+وتُعرَّف الأدوار التالية في OIDC:
+
+* الطرف المعوِّل (RP) هو تطبيق العميل الذي يطلب مصادقة المستخدم النهائي عبر مزوّد OpenID. وهو يتولى دور عميل OAuth.
+* مزوّد OpenID (OP) هو خادم تخويل OAuth قادر على مصادقة المستخدم النهائي ويوفّر مطالبات OIDC للطرف المعوِّل. وقد يكون مزوّد OpenID هو مزوّد الهوية (IdP)، لكن في السيناريوهات الاتحادية قد يكون مزوّد OpenID ومزوّد الهوية (الذي يصادق المستخدم النهائي لديه) تطبيقَي خادم مختلفين.
+
+وقد صُمِّم OAuth وOIDC في البداية لتطبيقات الأطراف الثالثة. وهما اليوم يُستخدمان كثيرًا من قِبل تطبيقات الطرف الأول كذلك. لكن عند استخدامهما في سيناريوهات الطرف الأول، مثل المصادقة وإدارة الجلسات، يضيف البروتوكول بعض التعقيد، ما قد يُدخل تحديات أمنية جديدة.
+
+ويمكن استخدام OAuth وOIDC في أنواع كثيرة من التطبيقات، لكن تركيز معيار التحقق من أمان التطبيقات والمتطلبات في هذا الفصل على تطبيقات الويب وواجهات برمجة التطبيقات.
+
+وبما أن OAuth وOIDC يمكن اعتبارهما منطقًا فوق تقنيات الويب، فإن المتطلبات العامة من الفصول الأخرى تنطبق دائمًا، ولا يمكن أخذ هذا الفصل خارج سياقه.
+
+ويتناول هذا الفصل الممارسات الفضلى الراهنة لـ OAuth2 وOIDC بما يتوافق مع المواصفات الموجودة في <https://oauth.net/2/> و<https://openid.net/developers/specs/>. وحتى إن كانت وثائق RFC تُعدّ ناضجة، فإنها تُحدَّث بصورة متكرّرة. ولذلك من المهم التوافق مع أحدث الإصدارات عند تطبيق المتطلبات في هذا الفصل. انظر قسم المراجع لمزيد من التفاصيل.
+
+وبالنظر إلى تعقيد هذا المجال، فمن الأهمية الحيوية لأي حل آمن يعتمد OAuth أو OIDC أن يستخدم خوادم تخويل معيارية معروفة في الصناعة وأن يطبّق التكوين الأمني الموصى به.
+
+والمصطلحات المستخدمة في هذا الفصل متوافقة مع وثائق RFC الخاصة بـ OAuth ومواصفات OIDC، لكن لاحظ أن مصطلحات OIDC لا تُستخدم إلا في المتطلبات الخاصة بـ OIDC؛ وفيما عدا ذلك تُستخدم مصطلحات OAuth.
+
+وفي سياق OAuth وOIDC، يشير مصطلح "الرمز المميز" في هذا الفصل إلى:
+
+* رموز الوصول، التي لا يجوز أن يستهلكها إلا خادم الموارد، ويمكن أن تكون إما رموزًا مرجعية يُتحقَّق منها بالاستبطان أو رموزًا مكتفية بذاتها يُتحقَّق منها باستخدام مادة مفاتيح ما.
+* رموز التحديث، التي لا يجوز أن يستهلكها إلا خادم التخويل الذي أصدر الرمز.
+* رموز الهوية في OIDC، التي لا يجوز أن يستهلكها إلا العميل الذي استهلّ مسار التخويل.
+
+وتعتمد مستويات المخاطر لبعض المتطلبات في هذا الفصل على ما إذا كان العميل عميلًا سرّيًا أو يُعدّ عميلًا عامًا. وبما أن استخدام مصادقة قوية للعميل يخفّف من متجهات هجوم كثيرة، فقد تُخفَّف بعض المتطلبات عند استخدام عميل سرّي في تطبيقات المستوى 1.
+
+## V10.1 الأمان العام لـ OAuth وOIDC
+
+يتناول هذا القسم المتطلبات المعمارية العامة التي تنطبق على جميع التطبيقات التي تستخدم OAuth أو OIDC.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **10.1.1** | تحقق من أن الرموز المميزة لا تُرسل إلا إلى المكوّنات التي تحتاج إليها حصرًا. فعلى سبيل المثال، عند استخدام نمط الواجهة الخلفية للواجهة الأمامية في تطبيقات JavaScript القائمة على المتصفح، لا يجوز أن تكون رموز الوصول والتحديث متاحة إلا للواجهة الخلفية. | 2 |
+| **10.1.2** | تحقق من أن العميل لا يقبل القيم الواردة من خادم التخويل (مثل رمز التخويل أو رمز الهوية) إلا إذا كانت هذه القيم ناتجة عن مسار تخويل استهلّته جلسة وكيل المستخدم والمعاملة نفسها. ويقتضي ذلك أن تكون الأسرار التي يولّدها العميل، مثل 'code_verifier' الخاص بمفتاح إثبات تبادل الرمز (PKCE) أو 'state' أو 'nonce' في OIDC، غير قابلة للتخمين وخاصة بالمعاملة ومرتبطة بأمان بكل من العميل وجلسة وكيل المستخدم التي بدأت فيها المعاملة. | 2 |
+
+## V10.2 عميل OAuth
+
+تبيّن هذه المتطلبات مسؤوليات تطبيقات عميل OAuth. وقد يكون العميل، على سبيل المثال، واجهة خلفية لخادم ويب (تعمل غالبًا كواجهة خلفية للواجهة الأمامية، BFF)، أو تكاملًا لخدمة في الواجهة الخلفية، أو تطبيق صفحة واحدة في الواجهة الأمامية (SPA، المعروف كذلك بالتطبيق القائم على المتصفح).
+
+وعمومًا، تُعدّ عملاء الواجهة الخلفية عملاء سرّيين وتُعدّ عملاء الواجهة الأمامية عملاء عامين. لكن التطبيقات الأصيلة التي تعمل على جهاز المستخدم النهائي يمكن أن تُعدّ سرّية عند استخدام التسجيل الديناميكي للعملاء في OAuth.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **10.2.1** | تحقق من أن عميل OAuth، في حال استخدام مسار الرمز، يمتلك حماية من هجمات تزوير الطلبات القائمة على المتصفح، المعروفة عمومًا بتزوير الطلبات عبر المواقع (CSRF)، التي تُشغّل طلبات الرموز، وذلك إما باستخدام وظيفة مفتاح إثبات تبادل الرمز (PKCE) أو بفحص المعامل 'state' الذي أُرسل في طلب التخويل. | 2 |
+| **10.2.2** | تحقق من أن عميل OAuth، إذا كان يمكنه التفاعل مع أكثر من خادم تخويل، يمتلك دفاعًا عن هجمات الخلط. فعلى سبيل المثال، قد يشترط أن يعيد خادم التخويل قيمة المعامل 'iss' وأن يتحقق منها في استجابة التخويل واستجابة الرمز. | 2 |
+| **10.2.3** | تحقق من أن عميل OAuth لا يطلب سوى النطاقات المطلوبة (أو معاملات التخويل الأخرى) في الطلبات الموجّهة إلى خادم التخويل. | 3 |
+
+## V10.3 خادم موارد OAuth
+
+في سياق معيار التحقق من أمان التطبيقات وهذا الفصل، يكون خادم الموارد واجهة برمجة تطبيقات. ولتوفير وصول آمن، يجب على خادم الموارد أن:
+
+* يتحقق من رمز الوصول، وفق صيغة الرمز ومواصفات البروتوكول المعنية، مثل التحقق من JWT أو استبطان رموز OAuth.
+* يُنفِذ، إذا كان الرمز صحيحًا، قرارات التخويل بناءً على المعلومات المستقاة من رمز الوصول والصلاحيات التي مُنحت. فعلى سبيل المثال، يلزم خادم الموارد أن يتحقق من أن العميل (العامل بالنيابة عن مالك الموارد) مخوَّل بالوصول إلى المورد المطلوب.
+
+ولذلك فإن المتطلبات المدرجة هنا خاصة بـ OAuth أو OIDC وينبغي تنفيذها بعد التحقق من الرمز وقبل تنفيذ التخويل بناءً على المعلومات المستقاة منه.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **10.3.1** | تحقق من أن خادم الموارد لا يقبل سوى رموز الوصول المخصّصة للاستخدام مع تلك الخدمة (الجهة المستهدفة). وقد تكون الجهة المستهدفة مُدرجة في رمز وصول مُهيكل (مثل مطالبة 'aud' في JWT)، أو يمكن فحصها باستخدام نقطة نهاية استبطان الرموز. | 2 |
+| **10.3.2** | تحقق من أن خادم الموارد يُنفِذ قرارات التخويل بناءً على المطالبات المستقاة من رمز الوصول التي تحدّد التخويل المفوَّض. وإذا كانت مطالبات مثل 'sub' و'scope' و'authorization_details' موجودة، فيجب أن تكون جزءًا من القرار. | 2 |
+| **10.3.3** | تحقق من أنه، إذا كان قرار التحكم في الوصول يقتضي تحديد مستخدم فريد من رمز وصول (JWT أو استجابة استبطان الرمز المتصلة به)، فإن خادم الموارد يحدّد المستخدم من مطالبات لا يمكن إعادة تخصيصها لمستخدمين آخرين. ويعني ذلك عادةً استخدام تركيبة من مطالبتي 'iss' و'sub'. | 2 |
+| **10.3.4** | تحقق من أن خادم الموارد، إذا كان يشترط قوة أو طرائق أو حداثة مصادقة معيّنة، يتحقق من أن رمز الوصول المُقدَّم يستوفي هذه القيود. فعلى سبيل المثال، باستخدام مطالبات OIDC 'acr' و'amr' و'auth_time' على التوالي، إن وُجدت. | 2 |
+| **10.3.5** | تحقق من أن خادم الموارد يمنع استخدام رموز الوصول المسروقة أو إعادة إرسال رموز الوصول (من أطراف غير مصرَّح لها) باشتراط رموز وصول مقيَّدة بالمُرسِل، إما باستخدام TLS المتبادل لـ OAuth 2 أو إثبات الحيازة (DPoP) في OAuth 2. | 3 |
+
+## V10.4 خادم تخويل OAuth
+
+تبيّن هذه المتطلبات مسؤوليات خوادم تخويل OAuth، بما فيها مزوّدو OpenID.
+
+وبالنسبة إلى مصادقة العميل، يُسمح بطريقة 'self_signed_tls_client_auth' بالشروط المسبقة التي يقتضيها [القسم 2.2](https://datatracker.ietf.org/doc/html/rfc8705#name-self-signed-certificate-mut) من [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705).
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **10.4.1** | تحقق من أن خادم التخويل يتحقق من معرّفات إعادة التوجيه بناءً على قائمة سماح خاصة بالعميل تتضمّن معرّفات مسجّلة مسبقًا، باستخدام مقارنة نصية دقيقة. | 1 |
+| **10.4.2** | تحقق من أنه، إذا أعاد خادم التخويل رمز التخويل في استجابة التخويل، فلا يمكن استخدامه إلا مرة واحدة لطلب رمز. وعند ورود طلب صحيح ثانٍ برمز تخويل استُخدم بالفعل لإصدار رمز وصول، يجب على خادم التخويل رفض طلب الرمز وإبطال أي رموز صادرة متصلة برمز التخويل. | 1 |
+| **10.4.3** | تحقق من أن رمز التخويل قصير الأجل. ويمكن أن يبلغ العمر الأقصى 10 دقائق لتطبيقات المستويين 1 و2 ودقيقة واحدة لتطبيقات المستوى 3. | 1 |
+| **10.4.4** | تحقق من أن خادم التخويل، لعميل معيّن، لا يسمح إلا باستخدام المنح التي يحتاج هذا العميل إلى استخدامها. ولاحظ أن المنحتين 'token' (المسار الضمني) و'password' (مسار بيانات اعتماد كلمة مرور مالك الموارد) يجب ألا تُستخدما بعد الآن. | 1 |
+| **10.4.5** | تحقق من أن خادم التخويل يخفّف من هجمات إعادة إرسال رموز التحديث للعملاء العامين، ويُفضَّل باستخدام رموز تحديث مقيَّدة بالمُرسِل، أي إثبات الحيازة (DPoP) أو رموز وصول مرتبطة بالشهادات باستخدام TLS المتبادل (mTLS). وبالنسبة إلى تطبيقات المستويين 1 و2، يمكن استخدام تدوير رموز التحديث. وإذا استُخدم تدوير رموز التحديث، فيجب على خادم التخويل إبطال رمز التحديث بعد استخدامه، وإبطال جميع رموز التحديث لذلك التخويل إذا قُدّم رمز تحديث مستخدم ومُبطَل بالفعل. | 1 |
+| **10.4.6** | تحقق من أن خادم التخويل، في حال استخدام منحة الرمز، يخفّف من هجمات اعتراض رمز التخويل باشتراط مفتاح إثبات تبادل الرمز (PKCE). وبالنسبة إلى طلبات التخويل، يجب على خادم التخويل اشتراط قيمة 'code_challenge' صحيحة ويجب ألا يقبل قيمة 'plain' للمعامل 'code_challenge_method'. وبالنسبة إلى طلب الرمز، يجب أن يشترط التحقق من المعامل 'code_verifier'. | 2 |
+| **10.4.7** | تحقق من أن خادم التخويل، إذا كان يدعم التسجيل الديناميكي غير المصادَق عليه للعملاء، يخفّف من خطر تطبيقات العملاء الخبيثة. ويجب أن يتحقق من بيانات العميل الوصفية مثل أي معرّفات مسجّلة، وأن يضمن موافقة المستخدم، وأن يحذّر المستخدم قبل معالجة طلب تخويل بتطبيق عميل غير موثوق. | 2 |
+| **10.4.8** | تحقق من أن لرموز التحديث انتهاء صلاحية مطلقًا، بما في ذلك في حال تطبيق انتهاء صلاحية متزحلق لرموز التحديث. | 2 |
+| **10.4.9** | تحقق من أن رموز التحديث ورموز الوصول المرجعية يمكن إبطالها بواسطة مستخدم مخوَّل عبر واجهة مستخدم خادم التخويل، وذلك للتخفيف من خطر العملاء الخبيثة أو الرموز المسروقة. | 2 |
+| **10.4.10** | تحقق من أن العميل السرّي مُصادَق عليه في طلبات القناة الخلفية من العميل إلى الخادم المخوَّل، مثل طلبات الرموز وطلبات التخويل المدفوعة (PAR) وطلبات إبطال الرموز. | 2 |
+| **10.4.11** | تحقق من أن تكوين خادم التخويل لا يخصّص لعميل OAuth إلا النطاقات المطلوبة. | 2 |
+| **10.4.12** | تحقق من أن خادم التخويل، لعميل معيّن، لا يسمح إلا بقيمة 'response_mode' التي يحتاج هذا العميل إلى استخدامها. وذلك مثلًا بأن يتحقق خادم التخويل من هذه القيمة مقابل القيم المتوقعة أو باستخدام طلب التخويل المدفوع (PAR) أو طلب التخويل المؤمَّن بـ JWT (JAR). | 3 |
+| **10.4.13** | تحقق من أن نوع المنحة 'code' يُستخدم دائمًا مع طلبات التخويل المدفوعة (PAR). | 3 |
+| **10.4.14** | تحقق من أن خادم التخويل لا يُصدر إلا رموز وصول مقيَّدة بالمُرسِل (إثبات الحيازة)، إما رموز وصول مرتبطة بالشهادات باستخدام TLS المتبادل (mTLS) أو رموز وصول مرتبطة بـ DPoP (إثبات الحيازة). | 3 |
+| **10.4.15** | تحقق من أن خادم التخويل، بالنسبة إلى عميل من جانب الخادم (لا يُنفَّذ على جهاز المستخدم النهائي)، يضمن أن قيمة المعامل 'authorization_details' واردة من واجهة العميل الخلفية وأن المستخدم لم يتلاعب بها. وذلك مثلًا باشتراط استخدام طلب التخويل المدفوع (PAR) أو طلب التخويل المؤمَّن بـ JWT (JAR). | 3 |
+| **10.4.16** | تحقق من أن العميل سرّي وأن خادم التخويل يشترط استخدام طرائق مصادقة قوية للعميل (مبنية على تشفير المفتاح العام ومقاومة لهجمات إعادة الإرسال)، مثل TLS المتبادل ('tls_client_auth' و'self_signed_tls_client_auth') أو JWT بالمفتاح الخاص ('private_key_jwt'). | 3 |
+
+## V10.5 عميل OIDC
+
+بما أن الطرف المعوِّل في OIDC يعمل كعميل OAuth، فإن المتطلبات الواردة في قسم "عميل OAuth" تنطبق كذلك.
+
+ولاحظ أن قسم "المصادقة عبر مزوّد هوية" في فصل "المصادقة" يحتوي كذلك على متطلبات عامة ذات صلة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **10.5.1** | تحقق من أن العميل (بوصفه الطرف المعوِّل) يخفّف من هجمات إعادة إرسال رمز الهوية. وذلك مثلًا بالتأكد من أن مطالبة 'nonce' في رمز الهوية تطابق قيمة 'nonce' المُرسلة في طلب المصادقة إلى مزوّد OpenID (المشار إليه في OAuth2 بطلب التخويل المُرسل إلى خادم التخويل). | 2 |
+| **10.5.2** | تحقق من أن العميل يحدّد المستخدم على نحو فريد من مطالبات رمز الهوية، وعادةً مطالبة 'sub'، التي لا يمكن إعادة تخصيصها لمستخدمين آخرين (في نطاق مزوّد هوية واحد). | 2 |
+| **10.5.3** | تحقق من أن العميل يرفض محاولات خادم تخويل خبيث لانتحال هوية خادم تخويل آخر عبر البيانات الوصفية لخادم التخويل. ويجب على العميل رفض البيانات الوصفية لخادم التخويل إذا لم يطابق عنوان URL الخاص بالجهة المُصدِرة في تلك البيانات، مطابقةً دقيقة، عنوان URL المُهيّأ مسبقًا والمتوقع من قِبل العميل. | 2 |
+| **10.5.4** | تحقق من أن العميل يتحقق من أن رمز الهوية مخصّص للاستخدام من قِبل ذلك العميل (الجهة المستهدفة)، وذلك بفحص أن مطالبة 'aud' في الرمز مساوية لقيمة 'client_id' الخاصة بالعميل. | 2 |
+| **10.5.5** | تحقق من أن الطرف المعوِّل، عند استخدام تسجيل الخروج عبر القناة الخلفية في OIDC، يخفّف من حجب الخدمة عن طريق تسجيل الخروج القسري ومن الالتباس بين رموز JWT في مسار تسجيل الخروج. ويجب على العميل التحقق من أن رمز تسجيل الخروج مُصنَّف على نحو صحيح بالقيمة 'logout+jwt'، وأنه يحتوي على مطالبة 'event' باسم العضو الصحيح، وأنه لا يحتوي على مطالبة 'nonce'. ولاحظ أنه يُوصى كذلك بأن يكون له انتهاء صلاحية قصير (مثلًا دقيقتان). | 2 |
+
+## V10.6 مزوّد OpenID
+
+بما أن مزوّدي OpenID يعملون كخوادم تخويل OAuth، فإن المتطلبات الواردة في قسم "خادم تخويل OAuth" تنطبق كذلك.
+
+ولاحظ أنه في حال استخدام مسار رمز الهوية (وليس مسار الرمز)، لا تُصدر رموز وصول، وكثير من متطلبات خادم تخويل OAuth تكون غير منطبقة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **10.6.1** | تحقق من أن مزوّد OpenID لا يسمح إلا بالقيم 'code' أو 'ciba' أو 'id_token' أو 'id_token code' لنمط الاستجابة. ولاحظ أن 'code' مفضّلة على 'id_token code' (المسار الهجين في OIDC)، وأن 'token' (أي مسار ضمني) يجب ألا تُستخدم. | 2 |
+| **10.6.2** | تحقق من أن مزوّد OpenID يخفّف من حجب الخدمة عن طريق تسجيل الخروج القسري. وذلك بالحصول على تأكيد صريح من المستخدم النهائي أو، إن وُجدت، بالتحقق من المعاملات في طلب تسجيل الخروج (الذي يستهلّه الطرف المعوِّل)، مثل 'id_token_hint'. | 2 |
+
+## V10.7 إدارة الموافقة
+
+تتناول هذه المتطلبات التحقق من موافقة المستخدم بواسطة خادم التخويل. فمن دون تحقق سليم من موافقة المستخدم، قد يحصل فاعل خبيث على صلاحيات بالنيابة عن المستخدم عن طريق الانتحال أو الهندسة الاجتماعية.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **10.7.1** | تحقق من أن خادم التخويل يضمن موافقة المستخدم على كل طلب تخويل. وإذا لم يكن من الممكن ضمان هوية العميل، فيجب على خادم التخويل أن يطلب موافقة المستخدم صراحةً دائمًا. | 2 |
+| **10.7.2** | تحقق من أن خادم التخويل، عند طلبه موافقة المستخدم، يعرض معلومات كافية وواضحة عمّا تجري الموافقة عليه. وينبغي أن يشمل ذلك، حيث ينطبق، طبيعة التخويلات المطلوبة (عادةً بناءً على النطاق وخادم الموارد وتفاصيل التخويل في طلبات التخويل الغنية (RAR))، وهوية التطبيق المخوَّل، وعمر هذه التخويلات. | 2 |
+| **10.7.3** | تحقق من أن المستخدم يمكنه مراجعة الموافقات التي منحها عبر خادم التخويل وتعديلها وإبطالها. | 2 |
+
+## المراجع
+
+لمزيد من المعلومات عن OAuth، يُرجى الاطلاع على:
+
+* [oauth.net](https://oauth.net/)
+* [OWASP OAuth 2.0 Protocol Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html)
+
+وبالنسبة إلى المتطلبات المتعلقة بـ OAuth في معيار التحقق من أمان التطبيقات، تُستخدم وثائق RFC المنشورة والتي في حالة مسوّدة التالية:
+
+* [RFC6749 The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749)
+* [RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750)
+* [RFC6819 OAuth 2.0 Threat Model and Security Considerations](https://datatracker.ietf.org/doc/html/rfc6819)
+* [RFC7636 Proof Key for Code Exchange by OAuth Public Clients](https://datatracker.ietf.org/doc/html/rfc7636)
+* [RFC7591 OAuth 2.0 Dynamic Client Registration Protocol](https://datatracker.ietf.org/doc/html/rfc7591)
+* [RFC8628 OAuth 2.0 Device Authorization Grant](https://datatracker.ietf.org/doc/html/rfc8628)
+* [RFC8707 Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707)
+* [RFC9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://datatracker.ietf.org/doc/html/rfc9068)
+* [RFC9126 OAuth 2.0 Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126)
+* [RFC9207 OAuth 2.0 Authorization Server Issuer Identification](https://datatracker.ietf.org/doc/html/rfc9207)
+* [RFC9396 OAuth 2.0 Rich Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9396)
+* [RFC9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449)
+* [RFC9700 Best Current Practice for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700)
+* [draft OAuth 2.0 for Browser-Based Applications](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps)<!-- recheck on release -->
+* [draft The OAuth 2.1 Authorization Framework](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12)<!-- recheck on release -->
+
+ولمزيد من المعلومات عن OpenID Connect، يُرجى الاطلاع على:
+
+* [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)
+* [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html)
diff --git a/5.0/ar/0x20-V11-Cryptography.md b/5.0/ar/0x20-V11-Cryptography.md
new file mode 100644
index 0000000000..c3ef1374bc
--- /dev/null
+++ b/5.0/ar/0x20-V11-Cryptography.md
@@ -0,0 +1,107 @@
+# V11 التشفير
+
+## الهدف من ضوابط الأمان
+
+الهدف من هذا الفصل تحديد الممارسات الفضلى للاستخدام العام للتشفير، وكذلك إرساء فهم أساسي لمبادئ التشفير والتحفيز على التحوّل إلى مناهج أكثر صمودًا وحداثة. وهو يشجّع على ما يلي:
+
+* تنفيذ أنظمة تشفير متينة تفشل بأمان وتتكيّف مع التهديدات المتطوّرة وتصمد للمستقبل.
+* الاستفادة من آليات تشفير آمنة ومتوافقة مع الممارسات الفضلى في الصناعة.
+* الحفاظ على نظام آمن لإدارة مفاتيح التشفير مع ضوابط وصول وتدقيق ملائمة.
+* التقييم المنتظم لمشهد التشفير لتقدير المخاطر الجديدة وتكييف الخوارزميات وفقًا لذلك.
+* استكشاف حالات استخدام التشفير وإدارتها على امتداد دورة حياة التطبيق للتأكد من أن جميع الأصول التشفيرية محسوبة ومؤمَّنة.
+
+وإضافةً إلى بيان المبادئ العامة والممارسات الفضلى، يوفّر هذا المستند كذلك معلومات تقنية أكثر تعمّقًا عن المتطلبات في الملحق ج - معايير التشفير. ويشمل ذلك الخوارزميات والأنماط التي تُعدّ "معتمدة" لأغراض المتطلبات الواردة في هذا الفصل.
+
+أما المتطلبات التي تستخدم التشفير لحل مشكلة منفصلة، مثل إدارة الأسرار أو أمان الاتصالات، فستكون في أجزاء أخرى من المعيار.
+
+## V11.1 جرد التشفير وتوثيقه
+
+يلزم تصميم التطبيقات بمعمارية تشفير قوية لحماية أصول البيانات وفق تصنيفها. فتشفير كل شيء مضيعة، وعدم تشفير أي شيء إهمال من الناحية القانونية. ويجب إيجاد توازن، عادةً أثناء التصميم المعماري أو الرفيع المستوى أو دورات التصميم أو الاستقصاءات المعمارية. وتصميم التشفير "على عجل" أو إضافته لاحقًا سيكلّف حتمًا أكثر بكثير لتنفيذه بأمان من مجرّد بنائه من البداية.
+
+ومن المهم التأكد من استكشاف جميع الأصول التشفيرية وجردها وتقييمها بانتظام. يُرجى الاطلاع على الملحق لمزيد من المعلومات عن كيفية تحقيق ذلك.
+
+والحاجة إلى تحصين أنظمة التشفير للمستقبل ضد الصعود المرتقب للحوسبة الكمومية بالغة الأهمية كذلك. ويشير التشفير ما بعد الكمومي (PQC) إلى خوارزميات تشفير مصمّمة لتبقى آمنة أمام هجمات الحواسيب الكمومية، التي يُتوقع أن تكسر خوارزميات واسعة الاستخدام مثل RSA وتشفير المنحنيات الإهليلجية (ECC).
+
+يُرجى الاطلاع على الملحق للإرشادات الراهنة عن أوليات ومعايير PQC المدروسة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **11.1.1** | تحقق من وجود سياسة موثّقة لإدارة مفاتيح التشفير ودورة حياة لمفاتيح التشفير تتّبع معيارًا لإدارة المفاتيح مثل NIST SP 800-57. وينبغي أن يشمل ذلك التأكد من عدم الإفراط في مشاركة المفاتيح (مثلًا مع أكثر من كيانين للأسرار المشتركة وأكثر من كيان واحد للمفاتيح الخاصة). | 2 |
+| **11.1.2** | تحقق من أن جرد التشفير يُنفَّذ ويُصان ويُحدَّث بانتظام ويشمل جميع مفاتيح التشفير والخوارزميات والشهادات التي يستخدمها التطبيق. ويجب أن يوثّق كذلك المواضع التي يمكن وتلك التي لا يمكن استخدام المفاتيح فيها في النظام، وأنواع البيانات التي يمكن وتلك التي لا يمكن حمايتها باستخدام هذه المفاتيح. | 2 |
+| **11.1.3** | تحقق من استخدام آليات استكشاف التشفير لتحديد جميع مواضع التشفير في النظام، بما فيها عمليات التشفير والتلبيد والتوقيع. | 3 |
+| **11.1.4** | تحقق من الاحتفاظ بجرد للتشفير. ويجب أن يشمل ذلك خطة موثّقة تبيّن مسار الانتقال إلى معايير تشفير جديدة، مثل التشفير ما بعد الكمومي، وذلك للتفاعل مع التهديدات المستقبلية. | 3 |
+
+## V11.2 التنفيذ الآمن للتشفير
+
+يحدّد هذا القسم متطلبات اختيار خوارزميات التشفير الأساسية للتطبيق وتنفيذها وإدارتها المستمرة. والهدف التأكد من عدم نشر إلا أوليات تشفيرية متينة ومقبولة في الصناعة، بما يتوافق مع المعايير الراهنة (مثل NIST وISO/IEC) والممارسات الفضلى. ويجب على المؤسسات التأكد من اختيار كل مكوّن تشفيري بناءً على أدلة خضعت لمراجعة الأنداد واختبار أمني عملي.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **11.2.1** | تحقق من استخدام تنفيذات مُصادَق عليها في الصناعة (بما فيها المكتبات والتنفيذات المعزّزة بالعتاد) للعمليات التشفيرية. | 2 |
+| **11.2.2** | تحقق من أن التطبيق مصمّم بمرونة تشفيرية بحيث يمكن إعادة تهيئة أو ترقية أو استبدال خوارزميات الأعداد العشوائية أو التشفير المصادَق عليه أو MAC أو التلبيد، وأطوال المفاتيح والدورات ومجموعات التشفير والأنماط، في أي وقت، وذلك للحماية من الانكسارات التشفيرية. وبالمثل، يجب أن يكون من الممكن استبدال المفاتيح وكلمات المرور وإعادة تشفير البيانات. وهذا سيتيح ترقيات سلسة إلى التشفير ما بعد الكمومي (PQC)، بمجرّد توافر تنفيذات عالية التوكيد لمخططات أو معايير PQC المعتمدة على نطاق واسع. | 2 |
+| **11.2.3** | تحقق من أن جميع الأوليات التشفيرية تستخدم 128 بتًا على الأقل من الأمان بناءً على الخوارزمية وحجم المفتاح والتكوين. على سبيل المثال، يوفّر مفتاح ECC بطول 256 بتًا نحو 128 بتًا من الأمان، في حين يتطلّب RSA مفتاحًا بطول 3072 بتًا لتحقيق 128 بتًا من الأمان. | 2 |
+| **11.2.4** | تحقق من أن جميع العمليات التشفيرية ثابتة الزمن، دون عمليات "قصر الدائرة" في المقارنات أو الحسابات أو القيم المُعادة، وذلك لتجنّب تسريب المعلومات. | 3 |
+| **11.2.5** | تحقق من أن جميع وحدات التشفير تفشل بأمان، ومن أن الأخطاء تُعالَج بطريقة لا تُمكّن الثغرات، مثل هجمات كاهن الحشو. | 3 |
+
+## V11.3 خوارزميات التشفير
+
+تشكّل خوارزميات التشفير المصادَق عليها المبنية على AES وCHACHA20 العمود الفقري للممارسة التشفيرية الحديثة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **11.3.1** | تحقق من عدم استخدام أنماط الكتل غير الآمنة (مثل ECB) ومخططات الحشو الضعيفة (مثل PKCS#1 v1.5). | 1 |
+| **11.3.2** | تحقق من عدم استخدام إلا مجموعات التشفير والأنماط المعتمدة مثل AES مع GCM. | 1 |
+| **11.3.3** | تحقق من أن البيانات المشفّرة محمية من التعديل غير المصرَّح به، ويُفضَّل باستخدام طريقة تشفير مصادَق عليها معتمدة أو بالجمع بين طريقة تشفير معتمدة وخوارزمية MAC معتمدة. | 2 |
+| **11.3.4** | تحقق من أن القيم العشوائية لمرة واحدة ومتجهات التهيئة وغيرها من الأعداد ذات الاستخدام الواحد لا تُستخدم لأكثر من زوج واحد من مفتاح التشفير وعنصر البيانات. ويجب أن تكون طريقة التوليد ملائمة للخوارزمية المستخدمة. | 3 |
+| **11.3.5** | تحقق من أن أي تركيبة من خوارزمية تشفير وخوارزمية MAC تعمل بنمط التشفير ثم MAC. | 3 |
+
+## V11.4 التلبيد والدوالّ المبنية على التلبيد
+
+تُستخدم التلبيدات التشفيرية في مجموعة واسعة من بروتوكولات التشفير، مثل التوقيعات الرقمية وHMAC ودوالّ اشتقاق المفاتيح (KDF) وتوليد البتات العشوائية وتخزين كلمات المرور. وأمان النظام التشفيري لا يفوق قوة دوالّ التلبيد الأساسية المستخدمة. ويبيّن هذا القسم متطلبات استخدام دوالّ تلبيد آمنة في العمليات التشفيرية.
+
+وبالنسبة إلى تخزين كلمات المرور، وكذلك ملحق التشفير، ستوفّر [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#password-hashing-algorithms) سياقًا وإرشادات مفيدة كذلك.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **11.4.1** | تحقق من عدم استخدام إلا دوالّ التلبيد المعتمدة لحالات الاستخدام التشفيري العامة، بما فيها التوقيعات الرقمية وHMAC وKDF وتوليد البتات العشوائية. ويجب ألا تُستخدم دوالّ التلبيد الممنوعة، مثل MD5، لأي غرض تشفيري. | 1 |
+| **11.4.2** | تحقق من أن كلمات المرور تُخزَّن باستخدام دالة اشتقاق مفاتيح معتمدة ومكثّفة حسابيًا (تُعرف كذلك بـ"دالة تلبيد كلمات المرور")، مع ضبط المعاملات بناءً على الإرشادات الراهنة. وينبغي أن توازن الإعدادات بين الأمان والأداء لجعل هجمات القوة الغاشمة صعبة بما يكفي لمستوى الأمان المطلوب. | 2 |
+| **11.4.3** | تحقق من أن دوالّ التلبيد المستخدمة في التوقيعات الرقمية، كجزء من مصادقة البيانات أو سلامتها، مقاومة للتصادم وذات أطوال بتات ملائمة. وإذا كانت مقاومة التصادم مطلوبة، فيجب أن يكون طول المخرَج 256 بتًا على الأقل. وإذا كانت المقاومة لهجمات الصورة الأولية الثانية فقط مطلوبة، فيجب أن يكون طول المخرَج 128 بتًا على الأقل. | 2 |
+| **11.4.4** | تحقق من أن التطبيق يستخدم دوالّ اشتقاق مفاتيح معتمدة مع معاملات لتمديد المفاتيح عند اشتقاق مفاتيح سرّية من كلمات المرور. ويجب أن توازن المعاملات المستخدمة بين الأمان والأداء لمنع هجمات القوة الغاشمة من اختراق المفتاح التشفيري الناتج. | 2 |
+
+## V11.5 القيم العشوائية
+
+إن توليد الأعداد شبه العشوائية الآمن تشفيريًا (CSPRNG) بالغ الصعوبة في إتقانه. وعمومًا، ستُستنفد مصادر العشوائية الجيدة في نظام ما سريعًا إذا أُفرط في استخدامها، لكن المصادر الأقل عشوائية قد تؤدي إلى مفاتيح وأسرار قابلة للتوقع.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **11.5.1** | تحقق من أن جميع الأعداد والسلاسل العشوائية المقصود أن تكون غير قابلة للتخمين يجب أن تُولَّد باستخدام مولّد أعداد شبه عشوائية آمن تشفيريًا (CSPRNG) وأن تمتلك 128 بتًا على الأقل من العشوائية. ولاحظ أن المعرّفات الفريدة عالميًا (UUIDs) لا تحقّق هذا الشرط. | 2 |
+| **11.5.2** | تحقق من أن آلية توليد الأعداد العشوائية المستخدمة مصمّمة للعمل بأمان، حتى تحت الطلب الكثيف. | 3 |
+
+## V11.6 تشفير المفتاح العام
+
+سيُستخدم تشفير المفتاح العام حيث لا يكون من الممكن أو من المرغوب مشاركة مفتاح سرّي بين أطراف متعددة.
+
+وكجزء من ذلك، توجد حاجة إلى آليات معتمدة لتبادل المفاتيح، مثل ديفي-هيلمان وديفي-هيلمان بالمنحنيات الإهليلجية (ECDH)، لضمان بقاء النظام التشفيري آمنًا أمام التهديدات الحديثة. ويوفّر فصل "الاتصال الآمن" متطلبات TLS، ولذلك فإن المتطلبات في هذا القسم موجّهة إلى الحالات التي يُستخدم فيها تشفير المفتاح العام في حالات استخدام غير TLS.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **11.6.1** | تحقق من عدم استخدام إلا خوارزميات التشفير وأنماط التشغيل المعتمدة لتوليد المفاتيح وبذرها، ولتوليد التوقيعات الرقمية والتحقق منها. ويجب ألا تولّد خوارزميات توليد المفاتيح مفاتيح غير آمنة معرّضة لهجمات معروفة، مثل مفاتيح RSA المعرّضة لتحليل فيرما إلى عوامل. | 2 |
+| **11.6.2** | تحقق من استخدام خوارزميات تشفير معتمدة لتبادل المفاتيح (مثل ديفي-هيلمان) مع التركيز على التأكد من أن آليات تبادل المفاتيح تستخدم معاملات آمنة. وهذا سيمنع الهجمات على عملية إرساء المفاتيح التي قد تؤدي إلى هجمات الخصم في المنتصف أو إلى انكسارات تشفيرية. | 3 |
+
+## V11.7 تشفير البيانات قيد الاستخدام
+
+إن حماية البيانات أثناء معالجتها أمر بالغ الأهمية. ويُوصى بتقنيات مثل التشفير الكامل للذاكرة وتشفير البيانات أثناء النقل والتأكد من تشفير البيانات في أسرع وقت ممكن بعد الاستخدام.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **11.7.1** | تحقق من استخدام التشفير الكامل للذاكرة الذي يحمي البيانات الحساسة أثناء استخدامها، بما يمنع وصول المستخدمين أو العمليات غير المصرَّح لهم. | 3 |
+| **11.7.2** | تحقق من أن تدنية البيانات تضمن كشف أقل قدر من البيانات أثناء المعالجة، وتأكّد من تشفير البيانات فور استخدامها أو في أقرب وقت ممكن. | 3 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP Web Security Testing Guide: Testing for Weak Cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography)
+* [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)
+* [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final)
+* [NIST SP 800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final)
diff --git a/5.0/ar/0x21-V12-Secure-Communication.md b/5.0/ar/0x21-V12-Secure-Communication.md
new file mode 100644
index 0000000000..23d9cb81c6
--- /dev/null
+++ b/5.0/ar/0x21-V12-Secure-Communication.md
@@ -0,0 +1,57 @@
+# V12 الاتصال الآمن
+
+## الهدف من ضوابط الأمان
+
+يشتمل هذا الفصل على متطلبات متعلقة بالآليات المحدّدة التي ينبغي أن تتوافر لحماية البيانات أثناء النقل، سواء بين عميل المستخدم النهائي وخدمة في الواجهة الخلفية، أو بين الخدمات الداخلية وخدمات الواجهة الخلفية.
+
+وتشمل المفاهيم العامة التي يعزّزها هذا الفصل ما يلي:
+
+* التأكد من أن الاتصالات مشفّرة خارجيًا، ومن الأفضل داخليًا أيضًا.
+* تكوين آليات التشفير باستخدام أحدث الإرشادات، بما في ذلك الخوارزميات ومجموعات التشفير المفضّلة.
+* التأكد من أن الاتصالات لا تُعترض من قِبل أطراف غير مصرَّح لها، وذلك باستخدام شهادات موقّعة.
+
+وإضافةً إلى بيان المبادئ العامة والممارسات الفضلى، يوفّر معيار التحقق من أمان التطبيقات كذلك معلومات تقنية أكثر تعمّقًا عن القوة التشفيرية في الملحق ج - معايير التشفير.
+
+## V12.1 إرشادات عامة لأمان TLS
+
+يوفّر هذا القسم إرشادات أولية عن كيفية تأمين اتصالات TLS. وينبغي استخدام أدوات محدّثة لمراجعة تكوين TLS على نحو مستمر.
+
+ومع أن استخدام شهادات TLS بأحرف البدل ليس غير آمن في جوهره، فإن اختراق شهادة منشورة في جميع البيئات المملوكة (مثل الإنتاج والتهيئة والتطوير والاختبار) قد يؤدي إلى اختراق الوضع الأمني للتطبيقات التي تستخدمها. وينبغي، إن أمكن، توفير حماية وإدارة سليمتين واستخدام شهادات TLS منفصلة في البيئات المختلفة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **12.1.1** | تحقق من أن الإصدارات الأحدث الموصى بها من بروتوكول TLS هي وحدها المُمكَّنة، مثل TLS 1.2 وTLS 1.3. ويجب أن يكون أحدث إصدار من بروتوكول TLS هو الخيار المفضّل. | 1 |
+| **12.1.2** | تحقق من أن مجموعات التشفير الموصى بها هي وحدها المُمكَّنة، مع تعيين أقوى مجموعات التشفير كمفضّلة. ويجب ألا تدعم تطبيقات المستوى 3 سوى مجموعات التشفير التي توفّر السرّية التامة للتوجيه. | 2 |
+| **12.1.3** | تحقق من أن التطبيق يتحقق من أن شهادات عميل mTLS موثوقة قبل استخدام هوية الشهادة للمصادقة أو التخويل. | 2 |
+| **12.1.4** | تحقق من أن إبطال الشهادات على النحو السليم، مثل تدبيس بروتوكول حالة الشهادة عبر الإنترنت (OCSP Stapling)، مُمكَّن ومُهيّأ. | 3 |
+| **12.1.5** | تحقق من أن ميزة Encrypted Client Hello (ECH) مُمكَّنة في إعدادات TLS للتطبيق لمنع كشف البيانات الوصفية الحساسة، مثل إشارة اسم الخادم (SNI)، أثناء عمليات مصافحة TLS. | 3 |
+
+## V12.2 اتصالات HTTPS مع الخدمات الموجّهة إلى الخارج
+
+تأكّد من أن جميع حِزَم HTTP المتجهة إلى الخدمات الموجّهة إلى الخارج التي يعرضها التطبيق تُرسل مشفّرة، بشهادات موثوقة عمومًا.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **12.2.1** | تحقق من استخدام TLS في جميع الاتصالات بين العميل والخدمات الموجّهة إلى الخارج القائمة على HTTP، ومن أنه لا يرتد إلى اتصالات غير آمنة أو غير مشفّرة. | 1 |
+| **12.2.2** | تحقق من أن الخدمات الموجّهة إلى الخارج تستخدم شهادات TLS موثوقة عمومًا. | 1 |
+
+## V12.3 الأمان العام للاتصال بين الخدمات
+
+تتضمّن اتصالات الخادم (الداخلية والخارجية على حد سواء) أكثر من مجرّد HTTP. ويجب أن تكون الاتصالات من الأنظمة الأخرى وإليها آمنة كذلك، ومن الأفضل باستخدام TLS.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **12.3.1** | تحقق من استخدام بروتوكول مشفّر مثل TLS في جميع الاتصالات الواردة والصادرة من التطبيق وإليه، بما في ذلك أنظمة المراقبة وأدوات الإدارة والوصول عن بُعد وSSH والبرمجيات الوسيطة وقواعد البيانات والحواسيب المركزية وأنظمة الشركاء أو واجهات برمجة التطبيقات الخارجية. ويجب ألا يرتد الخادم إلى بروتوكولات غير آمنة أو غير مشفّرة. | 2 |
+| **12.3.2** | تحقق من أن عملاء TLS يتحققون من الشهادات المستلمة قبل التواصل مع خادم TLS. | 2 |
+| **12.3.3** | تحقق من استخدام TLS أو آلية تشفير نقل مناسبة أخرى في جميع الاتصالات بين الخدمات الداخلية القائمة على HTTP داخل التطبيق، ومن أنه لا يرتد إلى اتصالات غير آمنة أو غير مشفّرة. | 2 |
+| **12.3.4** | تحقق من أن اتصالات TLS بين الخدمات الداخلية تستخدم شهادات موثوقة. وحيث تُستخدم شهادات مُولَّدة داخليًا أو موقّعة ذاتيًا، يجب تهيئة الخدمة المستهلكة لتثق فقط بسلطات إصدار شهادات داخلية محدّدة وبشهادات موقّعة ذاتيًا محدّدة. | 2 |
+| **12.3.5** | تحقق من أن الخدمات التي تتواصل داخليًا في نظام ما (الاتصالات بين الخدمات) تستخدم مصادقة قوية للتأكد من التحقق من كل نقطة نهاية. ويجب استخدام طرائق مصادقة قوية، مثل مصادقة العميل في TLS، لضمان الهوية، باستخدام البنية التحتية للمفتاح العام وآليات مقاومة لهجمات إعادة الإرسال. وبالنسبة إلى معماريات الخدمات المصغّرة، ينبغي النظر في استخدام شبكة خدمات لتبسيط إدارة الشهادات وتعزيز الأمان. | 3 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP - Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)
+* [Mozilla's Server Side TLS configuration guide](https://wiki.mozilla.org/Security/Server_Side_TLS)
+* [Mozilla's tool to generate known good TLS configurations](https://ssl-config.mozilla.org/).
+* [O-Saft - OWASP Project to validate TLS configuration](https://owasp.org/www-project-o-saft/)
diff --git a/5.0/ar/0x22-V13-Configuration.md b/5.0/ar/0x22-V13-Configuration.md
new file mode 100644
index 0000000000..b00f1ecde9
--- /dev/null
+++ b/5.0/ar/0x22-V13-Configuration.md
@@ -0,0 +1,68 @@
+# V13 التكوين
+
+## الهدف من ضوابط الأمان
+
+يجب أن يكون التكوين الافتراضي للتطبيق آمنًا للاستخدام على الإنترنت.
+
+ويوفّر هذا الفصل إرشادات عن التكوينات المتنوعة اللازمة لتحقيق ذلك، بما فيها التكوينات المطبَّقة أثناء التطوير والبناء والنشر.
+
+وتشمل المواضيع المتناولة منع تسريب البيانات، وإدارة الاتصال بين المكوّنات بأمان، وحماية الأسرار.
+
+## V13.1 توثيق التكوين
+
+يبيّن هذا القسم متطلبات التوثيق الخاصة بكيفية اتصال التطبيق بالخدمات الداخلية والخارجية، وكذلك التقنيات اللازمة لمنع فقدان التوافر بسبب تعذّر الوصول إلى الخدمات. ويتناول كذلك التوثيق المتعلق بالأسرار.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **13.1.1** | تحقق من أن جميع احتياجات الاتصال الخاصة بالتطبيق موثّقة. ويجب أن يشمل ذلك الخدمات الخارجية التي يعتمد عليها التطبيق والحالات التي قد يتمكّن فيها المستخدم النهائي من تقديم موقع خارجي يتصل به التطبيق بعد ذلك. | 2 |
+| **13.1.2** | تحقق من أن الوثائق تحدّد، لكل خدمة يستخدمها التطبيق، العدد الأقصى للاتصالات المتزامنة (مثل حدود مجمّع الاتصالات) وكيفية تصرّف التطبيق عند بلوغ ذلك الحد، بما في ذلك أي آليات احتياطية أو للاستعادة، وذلك لمنع حالات حجب الخدمة. | 3 |
+| **13.1.3** | تحقق من أن وثائق التطبيق تحدّد استراتيجيات إدارة الموارد لكل نظام أو خدمة خارجية يستخدمها (مثل قواعد البيانات ومقابض الملفات والخيوط واتصالات HTTP). وينبغي أن يشمل ذلك إجراءات تحرير الموارد وإعدادات المهل ومعالجة الأعطال، وحيث يُنفَّذ منطق إعادة المحاولة، تحديد حدود إعادة المحاولة والتأخيرات وخوارزميات التراجع. وبالنسبة إلى عمليات طلب واستجابة HTTP المتزامنة، ينبغي أن تُلزم بمهل قصيرة وأن تعطّل إعادة المحاولة أو تقيّدها بصرامة لمنع التأخيرات المتتالية واستنفاد الموارد. | 3 |
+| **13.1.4** | تحقق من أن وثائق التطبيق تحدّد الأسرار الحرجة لأمان التطبيق وجدولًا لتدويرها، بناءً على نموذج التهديد الخاص بالمؤسسة ومتطلبات العمل. | 3 |
+
+## V13.2 تكوين اتصالات الواجهة الخلفية
+
+تتفاعل التطبيقات مع خدمات متعددة، منها واجهات برمجة التطبيقات وقواعد البيانات أو مكوّنات أخرى. وقد تُعدّ هذه داخلية بالنسبة إلى التطبيق لكنها غير مشمولة في آليات التحكم في الوصول القياسية للتطبيق، أو قد تكون خارجية تمامًا. وفي كلتا الحالتين، من الضروري تهيئة التطبيق للتفاعل مع هذه المكوّنات بأمان، وحماية ذلك التكوين إذا لزم الأمر.
+
+ملاحظة: يوفّر فصل "الاتصال الآمن" إرشادات عن التشفير أثناء النقل.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **13.2.1** | تحقق من أن الاتصالات بين مكوّنات التطبيق في الواجهة الخلفية التي لا تدعم آلية جلسة المستخدم القياسية للتطبيق، بما فيها واجهات برمجة التطبيقات والبرمجيات الوسيطة وطبقات البيانات، مُصادَق عليها. ويجب أن تستخدم المصادقة حسابات خدمة فردية أو رموزًا قصيرة الأجل أو مصادقة قائمة على الشهادات، وليس بيانات اعتماد ثابتة مثل كلمات المرور أو مفاتيح واجهات برمجة التطبيقات أو الحسابات المشتركة ذات الوصول المتميّز. | 2 |
+| **13.2.2** | تحقق من أن الاتصالات بين مكوّنات التطبيق في الواجهة الخلفية، بما فيها الخدمات المحلية أو خدمات نظام التشغيل وواجهات برمجة التطبيقات والبرمجيات الوسيطة وطبقات البيانات، تُنفَّذ بحسابات مُنحت أقل الصلاحيات اللازمة. | 2 |
+| **13.2.3** | تحقق من أنه، إذا كان لا بد من استخدام بيانات اعتماد لمصادقة الخدمة، فإن بيانات الاعتماد التي يستخدمها المستهلك ليست بيانات اعتماد افتراضية (مثل root/root أو admin/admin). | 2 |
+| **13.2.4** | تحقق من استخدام قائمة سماح لتحديد الموارد أو الأنظمة الخارجية التي يُسمح للتطبيق بالاتصال بها (مثلًا للطلبات الصادرة أو تحميل البيانات أو الوصول إلى الملفات). ويمكن تنفيذ قائمة السماح هذه في طبقة التطبيق أو خادم الويب أو الجدار الناري أو في مجموعة من الطبقات المختلفة. | 2 |
+| **13.2.5** | تحقق من أن خادم الويب أو التطبيق مُهيّأ بقائمة سماح بالموارد أو الأنظمة التي يمكن للخادم إرسال طلبات إليها أو تحميل بيانات أو ملفات منها. | 2 |
+| **13.2.6** | تحقق من أن التطبيق، حيث يتصل بخدمات منفصلة، يتّبع التكوين الموثّق لكل اتصال، مثل العدد الأقصى للاتصالات المتوازية والتصرّف عند بلوغ العدد الأقصى المسموح به من الاتصالات ومهل الاتصال واستراتيجيات إعادة المحاولة. | 3 |
+
+## V13.3 إدارة الأسرار
+
+إن إدارة الأسرار مهمة تكوين أساسية لضمان حماية البيانات المستخدمة في التطبيق. وتوجد المتطلبات الخاصة بالتشفير في فصل "التشفير"، لكن هذا القسم يركّز على جوانب إدارة الأسرار والتعامل معها.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **13.3.1** | تحقق من استخدام حل لإدارة الأسرار، مثل خزنة مفاتيح، لإنشاء أسرار الواجهة الخلفية وتخزينها والتحكم في الوصول إليها وتدميرها بأمان. وقد تشمل هذه كلمات المرور ومادة المفاتيح والتكاملات مع قواعد البيانات وأنظمة الأطراف الثالثة والمفاتيح والبذور الخاصة بالرموز المعتمدة على الوقت وغيرها من الأسرار الداخلية ومفاتيح واجهات برمجة التطبيقات. ويجب ألا تُدرج الأسرار في الشيفرة المصدرية للتطبيق أو في مخرجات البناء. وبالنسبة إلى تطبيق من المستوى 3، يجب أن يتضمّن ذلك حلًّا مدعومًا بالعتاد مثل وحدة أمان العتاد (HSM). | 2 |
+| **13.3.2** | تحقق من أن الوصول إلى أصول الأسرار يتقيّد بمبدأ الحد الأدنى من الصلاحيات. | 2 |
+| **13.3.3** | تحقق من أن جميع العمليات التشفيرية تُنفَّذ باستخدام وحدة أمان معزولة (مثل خزنة أو وحدة أمان عتادية) لإدارة مادة المفاتيح وحمايتها بأمان من التعرّض خارج وحدة الأمان. | 3 |
+| **13.3.4** | تحقق من أن الأسرار مُهيّأة لانتهاء الصلاحية والتدوير بناءً على وثائق التطبيق. | 3 |
+
+## V13.4 تسريب المعلومات غير المقصود
+
+ينبغي تحصين تكوينات الإنتاج لتجنّب كشف بيانات غير ضرورية. وكثير من هذه المشكلات يُصنَّف نادرًا كمخاطر جسيمة، لكنها تُسلسَل غالبًا مع ثغرات أخرى. وإذا لم تكن هذه المشكلات موجودة افتراضيًا، فإن ذلك يرفع مستوى الصعوبة أمام مهاجمة التطبيق.
+
+على سبيل المثال، إخفاء إصدار مكوّنات جانب الخادم لا يلغي الحاجة إلى ترقيع جميع المكوّنات، وتعطيل سرد المجلدات لا يزيل الحاجة إلى استخدام ضوابط التخويل أو إبعاد الملفات عن المجلد العام، لكنه يرفع مستوى الصعوبة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **13.4.1** | تحقق من أن التطبيق يُنشر إما دون أي بيانات وصفية لإدارة الإصدارات، بما فيها مجلدا .git أو .svn، أو بطريقة تجعل هذين المجلدين غير قابلين للوصول خارجيًا ومن التطبيق نفسه. | 1 |
+| **13.4.2** | تحقق من تعطيل أوضاع التنقيح لجميع المكوّنات في بيئات الإنتاج لمنع كشف ميزات التنقيح وتسريب المعلومات. | 2 |
+| **13.4.3** | تحقق من أن خوادم الويب لا تكشف سرد الأدلة للعملاء إلا إذا كان ذلك مقصودًا صراحةً. | 2 |
+| **13.4.4** | تحقق من أن استخدام طريقة HTTP TRACE غير مدعوم في بيئات الإنتاج، لتجنّب احتمال تسريب المعلومات. | 2 |
+| **13.4.5** | تحقق من أن الوثائق (مثل وثائق واجهات برمجة التطبيقات الداخلية) ونقاط نهاية المراقبة غير مكشوفة إلا إذا كان ذلك مقصودًا صراحةً. | 2 |
+| **13.4.6** | تحقق من أن التطبيق لا يكشف معلومات إصدار مفصّلة عن مكوّنات الواجهة الخلفية. | 3 |
+| **13.4.7** | تحقق من أن طبقة الويب مُهيّأة لتقديم الملفات ذات امتدادات محدّدة فقط، وذلك لمنع التسريب غير المقصود للمعلومات والتكوين والشيفرة المصدرية. | 3 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP Web Security Testing Guide: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing)
diff --git a/5.0/ar/0x23-V14-Data-Protection.md b/5.0/ar/0x23-V14-Data-Protection.md
new file mode 100644
index 0000000000..bd90b32a65
--- /dev/null
+++ b/5.0/ar/0x23-V14-Data-Protection.md
@@ -0,0 +1,60 @@
+# V14 حماية البيانات
+
+## الهدف من ضوابط الأمان
+
+لا يمكن للتطبيقات أن تحسب لجميع أنماط الاستخدام وسلوكيات المستخدمين، ولذلك ينبغي لها تنفيذ ضوابط للحد من الوصول غير المصرَّح به إلى البيانات الحساسة على أجهزة العملاء.
+
+ويشتمل هذا الفصل على متطلبات متعلقة بتحديد البيانات التي تحتاج إلى حماية، وكيفية حمايتها، والآليات المحدّدة التي ينبغي تنفيذها أو المزالق التي ينبغي تجنّبها.
+
+ومن الاعتبارات الأخرى لحماية البيانات الاستخراج بالجملة أو التعديل أو الاستخدام المفرط. ومن المرجّح أن تكون متطلبات كل نظام مختلفة جدًا، ولذلك يجب أن يراعي تحديد ما هو "غير طبيعي" نموذج التهديد ومخاطر العمل. ومن منظور معيار التحقق من أمان التطبيقات، يُعالَج كشف هذه المشكلات في فصل "تسجيل الأحداث الأمنية ومعالجة الأخطاء"، ويُعالَج وضع الحدود في فصل "التحقق من الصحة ومنطق العمل".
+
+## V14.1 توثيق حماية البيانات
+
+من الشروط المسبقة الرئيسية للقدرة على حماية البيانات تصنيف البيانات التي ينبغي اعتبارها حساسة. ومن المرجّح أن تكون هناك عدة مستويات مختلفة من الحساسية، وستكون الضوابط اللازمة لحماية البيانات في كل مستوى مختلفة.
+
+وهناك لوائح وقوانين خصوصية متنوعة تؤثّر في كيفية تعامل التطبيقات مع تخزين المعلومات الشخصية الحساسة واستخدامها ونقلها. ولم يعد هذا القسم يحاول تكرار هذه الأنواع من تشريعات حماية البيانات أو الخصوصية، بل يركّز على الاعتبارات التقنية الرئيسية لحماية البيانات الحساسة. يُرجى الرجوع إلى القوانين واللوائح المحلية، واستشارة متخصّص خصوصية مؤهّل أو محام عند الحاجة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **14.1.1** | تحقق من أن جميع البيانات الحساسة التي ينشئها التطبيق ويعالجها قد حُدّدت وصُنّفت في مستويات حماية. ويشمل ذلك البيانات المُرمَّزة فقط والتي يسهل بالتالي فك ترميزها، مثل سلاسل Base64 أو الحمولة بنص واضح داخل رمز JWT. ويلزم أن تراعي مستويات الحماية أي لوائح ومعايير لحماية البيانات والخصوصية يُطلب من التطبيق الامتثال لها. | 2 |
+| **14.1.2** | تحقق من أن لجميع مستويات حماية البيانات الحساسة مجموعة موثّقة من متطلبات الحماية. ويجب أن يشمل ذلك (على سبيل المثال لا الحصر) المتطلبات المتعلقة بالتشفير العام والتحقق من السلامة والاستبقاء وكيفية تسجيل البيانات وضوابط الوصول إلى البيانات الحساسة في السجلات والتشفير على مستوى قاعدة البيانات والخصوصية والتقنيات المعزّزة للخصوصية التي ستُستخدم، وغيرها من متطلبات السرية. | 2 |
+
+## V14.2 الحماية العامة للبيانات
+
+يحتوي هذا القسم على متطلبات عملية متنوعة متعلقة بحماية البيانات. ومعظمها خاص بمسائل معيّنة مثل تسريب البيانات غير المقصود، لكن هناك كذلك متطلبًا عامًا لتنفيذ ضوابط الحماية بناءً على مستوى الحماية المطلوب لكل عنصر بيانات.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **14.2.1** | تحقق من أن البيانات الحساسة لا تُرسل إلى الخادم إلا في متن رسالة HTTP أو في حقول ترويستها، ومن أن عنوان URL وسلسلة الاستعلام لا يحتويان على معلومات حساسة، مثل مفتاح واجهة برمجة تطبيقات أو رمز جلسة. | 1 |
+| **14.2.2** | تحقق من أن التطبيق يمنع تخزين البيانات الحساسة مؤقتًا في مكوّنات الخادم، مثل موازنات الحمل وذاكرات التخزين المؤقت للتطبيق، أو يضمن إزالة البيانات بأمان بعد الاستخدام. | 2 |
+| **14.2.3** | تحقق من أن البيانات الحساسة المحدّدة لا تُرسل إلى أطراف غير موثوقة (مثل أدوات تتبّع المستخدمين) لمنع الجمع غير المرغوب فيه للبيانات خارج نطاق سيطرة التطبيق. | 2 |
+| **14.2.4** | تحقق من أن الضوابط المتعلقة بالبيانات الحساسة بشأن التشفير والتحقق من السلامة والاستبقاء وكيفية تسجيل البيانات وضوابط الوصول إلى البيانات الحساسة في السجلات والخصوصية والتقنيات المعزّزة للخصوصية، مُنفَّذة على النحو المحدّد في الوثائق الخاصة بمستوى حماية البيانات المعنية. | 2 |
+| **14.2.5** | تحقق من أن آليات التخزين المؤقت مُهيّأة لتخزين الاستجابات التي تحمل نوع المحتوى المتوقع لذلك المورد فقط ولا تحتوي على محتوى حساس أو ديناميكي. وينبغي أن يعيد خادم الويب استجابة 404 أو 302 عند الوصول إلى ملف غير موجود بدلًا من إعادة ملف آخر صالح. وهذا ينبغي أن يمنع هجمات خداع ذاكرة التخزين المؤقت للويب. | 3 |
+| **14.2.6** | تحقق من أن التطبيق لا يعيد سوى الحد الأدنى المطلوب من البيانات الحساسة اللازم لوظائف التطبيق. على سبيل المثال، إعادة بعض أرقام بطاقة الائتمان فقط وليس الرقم الكامل. وإذا كانت البيانات الكاملة مطلوبة، فينبغي إخفاؤها في واجهة المستخدم إلا إذا اطّلع عليها المستخدم تحديدًا. | 3 |
+| **14.2.7** | تحقق من أن المعلومات الحساسة تخضع لتصنيف استبقاء البيانات، بما يضمن حذف البيانات القديمة أو غير الضرورية تلقائيًا، وفق جدول محدّد، أو حسب ما يقتضيه الوضع. | 3 |
+| **14.2.8** | تحقق من إزالة المعلومات الحساسة من البيانات الوصفية للملفات المقدَّمة من المستخدم إلا إذا وافق المستخدم على تخزينها. | 3 |
+
+## V14.3 حماية البيانات من جانب العميل
+
+يحتوي هذا القسم على متطلبات لمنع تسريب البيانات بطرائق معيّنة في جانب العميل أو وكيل المستخدم في التطبيق.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **14.3.1** | تحقق من أن البيانات المصادَق عليها تُمحى من تخزين العميل، مثل DOM في المتصفح، بعد إنهاء العميل أو الجلسة. وقد يساعد حقل ترويسة استجابة HTTP المسمّى 'Clear-Site-Data' في ذلك، لكن ينبغي أن يكون جانب العميل قادرًا كذلك على التنظيف إذا لم يكن الاتصال بالخادم متاحًا عند إنهاء الجلسة. | 1 |
+| **14.3.2** | تحقق من أن التطبيق يضبط حقول ترويسة استجابة HTTP كافية لمكافحة التخزين المؤقت (أي Cache-Control: no-store) بحيث لا تُخزَّن البيانات الحساسة مؤقتًا في المتصفحات. | 2 |
+| **14.3.3** | تحقق من أن البيانات المخزَّنة في تخزين المتصفح (مثل localStorage وsessionStorage وIndexedDB أو ملفات تعريف الارتباط) لا تحتوي على بيانات حساسة، باستثناء رموز الجلسة. | 2 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [Consider using the Security Headers website to check security and anti-caching header fields](https://securityheaders.com/)
+* [Documentation about anti-caching headers by Mozilla](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)
+* [OWASP Secure Headers project](https://owasp.org/www-project-secure-headers/)
+* [OWASP Privacy Risks Project](https://owasp.org/www-project-top-10-privacy-risks/)
+* [OWASP User Privacy Protection Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html)
+* [Australian Privacy Principle 11 - Security of personal information](https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-11-app-11-security-of-personal-information)
+* [European Union General Data Protection Regulation (GDPR) overview](https://www.edps.europa.eu/data-protection_en)
+* [European Union Data Protection Supervisor - Internet Privacy Engineering Network](https://www.edps.europa.eu/data-protection/ipen-internet-privacy-engineering-network_en)
+* [Information on the "Clear-Site-Data" header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data)
+* [White paper on Web Cache Deception](https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf)
diff --git a/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md b/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md
new file mode 100644
index 0000000000..4fb4ca0f6e
--- /dev/null
+++ b/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md
@@ -0,0 +1,77 @@
+# V15 البرمجة الآمنة والمعمارية
+
+## الهدف من ضوابط الأمان
+
+يتعلق كثير من متطلبات معيار التحقق من أمان التطبيقات إما بمجال معيّن من الأمان، مثل المصادقة أو التخويل، أو بنوع معيّن من وظائف التطبيق، مثل تسجيل الأحداث أو التعامل مع الملفات.
+
+ويوفّر هذا الفصل متطلبات أمنية عامة ينبغي مراعاتها عند تصميم التطبيقات وتطويرها. ولا تركّز هذه المتطلبات على نقاء المعمارية وجودة الشيفرة فحسب، بل كذلك على ممارسات معمارية وبرمجية محدّدة لازمة لأمان التطبيقات.
+
+## V15.1 توثيق البرمجة الآمنة والمعمارية
+
+يعتمد كثير من متطلبات إرساء معمارية آمنة وقابلة للدفاع على توثيق واضح للقرارات المتّخذة بشأن تنفيذ ضوابط أمنية معيّنة والمكوّنات المستخدمة داخل التطبيق.
+
+ويبيّن هذا القسم متطلبات التوثيق، بما فيها تحديد المكوّنات التي تُعدّ محتوية على "وظائف خطيرة" أو تُعدّ "مكوّنات محفوفة بالمخاطر".
+
+وقد يكون المكوّن ذو "الوظائف الخطيرة" مكوّنًا مطوّرًا داخليًا أو من طرف ثالث ينفّذ عمليات مثل فك تسلسل بيانات غير موثوقة أو تحليل ملفات أو بيانات ثنائية خام أو تنفيذ شيفرة ديناميكية أو التلاعب المباشر بالذاكرة. وتمثّل الثغرات في هذه الأنواع من العمليات خطرًا مرتفعًا لاختراق التطبيق واحتمال كشف بنيته التحتية الأساسية.
+
+أما "المكوّن المحفوف بالمخاطر" فهو مكتبة من طرف ثالث (أي غير مطوّرة داخليًا) تفتقر إلى ضوابط أمنية أو تنفّذها تنفيذًا سيئًا فيما يخص عمليات تطويرها أو وظائفها. ومن الأمثلة المكوّنات التي تُصان صيانة سيئة أو غير المدعومة أو التي في مرحلة نهاية العمر أو التي لها تاريخ من الثغرات الجسيمة.
+
+ويؤكّد هذا القسم كذلك أهمية تحديد أُطر زمنية ملائمة لمعالجة الثغرات في مكوّنات الأطراف الثالثة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **15.1.1** | تحقق من أن وثائق التطبيق تحدّد أُطرًا زمنية للمعالجة مبنية على المخاطر لإصدارات مكوّنات الأطراف الثالثة التي تحتوي على ثغرات، ولتحديث المكتبات بشكل عام، وذلك لتقليل المخاطر الناشئة عن هذه المكوّنات. | 1 |
+| **15.1.2** | تحقق من الاحتفاظ بفهرس جرد، مثل قائمة مكوّنات البرمجيات (SBOM)، لجميع مكتبات الأطراف الثالثة المستخدمة، بما في ذلك التحقق من أن المكوّنات تأتي من مستودعات محدّدة مسبقًا وموثوقة وتُصان على نحو مستمر. | 2 |
+| **15.1.3** | تحقق من أن وثائق التطبيق تحدّد الوظائف المستهلِكة للوقت أو المطلوبة للموارد بكثافة. ويجب أن يشمل ذلك كيفية منع فقدان التوافر بسبب الاستخدام المفرط لهذه الوظائف وكيفية تجنّب وضع يستغرق فيه بناء الاستجابة وقتًا أطول من مهلة المستهلك. وقد تشمل الدفاعات المحتملة المعالجة غير المتزامنة واستخدام قوائم الانتظار وتحديد العمليات المتوازية لكل مستخدم ولكل تطبيق. | 2 |
+| **15.1.4** | تحقق من أن وثائق التطبيق تُبرز مكتبات الأطراف الثالثة التي تُعدّ "مكوّنات محفوفة بالمخاطر". | 3 |
+| **15.1.5** | تحقق من أن وثائق التطبيق تُبرز أجزاء التطبيق التي تُستخدم فيها "وظائف خطيرة". | 3 |
+
+## V15.2 معمارية الأمان والتبعيات
+
+يشتمل هذا القسم على متطلبات للتعامل مع التبعيات والمكوّنات المحفوفة بالمخاطر أو القديمة أو غير الآمنة من خلال إدارة التبعيات.
+
+ويشمل كذلك استخدام تقنيات على مستوى المعمارية مثل العزل في صندوق رملي والتغليف والاحتواء في حاويات وعزل الشبكة، لتقليل أثر استخدام "العمليات الخطيرة" أو "المكوّنات المحفوفة بالمخاطر" (كما هي محدّدة في القسم السابق) ولمنع فقدان التوافر بسبب الاستخدام المفرط للوظائف المطلوبة للموارد بكثافة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **15.2.1** | تحقق من أن التطبيق لا يحتوي إلا على مكوّنات لم تتجاوز الأُطر الزمنية الموثّقة للتحديث والمعالجة. | 1 |
+| **15.2.2** | تحقق من أن التطبيق قد نفّذ دفاعات ضد فقدان التوافر بسبب الوظائف المستهلِكة للوقت أو المطلوبة للموارد بكثافة، بناءً على القرارات والاستراتيجيات الأمنية الموثّقة لذلك. | 2 |
+| **15.2.3** | تحقق من أن بيئة الإنتاج لا تشتمل إلا على الوظائف اللازمة لعمل التطبيق، ولا تكشف وظائف زائدة مثل شيفرة الاختبار والمقتطفات النموذجية ووظائف التطوير. | 2 |
+| **15.2.4** | تحقق من أن مكوّنات الأطراف الثالثة وجميع تبعياتها المتعدّية تُضمّ من المستودع المتوقع، سواء كان مملوكًا داخليًا أو مصدرًا خارجيًا، ومن عدم وجود خطر هجوم التباس التبعيات. | 3 |
+| **15.2.5** | تحقق من أن التطبيق ينفّذ حماية إضافية حول أجزاء التطبيق الموثّق أنها تحتوي على "وظائف خطيرة" أو تستخدم مكتبات أطراف ثالثة تُعدّ "مكوّنات محفوفة بالمخاطر". وقد يشمل ذلك تقنيات مثل العزل في صندوق رملي أو التغليف أو الاحتواء في حاويات أو العزل على مستوى الشبكة، لتأخير المهاجمين الذين يخترقون جزءًا من التطبيق وردعهم عن الانتقال إلى أماكن أخرى فيه. | 3 |
+
+## V15.3 البرمجة الدفاعية
+
+يتناول هذا القسم أنواع الثغرات، بما فيها تلاعب الأنواع وتلويث النموذج الأولي وغيرها، الناتجة عن استخدام أنماط برمجة غير آمنة في لغة معيّنة. وقد لا يكون بعضها ذا صلة بجميع اللغات، بينما سيكون لبعضها الآخر إصلاحات خاصة باللغة أو قد يتعلق بكيفية تعامل لغة أو إطار عمل معيّن مع ميزة مثل معاملات HTTP. ويراعي كذلك خطر عدم التحقق تشفيريًا من تحديثات التطبيق.
+
+ويراعي كذلك المخاطر المرتبطة باستخدام الكائنات لتمثيل عناصر البيانات وقبولها وإعادتها عبر واجهات برمجة التطبيقات الخارجية. وفي هذه الحالة، يجب أن يضمن التطبيق ألا تُعدَّل حقول البيانات التي لا ينبغي أن تكون قابلة للكتابة بواسطة مدخلات المستخدم (الإسناد الجماعي) وأن تكون واجهة برمجة التطبيقات انتقائية بشأن حقول البيانات التي تُعاد. وحيث يعتمد الوصول إلى الحقول على صلاحيات المستخدم، ينبغي مراعاة ذلك في سياق متطلب التحكم في الوصول على مستوى الحقول في فصل التخويل.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **15.3.1** | تحقق من أن التطبيق لا يعيد إلا المجموعة الفرعية المطلوبة من الحقول من كائن بيانات. على سبيل المثال، ينبغي ألا يعيد كائن بيانات كاملًا، إذ لا ينبغي أن تكون بعض الحقول الفردية متاحة للمستخدمين. | 1 |
+| **15.3.2** | تحقق من أن الواجهة الخلفية للتطبيق، حيث تجري استدعاءات إلى عناوين URL خارجية، مُهيّأة لعدم اتّباع عمليات إعادة التوجيه إلا إذا كانت وظيفة مقصودة. | 2 |
+| **15.3.3** | تحقق من أن التطبيق يمتلك تدابير مضادة للحماية من هجمات الإسناد الجماعي عن طريق تحديد الحقول المسموح بها لكل متحكّم وإجراء، أي أنه لا يمكن إدراج قيمة حقل أو تحديثها إذا لم يكن مقصودًا أن تكون جزءًا من ذلك الإجراء. | 2 |
+| **15.3.4** | تحقق من أن جميع مكوّنات الوكالة والبرمجيات الوسيطة تنقل عنوان IP الأصلي للمستخدم على نحو صحيح باستخدام حقول بيانات موثوقة لا يمكن للمستخدم النهائي التلاعب بها، ومن أن التطبيق وخادم الويب يستخدمان هذه القيمة الصحيحة لتسجيل الأحداث والقرارات الأمنية مثل تحديد المعدّل، مع مراعاة أن عنوان IP الأصلي نفسه قد لا يكون موثوقًا بسبب عناوين IP الديناميكية أو الشبكات الخاصة الافتراضية أو الجدران النارية للشركات. | 2 |
+| **15.3.5** | تحقق من أن التطبيق يضمن صراحةً أن المتغيرات من النوع الصحيح وينفّذ عمليات مساواة ومقارنة صارمة. والغرض من ذلك تجنّب ثغرات تلاعب الأنواع أو التباسها الناتجة عن افتراض شيفرة التطبيق نوعًا لمتغيّر ما. | 2 |
+| **15.3.6** | تحقق من أن شيفرة JavaScript مكتوبة بطريقة تمنع تلويث النموذج الأولي، وذلك مثلًا باستخدام Set() أو Map() بدلًا من الكائنات الحرفية. | 2 |
+| **15.3.7** | تحقق من أن التطبيق يمتلك دفاعات ضد هجمات تلويث معاملات HTTP، وخصوصًا إذا كان إطار عمل التطبيق لا يميّز بين مصادر معاملات الطلب (سلسلة الاستعلام أو معاملات المتن أو ملفات تعريف الارتباط أو حقول الترويسة). | 2 |
+
+## V15.4 التزامن الآمن
+
+يمكن أن تؤدي مشكلات التزامن، مثل حالات التسابق وثغرات من وقت الفحص إلى وقت الاستخدام (TOCTOU) والجمود والجمود الحيوي وتجويع الخيوط والمزامنة غير السليمة، إلى سلوك غير متوقع ومخاطر أمنية. ويشتمل هذا القسم على تقنيات واستراتيجيات متنوعة للمساعدة في التخفيف من هذه المخاطر.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **15.4.1** | تحقق من أن الكائنات المشتركة في الشيفرة متعددة الخيوط (مثل ذاكرات التخزين المؤقت أو الملفات أو الكائنات في الذاكرة التي تصل إليها خيوط متعددة) يُوصل إليها بأمان باستخدام أنواع آمنة للخيوط وآليات مزامنة مثل الأقفال أو الإشارات، وذلك لتجنّب حالات التسابق وتلف البيانات. | 3 |
+| **15.4.2** | تحقق من أن الفحوص على حالة مورد ما، مثل وجوده أو صلاحياته، والإجراءات التي تعتمد عليها تُنفَّذ كعملية ذرّية واحدة لمنع حالات تسابق من وقت الفحص إلى وقت الاستخدام (TOCTOU). على سبيل المثال، فحص وجود ملف قبل فتحه، أو التحقق من وصول مستخدم قبل منحه. | 3 |
+| **15.4.3** | تحقق من استخدام الأقفال باتساق لتجنّب تعلّق الخيوط، سواء بانتظار بعضها بعضًا أو بإعادة المحاولة إلى ما لا نهاية، ومن أن منطق القفل يبقى داخل الشيفرة المسؤولة عن إدارة المورد لضمان عدم إمكانية تعديل الأقفال عن غير قصد أو بشكل خبيث بواسطة أصناف أو شيفرات خارجية. | 3 |
+| **15.4.4** | تحقق من أن سياسات تخصيص الموارد تمنع تجويع الخيوط بضمان وصول عادل إلى الموارد، وذلك مثلًا بالاستفادة من مجمّعات الخيوط، بما يتيح للخيوط ذات الأولوية الأدنى المضي قدمًا في إطار زمني معقول. | 3 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP Prototype Pollution Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html)
+* [OWASP Mass Assignment Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html)
+* [OWASP CycloneDX Bill of Materials Specification](https://owasp.org/www-project-cyclonedx/)
+* [OWASP Web Security Testing Guide: Testing for HTTP Parameter Pollution](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution)
diff --git a/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md b/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md
new file mode 100644
index 0000000000..454f3d39f9
--- /dev/null
+++ b/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md
@@ -0,0 +1,84 @@
+# V16 تسجيل الأحداث الأمنية ومعالجة الأخطاء
+
+## الهدف من ضوابط الأمان
+
+تختلف سجلات الأمان عن سجلات الأخطاء أو الأداء، وتُستخدم لتدوين الأحداث ذات الصلة بالأمان مثل قرارات المصادقة وقرارات التحكم في الوصول ومحاولات تجاوز ضوابط الأمان، مثل التحقق من صحة المدخلات أو التحقق من منطق العمل. والغرض منها دعم الكشف والاستجابة والتحقيق من خلال توفير بيانات منظّمة عالية الإشارة لأدوات التحليل مثل أنظمة SIEM.
+
+ولا ينبغي أن تشتمل السجلات على بيانات شخصية حساسة إلا إذا كان ذلك مطلوبًا قانونًا، ويجب حماية أي بيانات مسجَّلة كأصل عالي القيمة. ويجب ألا يمسّ تسجيل الأحداث بالخصوصية أو بأمان النظام. ويجب كذلك أن تفشل التطبيقات بأمان، متجنّبةً الكشف أو التعطيل غير الضروريين.
+
+وللحصول على إرشادات تنفيذ مفصّلة، راجع أوراق OWASP المرجعية في قسم المراجع.
+
+## V16.1 توثيق تسجيل الأحداث الأمنية
+
+يضمن هذا القسم وجود جرد واضح وكامل لتسجيل الأحداث على امتداد حزمة التطبيق. وهذا ضروري للمراقبة الأمنية الفعّالة والاستجابة للحوادث والامتثال.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **16.1.1** | تحقق من وجود جرد يوثّق تسجيل الأحداث المُنفَّذ في كل طبقة من حزمة تقنيات التطبيق، وما الأحداث التي تُسجَّل، وصيغ السجلات، وأين تُخزَّن، وكيف تُستخدم، وكيف يُتحكَّم في الوصول إليها، ومدة الاحتفاظ بها. | 2 |
+
+## V16.2 تسجيل الأحداث العام
+
+يوفّر هذا القسم متطلبات للتأكد من أن سجلات الأمان منظّمة باتساق وتحتوي على البيانات الوصفية المتوقعة. والهدف جعل السجلات قابلة للقراءة آليًا وللتحليل على امتداد الأنظمة والأدوات الموزّعة.
+
+وبطبيعة الحال، تتضمّن الأحداث الأمنية غالبًا بيانات حساسة. وإذا سُجّلت هذه البيانات دون مراعاة، تصبح السجلات نفسها مصنّفة ومن ثم خاضعة لمتطلبات التشفير وسياسات استبقاء أكثر صرامة واحتمال الكشف عنها أثناء عمليات التدقيق.
+
+ولذلك من الأهمية البالغة تسجيل ما هو ضروري فقط والتعامل مع بيانات السجلات بالعناية نفسها التي تُولى للأصول الحساسة الأخرى.
+
+وتُرسي المتطلبات أدناه متطلبات أساسية لبيانات السجلات الوصفية والمزامنة والصيغة والتحكم.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **16.2.1** | تحقق من أن كل مدخلة في السجل تشتمل على البيانات الوصفية اللازمة (مثل متى وأين ومن وماذا) التي تتيح إجراء تحقيق مفصّل في التسلسل الزمني عند وقوع حدث. | 2 |
+| **16.2.2** | تحقق من أن مصادر الوقت لجميع مكوّنات تسجيل الأحداث متزامنة، ومن أن الطوابع الزمنية في البيانات الوصفية للأحداث الأمنية تستخدم التوقيت العالمي المنسّق (UTC) أو تشتمل على فرق منطقة زمنية صريح. ويُوصى باستخدام UTC لضمان الاتساق على امتداد الأنظمة الموزّعة ولمنع الالتباس أثناء التحوّلات إلى التوقيت الصيفي. | 2 |
+| **16.2.3** | تحقق من أن التطبيق لا يخزّن السجلات أو يبثّها إلا إلى الملفات والخدمات الموثّقة في جرد السجلات. | 2 |
+| **16.2.4** | تحقق من أن السجلات قابلة للقراءة والربط بواسطة معالج السجلات المستخدم، ويُفضَّل باستخدام صيغة تسجيل شائعة. | 2 |
+| **16.2.5** | تحقق من أن التطبيق، عند تسجيل بيانات حساسة، يُنفِذ التسجيل بناءً على مستوى حماية البيانات. على سبيل المثال، قد لا يُسمح بتسجيل بيانات معيّنة، مثل بيانات الاعتماد أو تفاصيل الدفع. وقد لا تُسجَّل بيانات أخرى، مثل رموز الجلسة، إلا بعد تلبيدها أو إخفائها، كليًا أو جزئيًا. | 2 |
+
+## V16.3 الأحداث الأمنية
+
+يحدّد هذا القسم متطلبات تسجيل الأحداث ذات الصلة بالأمان داخل التطبيق. والتقاط هذه الأحداث بالغ الأهمية لكشف السلوك المشبوه ودعم التحقيقات والوفاء بالتزامات الامتثال.
+
+ويبيّن هذا القسم أنواع الأحداث التي ينبغي تسجيلها لكنه لا يحاول تقديم تفاصيل شاملة. فلكل تطبيق عوامل مخاطر وسياق تشغيلي فريدان.
+
+ولاحظ أنه مع أن معيار التحقق من أمان التطبيقات يدرج تسجيل الأحداث الأمنية في نطاقه، فإن التنبيه والربط (مثل قواعد SIEM أو بنية المراقبة التحتية) يُعدّان خارج النطاق ويتولاهما نظامَا التشغيل والمراقبة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **16.3.1** | تحقق من تسجيل جميع عمليات المصادقة، بما فيها المحاولات الناجحة وغير الناجحة. وينبغي كذلك جمع بيانات وصفية إضافية، مثل نوع المصادقة أو العوامل المستخدمة. | 2 |
+| **16.3.2** | تحقق من تسجيل محاولات التخويل الفاشلة. وبالنسبة إلى المستوى 3، يجب أن يشمل ذلك تسجيل جميع قرارات التخويل، بما فيها التسجيل عند الوصول إلى بيانات حساسة (دون تسجيل البيانات الحساسة نفسها). | 2 |
+| **16.3.3** | تحقق من أن التطبيق يسجّل الأحداث الأمنية المحدّدة في الوثائق ويسجّل كذلك محاولات تجاوز ضوابط الأمان، مثل التحقق من صحة المدخلات ومنطق العمل ومكافحة الأتمتة. | 2 |
+| **16.3.4** | تحقق من أن التطبيق يسجّل الأخطاء غير المتوقعة وأعطال ضوابط الأمان مثل أعطال TLS في الواجهة الخلفية. | 2 |
+
+## V16.4 حماية السجلات
+
+السجلات آثار جنائية قيّمة ويجب حمايتها. فإذا كان من السهل تعديل السجلات أو حذفها، فإنها تفقد سلامتها وتصبح غير موثوقة للتحقيق في الحوادث أو للإجراءات القانونية. وقد تكشف السجلات السلوك الداخلي للتطبيق أو بيانات وصفية حساسة، ما يجعلها هدفًا جاذبًا للمهاجمين.
+
+ويحدّد هذا القسم متطلبات للتأكد من حماية السجلات من الوصول غير المصرَّح به والتلاعب والكشف، ومن أنها تُنقل وتُخزَّن بأمان في أنظمة آمنة ومعزولة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **16.4.1** | تحقق من أن جميع مكوّنات تسجيل الأحداث تُرمّز البيانات على النحو الملائم لمنع حقن السجلات. | 2 |
+| **16.4.2** | تحقق من أن السجلات محمية من الوصول غير المصرَّح به ولا يمكن تعديلها. | 2 |
+| **16.4.3** | تحقق من أن السجلات تُنقل بأمان إلى نظام منفصل منطقيًا للتحليل والكشف والتنبيه والتصعيد. والهدف التأكد من أنه في حال اختراق التطبيق، لا تُختَرق السجلات. | 2 |
+
+## V16.5 معالجة الأخطاء
+
+يحدّد هذا القسم متطلبات للتأكد من أن التطبيقات تفشل بسلاسة وأمان دون كشف تفاصيل داخلية حساسة.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **16.5.1** | تحقق من إعادة رسالة عامة إلى المستهلك عند وقوع خطأ غير متوقع أو حسّاس أمنيًا، بما يضمن عدم كشف بيانات داخلية حساسة للنظام مثل تتبّعات المكدّس والاستعلامات والمفاتيح السرّية والرموز المميزة. | 2 |
+| **16.5.2** | تحقق من أن التطبيق يستمر في العمل بأمان عند فشل الوصول إلى مورد خارجي، وذلك مثلًا باستخدام أنماط مثل قواطع الدائرة أو التدهور السلس. | 2 |
+| **16.5.3** | تحقق من أن التطبيق يفشل بسلاسة وأمان، بما في ذلك عند وقوع استثناء، بما يمنع حالات الفشل المفتوح مثل معالجة معاملة رغم الأخطاء الناتجة عن منطق التحقق من الصحة. | 2 |
+| **16.5.4** | تحقق من تعريف معالج أخطاء "كملاذ أخير" يلتقط جميع الاستثناءات غير المعالجة. والغرض من ذلك تجنّب فقدان تفاصيل الأخطاء التي يجب أن تذهب إلى ملفات السجلات، وكذلك ضمان ألا يُسقط خطأ ما عملية التطبيق بأكملها، ما يؤدي إلى فقدان التوافر. | 3 |
+
+ملاحظة: هناك لغات معيّنة (منها Swift وGo، وبحكم الممارسة التصميمية الشائعة، كثير من اللغات الوظيفية) لا تدعم الاستثناءات أو معالجات الأحداث كملاذ أخير. وفي هذه الحالة، ينبغي للمعماريين والمطوّرين استخدام نمط أو لغة أو طريقة ملائمة لإطار العمل لضمان قدرة التطبيقات على معالجة الأحداث الاستثنائية أو غير المتوقعة أو المتصلة بالأمان بأمان.
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* [OWASP Web Security Testing Guide: Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README)
+* [OWASP Authentication Cheat Sheet section about error messages](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages)
+* [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
+* [OWASP Application Logging Vocabulary Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html)
diff --git a/5.0/ar/0x26-V17-WebRTC.md b/5.0/ar/0x26-V17-WebRTC.md
new file mode 100644
index 0000000000..175a49669d
--- /dev/null
+++ b/5.0/ar/0x26-V17-WebRTC.md
@@ -0,0 +1,75 @@
+# V17 WebRTC
+
+## الهدف من ضوابط الأمان
+
+تتيح اتصالات الويب في الوقت الحقيقي (WebRTC) تبادل الصوت والفيديو والبيانات في الوقت الحقيقي في التطبيقات الحديثة. ومع تزايد التبنّي، يصبح تأمين بنية WebRTC التحتية أمرًا بالغ الأهمية. ويوفّر هذا القسم متطلبات أمنية لأصحاب المصلحة الذين يطوّرون أنظمة WebRTC أو يستضيفونها أو يدمجونها.
+
+ويمكن تصنيف سوق WebRTC عمومًا في ثلاثة قطاعات:
+
+1. مطوّرو المنتجات: المورّدون المالكون ومورّدو المصادر المفتوحة الذين ينشئون منتجات وحلول WebRTC ويوفّرونها. وتركيزهم على تطوير تقنيات WebRTC متينة وآمنة يمكن للآخرين استخدامها.
+
+2. منصات الاتصالات كخدمة (CPaaS): المزوّدون الذين يوفّرون واجهات برمجة التطبيقات وحِزَم تطوير البرمجيات والبنية التحتية أو المنصات اللازمة لتمكين وظائف WebRTC. وقد يستخدم مزوّدو CPaaS منتجات من الفئة الأولى أو يطوّرون برمجيات WebRTC خاصة بهم لتقديم هذه الخدمات.
+
+3. مزوّدو الخدمات: المؤسسات التي تستفيد من منتجات مطوّري المنتجات أو مزوّدي CPaaS، أو تطوّر حلول WebRTC خاصة بها. وهي تنشئ وتنفّذ تطبيقات للمؤتمرات عبر الإنترنت والرعاية الصحية والتعلّم الإلكتروني وغيرها من المجالات التي يكون فيها الاتصال في الوقت الحقيقي بالغ الأهمية.
+
+والمتطلبات الأمنية المبيّنة هنا موجّهة أساسًا إلى مطوّري المنتجات ومزوّدي CPaaS ومزوّدي الخدمات الذين:
+
+* يستفيدون من حلول المصادر المفتوحة لبناء تطبيقات WebRTC الخاصة بهم.
+* يستخدمون منتجات WebRTC التجارية كجزء من بنيتهم التحتية.
+* يستخدمون حلول WebRTC المطوّرة داخليًا أو يدمجون مكوّنات متنوعة في عرض خدمة متكامل.
+
+ومن المهم ملاحظة أن هذه المتطلبات الأمنية لا تنطبق على المطوّرين الذين يستخدمون حصريًا حِزَم تطوير البرمجيات وواجهات برمجة التطبيقات التي يوفّرها مورّدو CPaaS. فبالنسبة إلى هؤلاء المطوّرين، يكون مزوّدو CPaaS مسؤولين عادةً عن معظم الاعتبارات الأمنية الأساسية داخل منصاتهم، وقد لا يلبّي معيار أمني عام مثل معيار التحقق من أمان التطبيقات احتياجاتهم بالكامل.
+
+## V17.1 خادم TURN
+
+يحدّد هذا القسم متطلبات أمنية للأنظمة التي تشغّل خوادم TURN (الاجتياز باستخدام المُرحِّلات حول NAT) الخاصة بها. وتساعد خوادم TURN في ترحيل الوسائط في بيئات الشبكات المقيّدة، لكنها قد تمثّل مخاطر إذا هُيّئت على نحو خاطئ. وتركّز هذه الضوابط على التصفية الآمنة للعناوين والحماية من استنفاد الموارد.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **17.1.1** | تحقق من أن خدمة الاجتياز باستخدام المُرحِّلات حول NAT (TURN) لا تسمح بالوصول إلا إلى عناوين IP غير المحجوزة لأغراض خاصة (مثل الشبكات الداخلية والبث والاسترجاع المحلي). ولاحظ أن هذا ينطبق على عناوين IPv4 وIPv6 على حد سواء. | 2 |
+| **17.1.2** | تحقق من أن خدمة الاجتياز باستخدام المُرحِّلات حول NAT (TURN) غير معرّضة لاستنفاد الموارد عندما يحاول مستخدمون شرعيون فتح عدد كبير من المنافذ على خادم TURN. | 3 |
+
+## V17.2 الوسائط
+
+لا تنطبق هذه المتطلبات إلا على الأنظمة التي تستضيف خوادم وسائط WebRTC الخاصة بها، مثل وحدات التوجيه الانتقائي (SFUs) ووحدات التحكم متعددة النقاط (MCUs) وخوادم التسجيل أو خوادم البوابات. وتتعامل خوادم الوسائط مع تدفقات الوسائط وتوزّعها، ما يجعل أمانها بالغ الأهمية لحماية الاتصال بين الأنداد. وحماية تدفقات الوسائط أمر بالغ الأهمية في تطبيقات WebRTC لمنع التنصّت والتلاعب وهجمات حجب الخدمة التي قد تمسّ بخصوصية المستخدم وجودة الاتصال.
+
+وعلى وجه الخصوص، من الضروري تنفيذ حماية من هجمات الإغراق، مثل تحديد المعدّل والتحقق من الطوابع الزمنية واستخدام ساعات متزامنة لمطابقة الفواصل الزمنية في الوقت الحقيقي وإدارة المخازن المؤقتة لمنع الفيضان والحفاظ على التوقيت السليم. وإذا وصلت رزم جلسة وسائط معيّنة بسرعة مفرطة، فينبغي إسقاط الرزم الزائدة. ومن المهم كذلك حماية النظام من الرزم المشوّهة عن طريق تنفيذ التحقق من صحة المدخلات ومعالجة فيضان الأعداد الصحيحة بأمان ومنع فيضان المخازن المؤقتة واستخدام تقنيات أخرى متينة لمعالجة الأخطاء.
+
+أما الأنظمة التي تعتمد كليًا على اتصال الوسائط ندًّا لندّ بين متصفحات الويب، دون مشاركة خوادم وسائط وسيطة، فهي مستثناة من هذه المتطلبات الأمنية المحدّدة المتعلقة بالوسائط.
+
+ويشير هذا القسم إلى استخدام أمان طبقة النقل لرزم البيانات (DTLS) في سياق WebRTC. ويمكن العثور على متطلب متعلق بوجود سياسة موثّقة لإدارة مفاتيح التشفير في فصل "التشفير". ويمكن العثور على معلومات عن طرائق التشفير المعتمدة إما في ملحق التشفير في معيار التحقق من أمان التطبيقات أو في وثائق مثل NIST SP 800-52 Rev. 2 أو BSI TR-02102-2 (الإصدار 2025-01).
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **17.2.1** | تحقق من أن مفتاح شهادة أمان طبقة النقل لرزم البيانات (DTLS) يُدار ويُحمى بناءً على السياسة الموثّقة لإدارة مفاتيح التشفير. | 2 |
+| **17.2.2** | تحقق من أن خادم الوسائط مُهيّأ لاستخدام ودعم مجموعات تشفير معتمدة لأمان طبقة النقل لرزم البيانات (DTLS) وملف حماية آمن لامتداد DTLS الخاص بإنشاء مفاتيح لبروتوكول النقل الآمن في الوقت الحقيقي (DTLS-SRTP). | 2 |
+| **17.2.3** | تحقق من فحص مصادقة بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) في خادم الوسائط لمنع هجمات حقن بروتوكول النقل في الوقت الحقيقي (RTP) من أن تؤدي إلى حالة حجب خدمة أو إلى إدخال وسائط صوتية أو مرئية في تدفقات الوسائط. | 2 |
+| **17.2.4** | تحقق من أن خادم الوسائط قادر على مواصلة معالجة حِزَم الوسائط الواردة عند مواجهة رزم مشوّهة من بروتوكول النقل الآمن في الوقت الحقيقي (SRTP). | 2 |
+| **17.2.5** | تحقق من أن خادم الوسائط قادر على مواصلة معالجة حِزَم الوسائط الواردة أثناء إغراق برزم بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) من مستخدمين شرعيين. | 3 |
+| **17.2.6** | تحقق من أن خادم الوسائط غير معرّض لثغرة حالة التسابق في "ClientHello" في أمان طبقة النقل لرزم البيانات (DTLS)، وذلك بفحص ما إذا كان خادم الوسائط معروفًا علنًا بأنه معرّض لها أو بإجراء اختبار حالة التسابق. | 3 |
+| **17.2.7** | تحقق من أن أي آليات لتسجيل الصوت أو الفيديو مرتبطة بخادم الوسائط قادرة على مواصلة معالجة حِزَم الوسائط الواردة أثناء إغراق برزم بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) من مستخدمين شرعيين. | 3 |
+| **17.2.8** | تحقق من فحص شهادة أمان طبقة النقل لرزم البيانات (DTLS) مقابل سمة البصمة في بروتوكول وصف الجلسة (SDP)، وإنهاء تدفق الوسائط في حال فشل الفحص، وذلك لضمان أصالة تدفق الوسائط. | 3 |
+
+## V17.3 الإشارات
+
+يحدّد هذا القسم متطلبات للأنظمة التي تشغّل خوادم الإشارات الخاصة بها في WebRTC. وتنسّق الإشارات الاتصال ندًّا لندّ ويجب أن تكون صامدة أمام الهجمات التي قد تعطّل إنشاء الجلسة أو التحكم فيها.
+
+ولضمان إشارات آمنة، يجب أن تتعامل الأنظمة مع المدخلات المشوّهة بسلاسة وأن تبقى متاحة تحت الحمل.
+
+| # | الوصف | المستوى |
+| :---: | :--- | :---: |
+| **17.3.1** | تحقق من أن خادم الإشارات قادر على مواصلة معالجة رسائل الإشارات الواردة الشرعية أثناء هجوم إغراق. وينبغي تحقيق ذلك بتنفيذ تحديد للمعدّل على مستوى الإشارات. | 2 |
+| **17.3.2** | تحقق من أن خادم الإشارات قادر على مواصلة معالجة رسائل الإشارات الشرعية عند مواجهة رسالة إشارات مشوّهة قد تسبّب حالة حجب خدمة. وقد يشمل ذلك تنفيذ التحقق من صحة المدخلات ومعالجة فيضان الأعداد الصحيحة بأمان ومنع فيضان المخازن المؤقتة واستخدام تقنيات أخرى متينة لمعالجة الأخطاء. | 2 |
+
+## المراجع
+
+لمزيد من المعلومات، انظر أيضًا:
+
+* أفضل توثيق لهجوم حجب الخدمة عبر ClientHello في DTLS الخاص بـ WebRTC موجود في [Enable Security's blog post aimed at security professionals](https://www.enablesecurity.com/blog/novel-dos-vulnerability-affecting-webrtc-media-servers/) وفي [white paper aimed at WebRTC developers](https://www.enablesecurity.com/blog/webrtc-hello-race-conditions-paper/) المرتبطة به
+* [RFC 3550 - RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550)
+* [RFC 3711 - The Secure Real-time Transport Protocol (SRTP)](https://datatracker.ietf.org/doc/html/rfc3711)
+* [RFC 5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP))](https://datatracker.ietf.org/doc/html/rfc5764)
+* [RFC 8825 - Overview: Real-Time Protocols for Browser-Based Applications](https://www.rfc-editor.org/info/rfc8825)
+* [RFC 8826 - Security Considerations for WebRTC](https://www.rfc-editor.org/info/rfc8826)
+* [RFC 8827 - WebRTC Security Architecture](https://www.rfc-editor.org/info/rfc8827)
+* [DTLS-SRTP Protection Profiles](https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml)
diff --git a/5.0/ar/0x90-Appendix-A_Glossary.md b/5.0/ar/0x90-Appendix-A_Glossary.md
new file mode 100644
index 0000000000..90e55ae4ff
--- /dev/null
+++ b/5.0/ar/0x90-Appendix-A_Glossary.md
@@ -0,0 +1,89 @@
+# الملحق أ: قائمة المصطلحات
+
+* **Absolute Maximum Session Lifetime** (العمر الأقصى المطلق للجلسة) – يُشار إليه أيضًا باسم "Overall Timeout" في NIST، وهو أقصى مدة زمنية يمكن أن تبقى فيها الجلسة نشطة بعد المصادقة بغض النظر عن تفاعل المستخدم. وهو أحد مكوّنات انتهاء صلاحية الجلسة.
+* **Allowlist** (قائمة السماح) – قائمة بالبيانات أو العمليات المسموح بها، على سبيل المثال قائمة بالمحارف المسموح بها لإجراء التحقق من صحة المدخلات.
+* **Anti-forgery token** (رمز الحماية من التزوير) – آلية يتم فيها تمرير رمز مميز واحد أو أكثر في الطلب ويتحقق منها خادم التطبيق للتأكد من أن الطلب قد ورد من نقطة نهاية متوقعة.
+* **Application Security** (أمان التطبيق) – يركّز الأمان على مستوى التطبيق على تحليل المكوّنات التي تشكّل طبقة التطبيق في النموذج المرجعي لربط الأنظمة المفتوحة (OSI Model)، بدلًا من التركيز على نظام التشغيل الأساسي أو الشبكات المتصلة مثلًا.
+* **Application Security Verification** (التحقق من أمان التطبيق) – التقييم الفني لتطبيق ما مقابل معيار معيار OWASP للتحقق من أمان التطبيقات.
+* **Application Security Verification Report** (تقرير التحقق من أمان التطبيق) – تقرير يوثّق النتائج الإجمالية والتحليل الداعم الذي ينتجه المدقّق لتطبيق معيّن.
+* **Authentication** (المصادقة) – التحقق من الهوية المُدّعاة لمستخدم التطبيق.
+* **Automated Verification** (التحقق المؤتمت) – استخدام أدوات مؤتمتة (إما أدوات التحليل الديناميكي أو أدوات التحليل الساكن أو كلتيهما) تستخدم تواقيع الثغرات للعثور على المشكلات.
+* **Black box testing** (اختبار الصندوق الأسود) – طريقة لاختبار البرمجيات تفحص وظائف التطبيق دون النظر في هياكله أو آليات عمله الداخلية.
+* **Common Weakness Enumeration** (CWE، تعداد نقاط الضعف الشائعة) – قائمة مطوّرة من قِبل المجتمع لنقاط ضعف أمان البرمجيات الشائعة. وهي بمثابة لغة مشتركة، ومقياس لأدوات أمان البرمجيات، وخط أساس لجهود تحديد نقاط الضعف والتخفيف منها والوقاية منها.
+* **Component** (المكوّن) – وحدة برمجية قائمة بذاتها، مع ما يرتبط بها من واجهات القرص والشبكة، تتواصل مع المكوّنات الأخرى.
+* **Credential Service Provider** (CSP، مزوّد خدمة بيانات الاعتماد) – يُسمّى أيضًا مزوّد الهوية (IdP). مصدر لبيانات المستخدمين يمكن أن تستخدمه تطبيقات أخرى كمصدر للمصادقة.
+* **Cross-Site Script Inclusion** (XSSI، تضمين النصوص البرمجية عبر المواقع) - نوع من هجمات البرمجة النصية عبر المواقع (XSS) يجلب فيه تطبيق الويب شيفرة ضارة من مورد خارجي ويضمّنها كجزء من محتواه.
+* **Cross-Site Scripting** (XSS، البرمجة النصية عبر المواقع) – ثغرة أمنية توجد عادةً في تطبيقات الويب وتسمح بحقن نصوص برمجية تُنفّذ من جانب العميل في المحتوى.
+* **Cryptographic module** (وحدة التشفير) – العتاد أو البرمجيات أو البرمجيات الثابتة التي تنفّذ خوارزميات التشفير أو تُنشئ مفاتيح التشفير.
+* **Cryptographically secure pseudo-random number generator** (CSPRNG، مولّد أعداد شبه عشوائية آمن تشفيريًا) - مولّد أعداد شبه عشوائية يتمتع بخصائص تجعله مناسبًا للاستخدام في التشفير، ويُشار إليه أيضًا باسم مولّد الأعداد العشوائية التشفيري (CRNG).
+* **Datagram Transport Layer Security** (DTLS، أمان طبقة النقل لرزم البيانات) – بروتوكول تشفيري يوفّر أمان الاتصال عبر اتصال شبكي. يستند إلى بروتوكول TLS لكنه مكيّف لحماية البروتوكولات الموجّهة للرزم (عادةً عبر UDP). معرّف في RFC 9147 لإصدار DTLS 1.3.
+* **Datagram Transport Layer Security Extension to Establish Keys for the Secure Real-time Transport Protocol** (DTLS-SRTP) – آلية لاستخدام مصافحة DTLS لإنشاء مادة المفاتيح لجلسة SRTP. معرّفة في RFC 5764.
+* **Design Verification** (التحقق من التصميم) – التقييم الفني لمعمارية أمان التطبيق.
+* **Dynamic Application Security Testing** (DAST، الاختبار الديناميكي لأمان التطبيقات) – تقنيات مصمّمة لكشف الظروف التي تدل على وجود ثغرة أمنية في التطبيق أثناء تشغيله.
+* **Dynamic Verification** (التحقق الديناميكي) – استخدام أدوات مؤتمتة تستخدم تواقيع الثغرات للعثور على المشكلات أثناء تنفيذ التطبيق.
+* **Fast IDentity Online** (FIDO، الهوية السريعة عبر الإنترنت) – مجموعة من معايير المصادقة تتيح استخدام طرائق مصادقة متنوعة، منها القياسات الحيوية ووحدات النظام الأساسي الموثوق (TPMs) ورموز أمان USB وغيرها.
+* **Hardware Security Module** (HSM، وحدة أمان العتاد) – مكوّن عتادي يخزّن مفاتيح التشفير وغيرها من الأسرار بطريقة محمية.
+* **Hibernate Query Language** (HQL) – لغة استعلام تشبه في شكلها لغة SQL وتستخدمها مكتبة Hibernate ORM.
+* **HTTP Strict Transport Security** (HSTS) – سياسة توجّه المتصفح إلى الاتصال بالنطاق الذي يعيد الترويسة عبر TLS فقط وعند تقديم شهادة صالحة. وتُنشَّط باستخدام حقل ترويسة الاستجابة Strict-Transport-Security.
+* **HyperText Transfer Protocol** (HTTP، بروتوكول نقل النص التشعبي) – بروتوكول تطبيقي لأنظمة المعلومات التشعبية الموزّعة والتعاونية. وهو أساس تبادل البيانات في شبكة الويب العالمية.
+* **HyperText Transfer Protocol over SSL/TLS** (HTTPS) – طريقة لتأمين اتصالات HTTP عن طريق تشفيرها باستخدام أمان طبقة النقل (TLS).
+* **Identity Provider** (IdP، مزوّد الهوية) – يُسمّى أيضًا مزوّد خدمة بيانات الاعتماد (CSP) في مراجع NIST. كيان يوفّر مصدرًا للمصادقة لتطبيقات أخرى.
+* **Inactivity Timeout** (مهلة عدم النشاط) – المدة الزمنية التي يمكن أن تبقى فيها الجلسة نشطة في غياب تفاعل المستخدم مع التطبيق. وهو أحد مكوّنات انتهاء صلاحية الجلسة.
+* **Input Validation** (التحقق من صحة المدخلات) – توحيد مدخلات المستخدم غير الموثوقة إلى صورتها القياسية والتحقق من صحتها.
+* **JSON Web Token** (JWT) – يحدّد RFC 7519 معيارًا لكائن بيانات JSON يتكوّن من قسم ترويسة يوضّح كيفية التحقق من الكائن، وقسم متن يحتوي على مجموعة من المطالبات، وقسم توقيع يحتوي على توقيع رقمي يمكن استخدامه للتحقق من محتويات قسم المتن. وهو نوع من الرموز المميزة المكتفية بذاتها.
+* **Local File Inclusion** (LFI، تضمين الملفات المحلية) - هجوم يستغل إجراءات تضمين الملفات المعرّضة للخطر في التطبيق، ما يؤدي إلى تضمين ملفات محلية موجودة بالفعل على الخادم.
+* **Malicious Code** (الشيفرة الضارة) – شيفرة تُدخل في التطبيق أثناء تطويره دون علم مالك التطبيق، وتتحايل على سياسة الأمان المقصودة للتطبيق. وهي ليست كالبرمجيات الخبيثة مثل الفيروس أو الدودة!
+* **Malware** (البرمجيات الخبيثة) – شيفرة قابلة للتنفيذ تُدخل في التطبيق أثناء وقت التشغيل دون علم مستخدم التطبيق أو مسؤوله.
+* **Message authentication code** (MAC، رمز مصادقة الرسالة) - مجموع تحقق تشفيري على البيانات، يُحسب بواسطة خوارزمية توليد MAC، ويُستخدم لتوفير ضمان لسلامة البيانات وأصالتها.
+* **Multi-factor authentication** (MFA، المصادقة متعددة العوامل) – مصادقة تتضمّن عاملين أو أكثر من العوامل الفردية.
+* **Mutual TLS** (mTLS، أمان طبقة النقل المتبادل) – انظر TLS client authentication.
+* **Object-relational Mapping** (ORM، التعيين الكياني العلائقي) – نظام يُستخدم للسماح بالإشارة إلى قاعدة بيانات علائقية أو جدولية والاستعلام عنها داخل برنامج تطبيقي باستخدام نموذج كائني متوافق مع التطبيق.
+* **One-time Password** (OTP، كلمة المرور لمرة واحدة) – كلمة مرور تُولَّد بشكل فريد لاستخدامها في مناسبة واحدة.
+* **Open Worldwide Application Security Project** (OWASP، المشروع العالمي المفتوح لأمان التطبيقات) – المشروع العالمي المفتوح لأمان التطبيقات (OWASP) هو مجتمع عالمي حر ومفتوح يركّز على تحسين أمان برمجيات التطبيقات. ومهمتنا هي جعل أمان التطبيقات "مرئيًا"، بحيث يستطيع الأفراد والمؤسسات اتخاذ قرارات مستنيرة بشأن مخاطر أمان التطبيقات. انظر: [https://www.owasp.org/](https://www.owasp.org/).
+* **Password-Based Key Derivation Function 2** (PBKDF2، دالة اشتقاق المفاتيح المعتمدة على كلمة المرور 2) – خوارزمية خاصة أحادية الاتجاه تُستخدم لإنشاء مفتاح تشفيري قوي من نص مُدخل (مثل كلمة مرور) وقيمة ملح عشوائية إضافية، ويمكن استخدامها بالتالي لزيادة صعوبة كسر كلمة المرور دون اتصال إذا خُزّنت القيمة الناتجة بدلًا من كلمة المرور الأصلية.
+* **Public Key Infrastructure** (PKI، البنية التحتية للمفتاح العام) – ترتيب يربط المفاتيح العامة بهويات الكيانات المقابلة لها. ويُنشأ هذا الربط من خلال عملية تسجيل وإصدار للشهادات لدى سلطة إصدار الشهادات (CA) وبواسطتها.
+* **Public Switched Telephone Network** (PSTN، شبكة الهاتف العمومية المبدّلة) – شبكة الهاتف التقليدية التي تشمل كلًّا من هواتف الخطوط الثابتة والهواتف المحمولة.
+* **Real-time Transport Protocol** (RTP) و**Real-time Transport Control Protocol** (RTCP) – بروتوكولان يُستخدمان معًا لنقل تدفقات الوسائط المتعددة. تستخدمهما حزمة WebRTC. معرّفان في RFC 3550.
+* **Reference Token** (الرمز المميز المرجعي) – نوع من الرموز المميزة يعمل كمؤشّر أو معرّف لحالة أو بيانات وصفية مخزّنة على الخادم، ويُشار إليه أحيانًا بالرموز العشوائية أو الرموز المعتمة. وبخلاف الرموز المكتفية بذاتها، التي تضمّن بعض بياناتها ذات الصلة داخل الرمز نفسه، لا تحتوي الرموز المرجعية على أي معلومات ذاتية، بل تعتمد على الخادم للحصول على السياق. ويكون الرمز المرجعي معرّف جلسة أو يحتوي عليه.
+* **Relying Party** (RP، الطرف المعوِّل) – عمومًا تطبيق يعوّل على مستخدم قد صادق لدى مزوّد مصادقة منفصل. ويعتمد التطبيق على نوع من الرموز المميزة أو مجموعة من التأكيدات الموقّعة التي يوفّرها مزوّد المصادقة ليثق بأن المستخدم هو من يدّعي أنه هو.
+* **Remote File Inclusion** (RFI، تضمين الملفات البعيدة) - هجوم يستغل إجراءات التضمين المعرّضة للخطر في التطبيق، ما ينتج عنه تضمين ملفات بعيدة.
+* **Scalable Vector Graphics** (SVG، الرسوميات المتجهية القابلة للتحجيم) – لغة توصيف قائمة على XML لوصف الرسوميات المتجهية ثنائية الأبعاد.
+* **Secure Real-time Transport Protocol** (SRTP) و**Secure Real-time Transport Control Protocol** (SRTCP) – ملف تعريفي لبروتوكولي RTP وRTCP يوفّر دعمًا لتشفير الرسائل والمصادقة وحماية السلامة. معرّف في RFC 3711.
+* **Security Architecture** (معمارية الأمان) – تجريد لتصميم التطبيق يحدّد ويصف موضع ضوابط الأمان وكيفية استخدامها، ويحدّد ويصف كذلك موضع بيانات المستخدم والتطبيق وحساسيتها.
+* **Security Assertion Markup Language** (SAML) – معيار مفتوح لمصادقة الدخول الموحّد يستند إلى تمرير تأكيدات موقّعة (كائنات XML عادةً) بين مزوّد الهوية والطرف المعوِّل.
+* **Security Configuration** (تكوين الأمان) – تكوين وقت التشغيل للتطبيق الذي يؤثّر في كيفية استخدام ضوابط الأمان.
+* **Security Control** (ضابط الأمان) – دالة أو مكوّن يجري فحصًا أمنيًا (مثل فحص التخويل) أو يؤدي عند استدعائه إلى أثر أمني (مثل توليد سجل تدقيق).
+* **Security information and event management** (SIEM، إدارة معلومات الأمان والأحداث) - نظام لكشف التهديدات والامتثال وإدارة حوادث الأمان من خلال جمع وتحليل البيانات المتعلقة بالأمان من مصادر مختلفة داخل البنية التحتية لتقنية المعلومات في المؤسسة.
+* **Self-Contained Token** (الرمز المميز المكتفي بذاته) – رمز مميز يضمّن سمة واحدة أو أكثر لا تعتمد على حالة مخزّنة في الخادم أو على تخزين خارجي آخر. وتضمن هذه الرموز أصالة سماتها المضمّنة وسلامتها، ما يتيح تبادلًا آمنًا و"عديم الحالة" للمعلومات بين الأنظمة. وتُؤمَّن الرموز المكتفية بذاتها عمومًا باستخدام تقنيات تشفيرية، مثل التوقيعات الرقمية أو رموز مصادقة الرسائل (MACs)، لضمان أصالة بياناتها وسلامتها، وفي بعض الحالات سريتها. ومن الأمثلة الشائعة تأكيدات SAML وJWTs.
+* **Server-side Request Forgery** (SSRF، تزوير الطلب من جانب الخادم) – هجوم يسيء استخدام وظيفة على الخادم لقراءة موارد داخلية أو تحديثها. يقدّم المهاجم عنوان URL أو يعدّله، لتقرأه الشيفرة العاملة على الخادم أو ترسل إليه بيانات.
+* **Session Description Protocol** (SDP، بروتوكول وصف الجلسة) – صيغة رسائل لإعداد جلسة وسائط متعددة (تُستخدم في WebRTC مثلًا). معرّف في RFC 4566.
+* **Session Identifier** أو **Session ID** (معرّف الجلسة) – مفتاح يعرّف جلسة ذات حالة مخزّنة في الواجهة الخلفية. ويُنقل إلى العميل ومنه إما كـ"رمز مرجعي" أو داخله.
+* **Session Token** (الرمز المميز للجلسة) – عبارة جامعة تُستخدم في هذا المعيار للإشارة إلى الرمز المميز أو القيمة المستخدمة في آليات الجلسات عديمة الحالة (التي تستخدم رمزًا مكتفيًا بذاته) أو آليات الجلسات ذات الحالة (التي تستخدم رمزًا مرجعيًا).
+* **Session Traversal Utilities for NAT** (STUN) – بروتوكول يُستخدم للمساعدة في اجتياز NAT من أجل إنشاء اتصالات ندٍّ لندّ. معرّف في RFC 3489.
+* **Single-factor authenticator** (مُصادِق أحادي العامل) – آلية للتحقق من أن المستخدم مُصادَق عليه. وينبغي أن تكون إما شيئًا تعرفه (أسرار محفوظة، كلمات مرور، عبارات مرور، أرقام تعريف شخصية)، أو شيئًا أنت عليه (القياسات الحيوية، بصمة الإصبع، مسح الوجه)، أو شيئًا تملكه (رموز OTP، جهاز تشفيري مثل البطاقة الذكية).
+* **Single Sign-on Authentication** (SSO، مصادقة الدخول الموحّد) – يحدث هذا عندما يدخل المستخدم إلى تطبيق واحد فيُسجَّل دخوله تلقائيًا إلى تطبيقات أخرى دون الحاجة إلى إعادة المصادقة. على سبيل المثال، عند الدخول إلى Google، يُسجَّل دخول المستخدم تلقائيًا إلى خدمات Google الأخرى مثل YouTube وGoogle Docs وGmail.
+* **Software bill of materials** (SBOM، قائمة مكوّنات البرمجيات) - قائمة منظّمة وشاملة بجميع المكوّنات والوحدات والمكتبات وأُطر العمل وغيرها من الموارد اللازمة لبناء تطبيق برمجي أو تجميعه.
+* **Software Composition Analysis** (SCA، تحليل تركيب البرمجيات) – مجموعة من التقنيات المصمّمة لتحليل تركيب التطبيق وتبعياته ومكتباته وحُزَمه بحثًا عن ثغرات أمنية في إصدارات مكوّنات معيّنة قيد الاستخدام. ولا ينبغي الخلط بينه وبين تحليل الشيفرة المصدرية الذي يُشار إليه الآن عادةً باسم SAST.
+* **Software development lifecycle** (SDLC، دورة حياة تطوير البرمجيات) – العملية التدريجية التي يُطوَّر بها البرنامج من المتطلبات الأولية إلى النشر والصيانة.
+* **SQL Injection** (SQLi، حقن SQL) – تقنية حقن شيفرة تُستخدم لمهاجمة التطبيقات المعتمدة على البيانات، حيث تُدرج عبارات SQL ضارة في نقطة إدخال.
+* **Stateful Session Mechanism** (آلية الجلسة ذات الحالة) – في آلية الجلسة ذات الحالة، يحتفظ التطبيق بحالة الجلسة في الواجهة الخلفية، وهي تقابل عادةً رمزًا مميزًا للجلسة يُولَّد باستخدام مولّد أعداد شبه عشوائية آمن تشفيريًا (CSPRNG)، ويُصدر للمستخدم النهائي.
+* **Stateless Session Mechanism** (آلية الجلسة عديمة الحالة) – تستخدم آلية الجلسة عديمة الحالة رمزًا مميزًا مكتفيًا بذاته يُمرَّر إلى العملاء، ويحتوي على معلومات الجلسة التي لا تُخزَّن بالضرورة داخل الخدمة التي تستقبل الرمز وتتحقق منه. وفي الواقع، ستحتاج الخدمة إلى الوصول إلى بعض معلومات الجلسة (مثل قائمة إبطال JWT) لتكون قادرة على إنفاذ ضوابط الأمان المطلوبة.
+* **Static application security testing** (SAST، الاختبار الساكن لأمان التطبيقات) – مجموعة من التقنيات المصمّمة لتحليل الشيفرة المصدرية للتطبيق ورمزه البايتي وملفاته الثنائية بحثًا عن ظروف في الكتابة والتصميم تدل على وجود ثغرات أمنية. وتحلّل حلول SAST التطبيق من "الداخل إلى الخارج" وهو في حالة عدم تشغيل.
+* **Threat Modeling** (نمذجة التهديدات) – تقنية تتمثّل في تطوير معماريات أمنية متزايدة الدقة لتحديد عناصر التهديد ومناطق الأمان وضوابط الأمان والأصول التقنية والتجارية المهمة.
+* **Time-of-check to time-of-use** (TOCTOU، من وقت الفحص إلى وقت الاستخدام) – حالة يفحص فيها التطبيق حالة مورد قبل استخدامه، لكن حالة المورد يمكن أن تتغيّر بين الفحص والاستخدام. وقد يُبطل ذلك نتائج الفحص ويؤدي إلى وضع ينفّذ فيه التطبيق إجراءات غير صحيحة بسبب عدم تطابق الحالة.
+* **Time based One-time Passwords** (TOTPs، كلمات المرور لمرة واحدة المعتمدة على الوقت) - طريقة لتوليد كلمة مرور لمرة واحدة يكون فيها الوقت الحالي جزءًا من الخوارزمية المستخدمة لتوليد كلمة المرور.
+* **TLS client authentication** (مصادقة العميل في TLS)، ويُسمّى أيضًا **Mutual TLS** (mTLS) – في اتصال TLS القياسي، يمكن للعميل استخدام الشهادة التي يوفّرها الخادم للتحقق من هوية الخادم. وعند استخدام مصادقة العميل في TLS، يستخدم العميل أيضًا مفتاحه الخاص وشهادته للسماح للخادم بالتحقق من هوية العميل كذلك.
+* **Transport Layer Security** (TLS، أمان طبقة النقل) – بروتوكولات تشفيرية توفّر أمان الاتصال عبر اتصال شبكي.
+* **Traversal Using Relays around NAT** (TURN) – امتداد لبروتوكول STUN يستخدم خادم TURN كمُرحِّل عندما لا يمكن إنشاء اتصالات ندٍّ لندّ مباشرة. معرّف في RFC 8656.
+* **Trusted execution environment** (TEE، بيئة التنفيذ الموثوقة) - بيئة معالجة معزولة يمكن فيها تنفيذ التطبيقات بأمان بصرف النظر عن بقية النظام.
+* **Trusted Platform Module** (TPM، وحدة النظام الأساسي الموثوق) – نوع من وحدات أمان العتاد (HSM) يكون عادةً مرفقًا بمكوّن عتادي أكبر مثل اللوحة الأم، ويعمل كـ"جذر الثقة" لذلك النظام.
+* **Trusted Service Layer** (طبقة الخدمة الموثوقة) – أي نقطة إنفاذ موثوقة للضوابط، مثل خدمة مصغّرة، أو واجهة برمجة تطبيقات بلا خادم، أو جانب الخادم، أو واجهة برمجة تطبيقات موثوقة على جهاز عميل يمتلك إقلاعًا آمنًا، أو واجهات برمجة تطبيقات لشركاء أو خارجية، وما إلى ذلك. والموثوقية تعني عدم وجود قلق من أن يتمكّن مستخدم غير موثوق من تجاوز الطبقة أو الضوابط المنفَّذة فيها أو تخطّيها.
+* **Uniform Resource Identifier** (URI، معرّف الموارد الموحّد)- سلسلة محارف فريدة تعرّف موردًا، مثل صفحة ويب أو عنوان بريد أو أماكن.
+* **Uniform Resource Locator** (URL، محدّد موقع الموارد الموحّد) – سلسلة تحدّد موقع مورد على الإنترنت.
+* **Universally Unique Identifier** (UUID، المعرّف الفريد عالميًا) – رقم مرجعي فريد يُستخدم كمعرّف في البرمجيات.
+* **Verifier** (المدقّق) – الشخص أو الفريق الذي يراجع تطبيقًا مقابل متطلبات معيار OWASP للتحقق من أمان التطبيقات.
+* **Web Real-Time Communication** (WebRTC، اتصالات الويب في الوقت الحقيقي) – حزمة بروتوكولات وواجهة برمجة تطبيقات ويب مرتبطة بها تُستخدم لنقل تدفقات الوسائط المتعددة في تطبيقات الويب، عادةً في سياق المؤتمرات المرئية. تستند إلى SRTP وSRTCP وDTLS وSDP وSTUN/TURN.
+* **WebSocket over TLS** (WSS) – ممارسة تأمين اتصالات WebSocket عن طريق تشغيل WebSocket فوق بروتوكول TLS.
+* **What You See Is What You Get** (WYSIWYG، ما تراه هو ما تحصل عليه) – نوع من محرّرات المحتوى الغني يُظهر كيف سيبدو المحتوى فعليًا عند عرضه بدلًا من إظهار الشيفرة المستخدمة للتحكّم في العرض.
+* **X.509 Certificate** (شهادة X.509) – شهادة X.509 هي شهادة رقمية تستخدم معيار البنية التحتية للمفتاح العام (PKI) الدولي X.509 المعتمد على نطاق واسع للتحقق من أن مفتاحًا عامًا ينتمي إلى هوية المستخدم أو الحاسوب أو الخدمة الواردة في الشهادة.
+* **XML eXternal Entity** (XXE، كيان XML الخارجي) – نوع من كيانات XML يمكنه الوصول إلى محتوى محلي أو بعيد عبر معرّف نظام معلن. وقد يؤدي ذلك إلى هجمات حقن مختلفة.
diff --git a/5.0/ar/0x91-Appendix-B_References.md b/5.0/ar/0x91-Appendix-B_References.md
new file mode 100644
index 0000000000..ccde6c6cc4
--- /dev/null
+++ b/5.0/ar/0x91-Appendix-B_References.md
@@ -0,0 +1,43 @@
+# الملحق ب: المراجع
+
+من المرجّح أن تكون مشاريع OWASP التالية مفيدة لمستخدمي هذا المعيار ومتبنّيه:
+
+## مشاريع OWASP الأساسية
+
+1. OWASP Top 10 Project: [https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top-ten/)
+2. OWASP Web Security Testing Guide: [https://owasp.org/www-project-web-security-testing-guide/](https://owasp.org/www-project-web-security-testing-guide/)
+3. OWASP Proactive Controls: [https://owasp.org/www-project-proactive-controls/](https://owasp.org/www-project-proactive-controls/)
+4. OWASP Software Assurance Maturity Model (SAMM): [https://owasp.org/www-project-samm/](https://owasp.org/www-project-samm/)
+5. OWASP Secure Headers Project: [https://owasp.org/www-project-secure-headers/](https://owasp.org/www-project-secure-headers/)
+
+## مشروع سلسلة الأوراق المرجعية من OWASP
+
+[هذا المشروع](https://owasp.org/www-project-cheat-sheets/) يضم عدة أوراق مرجعية ذات صلة بمواضيع مختلفة في معيار التحقق من أمان التطبيقات.
+
+وهناك تخطيط إلى معيار التحقق من أمان التطبيقات يمكن الاطلاع عليه هنا: [https://cheatsheetseries.owasp.org/IndexASVS.html](https://cheatsheetseries.owasp.org/IndexASVS.html)
+
+## المشاريع المتعلقة بأمان الأجهزة المحمولة
+
+1. OWASP Mobile Security Project: [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/)
+2. OWASP Mobile Top 10 Risks: [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/)
+3. OWASP Mobile Security Testing Guide and Mobile Application Security Verification Standard: [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/)
+
+## مشاريع OWASP المتعلقة بإنترنت الأشياء
+
+1. OWASP Internet of Things Project: [https://owasp.org/www-project-internet-of-things/](https://owasp.org/www-project-internet-of-things/)
+
+## مشاريع OWASP الخاصة بالحوسبة بلا خادم
+
+1. OWASP Serverless Project: [https://owasp.org/www-project-serverless-top-10/](https://owasp.org/www-project-serverless-top-10/)
+
+## أخرى
+
+وبالمثل، من المرجّح أن تكون المواقع التالية مفيدة لمستخدمي هذا المعيار ومتبنّيه
+
+1. SecLists Github: [https://github.com/danielmiessler/SecLists](https://github.com/danielmiessler/SecLists)
+2. MITRE Common Weakness Enumeration: [https://cwe.mitre.org/](https://cwe.mitre.org/)
+3. PCI Security Standards Council: [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/)
+4. PCI Data Security Standard (DSS) v3.2.1 Requirements and Security Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf)
+5. PCI Software Security Framework - Secure Software Requirements and Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf)
+6. PCI Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf)
+7. OWASP ASVS 4.0 Testing Guide [https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide](https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide)
diff --git a/5.0/ar/0x92-Appendix-C_Cryptography.md b/5.0/ar/0x92-Appendix-C_Cryptography.md
new file mode 100644
index 0000000000..be5bb249fc
--- /dev/null
+++ b/5.0/ar/0x92-Appendix-C_Cryptography.md
@@ -0,0 +1,311 @@
+# الملحق ج: معايير التشفير
+
+يتجاوز فصل "التشفير" مجرّد تحديد الممارسات الفضلى. فهو يهدف إلى تعزيز فهم مبادئ التشفير والتشجيع على تبنّي طرائق أمنية أكثر صمودًا وحداثة. ويوفّر هذا الملحق معلومات تقنية مفصّلة عن كل متطلب، مكمّلًا المعايير الشاملة المبيّنة في فصل "التشفير".
+
+يحدّد هذا الملحق مستوى الاعتماد لآليات التشفير المختلفة:
+
+* الآليات المعتمدة (A) يمكن استخدامها في التطبيقات.
+* الآليات القديمة (L) لا ينبغي استخدامها في التطبيقات لكن قد تبقى مستخدمة للتوافق مع التطبيقات أو الشيفرات القديمة القائمة فقط. ومع أن استخدام هذه الآليات لا يُعدّ حاليًا ثغرة في حد ذاته، فينبغي استبدالها بآليات أكثر أمانًا وأصمد للمستقبل في أسرع وقت ممكن.
+* الآليات الممنوعة (D) يجب ألا تُستخدم لأنها تُعدّ حاليًا مكسورة أو لا توفّر أمانًا كافيًا.
+
+وقد تُتجاوز هذه القائمة في سياق تطبيق معيّن لأسباب متنوعة منها:
+
+* التطورات الجديدة في مجال التشفير؛
+* الامتثال للتنظيمات.
+
+## جرد التشفير وتوثيقه
+
+يوفّر هذا القسم معلومات إضافية
+عن V11.1 جرد التشفير وتوثيقه.
+
+من المهم التأكد من أن جميع الأصول التشفيرية، مثل الخوارزميات والمفاتيح والشهادات، تُستكشف وتُجرد وتُقيَّم بانتظام. وبالنسبة إلى المستوى 3، ينبغي أن يشمل ذلك استخدام الفحص الساكن والديناميكي لاستكشاف استخدام التشفير في التطبيق. وقد تساعد أدوات مثل SAST وDAST في ذلك، لكن من المحتمل أن تكون هناك حاجة إلى أدوات مخصّصة للحصول على تغطية أشمل. ومن أمثلة الأدوات المجانية:
+
+* [CryptoMon - Network Cryptography Monitor - using eBPF, written in python](https://github.com/Santandersecurityresearch/CryptoMon)
+* [Cryptobom Forge Tool: Generating Comprehensive CBOMs from CodeQL Outputs](https://github.com/Santandersecurityresearch/cryptobom-forge)
+
+## القوى المكافئة لمعاملات التشفير
+
+ترد القوى الأمنية النسبية لأنظمة تشفير متنوعة في هذا الجدول (من [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)، ص. 71):
+
+| القوة الأمنية | خوارزميات المفتاح المتناظر | الحقل المنتهي | تحليل الأعداد الصحيحة إلى عوامل | المنحنى الإهليلجي |
+|--|--|--|--|--|
+| <= 80 | 2TDEA | L = 1024 <br> N = 160 | k = 1024 | f = 160-223 |
+| 112 | 3TDEA   | L = 2048 <br> N = 224 | k = 2048 | f = 224-255 |
+| 128 | AES-128 | L = 3072 <br> N = 256 | k = 3072 | f = 256-383 |
+| 192 | AES-192 | L = 7680 <br> N = 384 | k = 7680 | f = 384-511 |
+| 256 | AES-256 | L = 15360 <br> N = 512 | k = 15360 | f = 512+ |
+
+أمثلة على التطبيقات:
+
+* تشفير الحقل المنتهي: DSA وFFDH وMQV
+* تشفير تحليل الأعداد الصحيحة إلى عوامل: RSA
+* تشفير المنحنيات الإهليلجية: ECDSA وEdDSA وECDH وMQV
+
+ملاحظة: يفترض هذا القسم عدم وجود حاسوب كمومي؛ فإذا وُجد مثل هذا الحاسوب، فلن تبقى التقديرات في الأعمدة الثلاثة الأخيرة صالحة.
+
+## القيم العشوائية
+
+يوفّر هذا القسم معلومات إضافية
+عن V11.5 القيم العشوائية.
+
+| الاسم | الإصدار/المرجع | ملاحظات | الحالة |
+|:---|:----|:----|:-:|
+| `/dev/random` | Linux 4.8+ [(Oct 2016)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3), also found in iOS, Android, and other Linux-based POSIX operating systems. Based on [RFC7539](https://datatracker.ietf.org/doc/html/rfc7539) | Utilizing ChaCha20 stream. Found in iOS [`SecRandomCopyBytes`](https://developer.apple.com/documentation/security/secrandomcopybytes(_:_:_:)?language=objc) and Android [`Secure Random`](https://developer.android.com/reference/java/security/SecureRandom) with the correct settings provided to each. | A |
+| `/dev/urandom` | Linux kernel's special file for providing random data | Provides high-quality, entropy sources from hardware randomness | A |
+| `AES-CTR-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | As used in common implementations, such as [Windows CNG API `BCryptGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom) set by [`BCRYPT_RNG_ALGORITHM`](https://learn.microsoft.com/en-us/windows/win32/seccng/cng-algorithm-identifiers). | A |
+| `HMAC-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A |
+| `Hash-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A |
+| `getentropy()` | [OpenBSD](https://man.openbsd.org/getentropy.2), available in [Linux glibc 2.25+](https://man7.org/linux/man-pages/man3/getentropy.3.html) and [macOS 10.12+](https://support.apple.com/en-gb/guide/security/seca0c73a75b/web) | Provides secure random bytes directly from the kernel's entropy source with a straightforward and minimal API. It’s more modern and avoids pitfalls associated with older APIs. | A |
+
+يجب أن تكون دالة التلبيد الأساسية المستخدمة مع HMAC-DRBG أو Hash-DRBG معتمدة لهذا الاستخدام.
+
+## خوارزميات التشفير
+
+يوفّر هذا القسم معلومات إضافية
+عن V11.3 خوارزميات التشفير.
+
+خوارزميات التشفير المعتمدة مدرجة بترتيب التفضيل.
+
+| خوارزميات المفتاح المتناظر | المرجع | الحالة |
+| ------ | ------ |:-:|
+| AES-256 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | A |
+| Salsa20 | [Salsa 20 specification](https://cr.yp.to/snuffle/spec.pdf) | A |
+| XChaCha20 | [XChaCha20 Draft](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xchacha-03) | A |
+| XSalsa20 | [Extending the Salsa20 nonce](https://cr.yp.to/snuffle/xsalsa-20110204.pdf) | A |
+| ChaCha20 | [RFC 8439](https://www.rfc-editor.org/info/rfc8439) | A |
+| AES-192 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | A |
+| AES-128 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | L |
+| 2TDEA | | D |
+| TDEA (3DES/3DEA) | | D |
+| IDEA | | D |
+| RC4 | | D |
+| Blowfish| | D |
+| ARC4 | | D |
+| DES | | D |
+
+### أنماط تشفير AES
+
+يمكن استخدام تشفيرات الكتل، مثل AES، مع أنماط تشغيل مختلفة. وكثير من أنماط التشغيل، مثل كتاب الشيفرة الإلكتروني (ECB)، غير آمن ويجب ألا يُستخدم. أما نمط جالوا/العدّاد (GCM) ونمط العدّاد مع رمز مصادقة رسالة تسلسل كتل التشفير (CCM) فيوفّران تشفيرًا مصادَقًا عليه وينبغي استخدامهما في التطبيقات الحديثة.
+
+الأنماط المعتمدة مدرجة بترتيب التفضيل.
+
+| النمط | مصادَق عليه | المرجع | الحالة | القيد |
+|--|--|--|:-:|--|
+| GCM | Yes | [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | |
+| CCM | Yes | [NIST SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | |
+| CBC | No | [NIST SP 800-38A](https://csrc.nist.gov/pubs/sp/800/38/a/final) | L | |
+| CCM-8 | Yes | | D | |
+| ECB | No | | D | |
+| CFB | No | | D | |
+| OFB | No | | D | |
+| CTR | No | | D | |
+
+ملاحظات:
+
+* يجب أن تكون جميع الرسائل المشفّرة مصادَقًا عليها. ولأي استخدام لنمط CBC يجب أن تكون هناك خوارزمية MAC تلبيدية مرتبطة به للتحقق من الرسالة. وعمومًا، يجب تطبيق ذلك بطريقة التشفير ثم التلبيد (لكن TLS 1.2 يستخدم التلبيد ثم التشفير بدلًا من ذلك). وإذا لم يكن من الممكن ضمان ذلك، فيجب ألا يُستخدم CBC. والتطبيق الوحيد الذي يُسمح فيه بالتشفير دون خوارزمية MAC هو تشفير الأقراص.
+* في حال استخدام CBC، يجب ضمان أن التحقق من الحشو يُنفَّذ في زمن ثابت.
+* عند استخدام CCM-8، لا تمتلك وسيمة MAC سوى 64 بتًا من الأمان. وهذا لا يتوافق مع المتطلب 6.2.9 الذي يقتضي 128 بتًا من الأمان على الأقل.
+* يُعدّ تشفير الأقراص خارج نطاق معيار التحقق من أمان التطبيقات. ولذلك لا يُدرج هذا الملحق أي طريقة معتمدة لتشفير الأقراص. ولهذا الاستخدام، يُقبل عادةً التشفير دون مصادقة وتُستخدم عادةً الأنماط XTS وXEX وLRW.
+
+### تغليف المفاتيح
+
+تغليف المفاتيح التشفيري (وما يقابله من فك التغليف) طريقة لحماية مفتاح قائم بتغليفه (أي تطويقه) باستخدام آلية تشفير إضافية بحيث لا يكون المفتاح الأصلي مكشوفًا بجلاء، مثلًا أثناء النقل. ويُشار إلى هذا المفتاح الإضافي المستخدم لحماية المفتاح الأصلي بمفتاح التغليف.
+
+وقد تُنفَّذ هذه العملية عندما يكون من المرغوب حماية المفاتيح في أماكن تُعدّ غير موثوقة، أو إرسال مفاتيح حساسة عبر شبكات غير موثوقة أو داخل التطبيقات.
+لكن ينبغي إيلاء اعتبار جدّي لفهم طبيعة المفتاح الأصلي (مثل هويته والغرض منه) قبل الإقدام على إجراء تغليف/فك تغليف، إذ قد تكون لذلك تبعات على الأنظمة أو التطبيقات المصدر والهدف على حد سواء من حيث الأمان، وخصوصًا الامتثال، الذي قد يشمل مسارات تدقيق لوظيفة المفتاح (مثل التوقيع) وكذلك التخزين الملائم للمفاتيح.
+
+وعلى وجه التحديد، يجب استخدام AES-256 لتغليف المفاتيح، وفقًا لـ [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) ومع مراعاة الأحكام الاستشرافية ضد التهديد الكمومي. وأنماط التشفير التي تستخدم AES هي التالية، بترتيب التفضيل:
+
+| تغليف المفاتيح | المرجع | الحالة |
+|--|--|:-:|
+| KW | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A |
+| KWP | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A |
+
+ويمكن استخدام AES-192 وAES-128 إذا اقتضت حالة الاستخدام ذلك، لكن يجب توثيق مبرّر ذلك في جرد التشفير الخاص بالجهة.
+
+### التشفير المصادَق عليه
+
+باستثناء تشفير الأقراص، يجب حماية البيانات المشفّرة من التعديل غير المصرَّح به باستخدام صورة ما من مخططات التشفير المصادَق عليه (AE)، وعادةً باستخدام مخطط التشفير المصادَق عليه مع البيانات المرتبطة (AEAD).
+
+وينبغي للتطبيق أن يستخدم مخطط AEAD معتمدًا تفضيلًا. وقد يجمع بدلًا من ذلك بين مخطط تشفير معتمد وخوارزمية MAC معتمدة ببنية التشفير ثم MAC.
+
+ولا يزال التلبيد ثم التشفير مسموحًا به للتوافق مع التطبيقات القديمة. وهو مستخدم في TLS v1.2 مع مجموعات التشفير القديمة.
+
+| آلية AEAD | المرجع | الحالة |
+|---|---------|:-:|
+|AES-GCM | [SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A |
+|AES-CCM  | [SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A |
+|ChaCha-Poly1305 | [RFC 7539](https://datatracker.ietf.org/doc/html/rfc7539) | A |
+|AEGIS-256 | [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A |
+|AEGIS-128 | [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A |
+|AEGIS-128L| [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A |
+|Encrypt-then-MAC | | A |
+|MAC-then-encrypt | | L |
+
+## دوالّ التلبيد
+
+يوفّر هذا القسم معلومات إضافية
+عن V11.4 التلبيد والدوالّ المبنية على التلبيد.
+
+### دوالّ التلبيد لحالات الاستخدام العامة
+
+يسرد الجدول التالي دوالّ التلبيد المعتمدة في حالات الاستخدام التشفيري العامة مثل التوقيعات الرقمية:
+
+* توفّر دوالّ التلبيد المعتمدة مقاومة قوية للتصادم وهي ملائمة للتطبيقات عالية الأمان.
+* توفّر بعض هذه الخوارزميات مقاومة قوية للهجمات عند استخدامها مع إدارة سليمة لمفاتيح التشفير، ولذلك فهي معتمدة إضافةً إلى ذلك لدوالّ HMAC وKDF وRBG.
+* دوالّ التلبيد التي يقل طول مخرَجها عن 254 بتًا لا تمتلك مقاومة كافية للتصادم ويجب ألا تُستخدم للتوقيع الرقمي أو غيره من التطبيقات التي تقتضي مقاومة التصادم. أما للاستخدامات الأخرى، فقد تُستخدم للتوافق والتحقق مع الأنظمة القديمة فقط، لكن يجب ألا تُستخدم في التصاميم الجديدة.
+
+| دالة التلبيد | المرجع | الحالة | القيود |
+| ------ | ----------- |:-:| ---------- |
+| SHA3-512 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | |
+| SHA-512 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | |
+| SHA3-384 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | |
+| SHA-384 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | |
+| SHA3-256 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | |
+| SHA-512/256 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | |
+| SHA-256 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | |
+| SHAKE256 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | |
+| BLAKE2s | [BLAKE2: simpler, smaller, fast as MD5](https://eprint.iacr.org/2013/322) | A | |
+| BLAKE2b | [BLAKE2: simpler, smaller, fast as MD5](https://eprint.iacr.org/2013/322) | A | |
+| BLAKE3 | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf) | A | |
+| SHA-224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures |
+| SHA-512/224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures |
+| SHA3-224 | [FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures |
+| SHA-1 | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | L | Not suitable for HMAC, KDF, RBG, digital signatures |
+| CRC (any length) |  | D |  |
+| MD4 | [RFC 1320](https://www.rfc-editor.org/info/rfc1320) | D | |
+| MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | |
+
+### دوالّ التلبيد لتخزين كلمات المرور
+
+لتلبيد كلمات المرور بأمان، يجب استخدام دوالّ تلبيد مخصّصة. وتخفّف خوارزميات التلبيد البطيء هذه من هجمات القوة الغاشمة وهجمات القواميس بزيادة الصعوبة الحسابية لكسر كلمات المرور.
+
+| KDF        | المرجع | المعاملات المطلوبة | الحالة |
+| ---------- | --------- | ------------ |:-:|
+| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m >= 47104 (46 MiB), p = 1 | A |
+|          |                                                     | t = 2: m >= 19456 (19 MiB), p = 1 | A |
+|          |                                                     | t >= 3: m >= 12288 (12 MiB), p = 1 | A |
+| scrypt   | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N >= 2^17 (128 MiB), r = 8 | A |
+|          |                                                     | p = 2: N >= 2^16 (64 MiB), r = 8  | A |
+|          |                                                     | p >= 3: N >= 2^15 (32 MiB), r = 8  | A |
+| bcrypt | [A Future-Adaptable Password Scheme](https://www.researchgate.net/publication/2519476_A_Future-Adaptable_Password_Scheme) | cost >= 10 | A |
+| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 210,000 | A |
+| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 600,000 | A |
+| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 1,300,000 | L |
+
+ويمكن استخدام دوالّ اشتقاق المفاتيح المعتمدة القائمة على كلمات المرور لتخزين كلمات المرور.
+
+## دوالّ اشتقاق المفاتيح (KDFs)
+
+### دوالّ اشتقاق المفاتيح العامة
+
+| KDF              | المرجع                                                                                        | الحالة |
+| ---------------- | -------- |:-:|
+| HKDF             | [RFC 5869](https://www.rfc-editor.org/info/rfc5869)                                           | A      |
+| TLS 1.2 PRF      | [RFC 5248](https://www.rfc-editor.org/info/rfc5248)                                           | L      |
+| MD5-based KDFs   | [RFC 1321](https://www.rfc-editor.org/info/rfc1321)                                           | D      |
+| SHA-1-based KDFs | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | D      |
+
+### دوالّ اشتقاق المفاتيح القائمة على كلمات المرور
+
+| KDF        | المرجع | المعاملات المطلوبة | الحالة |
+| ---------- | --------- | ------------ |:-:|
+| argon2id   | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m >= 47104 (46 MiB), p = 1 | A |
+|            |                                                     | t = 2: m >= 19456 (19 MiB), p = 1 | A |
+| scrypt     | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N >= 2^17 (128 MiB), r = 8 | A |
+|            |                                                     | p = 2: N >= 2^16 (64 MiB), r = 8  | A |
+|            |                                                     | p >= 3: N >= 2^15 (32 MiB), r = 8  | A |
+| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 210,000 | A |
+| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 600,000 | A |
+| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 1,300,000 | L |
+
+## آليات تبادل المفاتيح
+
+يوفّر هذا القسم معلومات إضافية
+عن V11.6 تشفير المفتاح العام.
+
+### مخططات تبادل المفاتيح
+
+يجب ضمان قوة أمنية قدرها 112 بتًا أو أكثر لجميع مخططات تبادل المفاتيح، ويجب أن يتّبع تنفيذها اختيارات المعاملات الواردة في الجدول التالي.
+
+| المخطط | معاملات المجال | السرّية التامة للتوجيه |الحالة |
+|--|--|--|:-:|
+| Finite Field Diffie-Hellman (FFDH) | L >= 3072 & N >= 256 | Yes | A |
+| Elliptic Curve Diffie-Hellman (ECDH) | f >= 256-383 | Yes | A |
+| Encrypted key transport with RSA-PKCS#1 v1.5 | | No | D |
+
+حيث المعاملات التالية هي:
+
+* k هو حجم المفتاح لمفاتيح RSA.
+* L هو حجم المفتاح العام وN هو حجم المفتاح الخاص لتشفير الحقل المنتهي.
+* f هو نطاق أحجام المفاتيح لتشفير المنحنيات الإهليلجية (ECC).
+
+ويجب ألا يستخدم أي تنفيذ جديد أي مخطط غير متوافق مع [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) و[B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) و[NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final). وعلى وجه التحديد، يجب ألا يُستخدم IKEv1 في الإنتاج.
+
+### مجموعات ديفي-هيلمان
+
+المجموعات التالية معتمدة لتنفيذات تبادل المفاتيح بطريقة ديفي-هيلمان. والقوى الأمنية موثّقة في [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final)، الملحق د، وفي [NIST SP 800-57 Part 1 Rev.5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final).
+
+| المجموعة         | الحالة |
+|------------------|:------:|
+| P-224, secp224r1 | A      |
+| P-256, secp256r1 | A      |
+| P-384, secp384r1 | A      |
+| P-521, secp521r1 | A      |
+| K-233, sect233k1 | A      |
+| K-283, sect283k1 | A      |
+| K-409, sect409k1 | A      |
+| K-571, sect571k1 | A      |
+| B-233, sect233r1 | A      |
+| B-283, sect283r1 | A      |
+| B-409, sect409r1 | A      |
+| B-571, sect571r1 | A      |
+| Curve448         | A      |
+| Curve25519       | A      |
+| MODP-2048        | A      |
+| MODP-3072        | A      |
+| MODP-4096        | A      |
+| MODP-6144        | A      |
+| MODP-8192        | A      |
+| ffdhe2048        | A      |
+| ffdhe3072        | A      |
+| ffdhe4096        | A      |
+| ffdhe6144        | A      |
+| ffdhe8192        | A      |
+
+## رموز مصادقة الرسائل (MAC)
+
+رموز مصادقة الرسائل (MACs) بِنى تشفيرية تُستخدم للتحقق من سلامة الرسالة وأصالتها. ويأخذ رمز MAC رسالة ومفتاحًا سرّيًا كمدخلات وينتج وسيمة ثابتة الحجم (قيمة MAC). وتُستخدم رموز MAC على نطاق واسع في بروتوكولات الاتصال الآمن (مثل TLS/SSL) لضمان أن الرسائل المتبادلة بين الأطراف أصيلة وسليمة.
+
+| خوارزمية MAC | المرجع                                                                                    | الحالة |
+| ----------    | --------------- |:-:|
+| HMAC-SHA-256  | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A |
+| HMAC-SHA-384  | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A |
+| HMAC-SHA-512  | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A |
+| KMAC128       | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final)                             | A |
+| KMAC256       | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final)                             | A |
+| BLAKE3 (keyed_hash mode) | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf)  | A |
+| AES-CMAC      | [RFC 4493](https://datatracker.ietf.org/doc/html/rfc4493) & [NIST SP 800-38B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf) | A |
+| AES-GMAC      | [NIST SP 800-38D](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf)            | A |
+| Poly1305-AES  | [The Poly1305-AES message-authentication code](https://cr.yp.to/mac/poly1305-20050329.pdf)                  | A |
+| HMAC-SHA-1    | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | L |
+| HMAC-MD5      | [RFC 1321](https://www.rfc-editor.org/info/rfc1321)                                | D      |
+
+## التوقيعات الرقمية
+
+يجب أن تستخدم مخططات التوقيع أحجام مفاتيح ومعاملات معتمدة وفق [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final).
+
+| خوارزمية التوقيع               | المرجع                                                     | الحالة |
+| ------------------------------ | ---------------------------------------------              | :-:    |
+| EdDSA (Ed25519, Ed448)         | [RFC 8032](https://www.rfc-editor.org/info/rfc8032)        | A      |
+| XEdDSA (Curve25519, Curve448)  | [XEdDSA](https://signal.org/docs/specifications/xeddsa/)   | A      |
+| ECDSA (P-256, P-384, P-521)    | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-5/final)  | A      |
+| RSA-RSSA-PSS                   | [RFC 8017](https://www.rfc-editor.org/info/rfc8017)        | A      |
+| RSA-SSA-PKCS#1 v1.5            | [RFC 8017](https://www.rfc-editor.org/info/rfc8017)        | D      |
+| DSA (any key size)             | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-4/final)  | D      |
+
+## معايير التشفير ما بعد الكمومي
+
+يجب أن تكون تنفيذات التشفير ما بعد الكمومي متوافقة مع [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd) إذ لا يوجد بعد سوى قدر ضئيل من الشيفرات المحصّنة أو المراجع التنفيذية. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
+
+طريقة اتفاق المفاتيح الهجينة ما بعد الكمومية المقترحة [mlkem768x25519](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/) لـ TLS مدعومة من متصفحات رئيسية مثل [Firefox release 132](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) و[Chrome release 131](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html). ويمكن استخدامها في بيئات الاختبار التشفيري أو عند توافرها في مكتبات معتمدة صناعيًا أو حكوميًا.
diff --git a/5.0/ar/0x93-Appendix-D_Recommendations.md b/5.0/ar/0x93-Appendix-D_Recommendations.md
new file mode 100644
index 0000000000..1abdd02fc8
--- /dev/null
+++ b/5.0/ar/0x93-Appendix-D_Recommendations.md
@@ -0,0 +1,49 @@
+# الملحق د: التوصيات
+
+## مقدمة
+
+أثناء إعداد الإصدار 5.0 من معيار التحقق من أمان التطبيقات (ASVS)، اتضح أن هناك عددًا من البنود القائمة والمقترحة حديثًا التي لا ينبغي إدراجها كمتطلبات في الإصدار 5.0. وقد يكون ذلك لأنها لم تكن داخل نطاق معيار التحقق من أمان التطبيقات وفق تعريف الإصدار 5.0، أو بدلًا من ذلك لأنه رُئي أنها، وإن كانت فكرة جيدة، لا يمكن جعلها إلزامية.
+
+ولعدم الرغبة في فقدان كل هذه البنود تمامًا، فقد ضُمّ بعضها في هذا الملحق.
+
+## آليات موصى بها وداخلة في النطاق
+
+البنود التالية داخلة في نطاق معيار التحقق من أمان التطبيقات. ولا ينبغي جعلها إلزامية، لكن يُوصى بقوة بالنظر فيها كجزء من تطبيق آمن.
+
+* ينبغي توفير مقياس لقوة كلمة المرور لمساعدة المستخدمين على تعيين كلمة مرور أقوى.
+* أنشئ ملف security.txt متاحًا للعموم في الجذر أو في مجلد .well-known الخاص بالتطبيق، يحدّد بوضوح رابطًا أو عنوان بريد إلكتروني ليتصل الناس بالمالكين بشأن المشكلات الأمنية.
+* ينبغي إنفاذ التحقق من صحة المدخلات من جانب العميل إضافةً إلى التحقق في طبقة خدمة موثوقة، إذ يوفّر ذلك فرصة جيدة لاكتشاف تجاوز أحدهم للضوابط من جانب العميل في محاولة لمهاجمة التطبيق.
+* امنع ظهور الصفحات الحسّاسة والتي يمكن الوصول إليها عن غير قصد في محركات البحث باستخدام ملف robots.txt أو ترويسة الاستجابة X-Robots-Tag أو وسم robots في html.
+* عند استخدام GraphQL، نفّذ منطق التخويل في طبقة منطق العمل بدلًا من طبقة GraphQL أو المُحلِّل، لتجنّب الحاجة إلى معالجة التخويل في كل واجهة منفصلة.
+
+المراجع:
+
+* [More information on security.txt including a link to the RFC](https://securitytxt.org/)
+
+## مبادئ أمان البرمجيات
+
+كانت البنود التالية موجودة سابقًا في معيار التحقق من أمان التطبيقات لكنها ليست متطلبات في الحقيقة. بل هي مبادئ ينبغي مراعاتها عند تنفيذ ضوابط الأمان، والتي يؤدي اتباعها إلى ضوابط أكثر متانة. وتشمل ما يلي:
+
+* ينبغي أن تكون ضوابط الأمان مركزية وبسيطة (اقتصاد التصميم) وآمنة على نحو قابل للتحقق وقابلة لإعادة الاستخدام. وهذا ينبغي أن يمنع الضوابط المكرّرة أو المفقودة أو غير الفعّالة.
+* استخدم، حيثما أمكن، تنفيذات ضوابط أمان مكتوبة مسبقًا ومدروسة جيدًا بدلًا من الاعتماد على تنفيذ الضوابط من الصفر.
+* من الأفضل استخدام آلية واحدة للتحكم في الوصول للوصول إلى البيانات والموارد المحمية. وينبغي أن تمرّ جميع الطلبات عبر هذه الآلية الواحدة لتجنّب النسخ واللصق أو المسارات البديلة غير الآمنة.
+* يُعدّ التحكم في الوصول المبني على السمات أو الميزات نمطًا موصى به، تتحقق فيه الشيفرة من تخويل المستخدم لميزة أو عنصر بيانات بدلًا من التحقق من دوره فقط. ومع ذلك ينبغي أن تُخصَّص الصلاحيات باستخدام الأدوار.
+
+## عمليات أمان البرمجيات
+
+هناك عدد من العمليات الأمنية التي أُزيلت من معيار التحقق من أمان التطبيقات 5.0 لكنها لا تزال فكرة جيدة. وقد يكون مشروع OWASP SAMM مصدرًا جيدًا لمعرفة كيفية تنفيذ هذه العمليات بفعالية. وتشمل البنود التي كانت موجودة سابقًا في معيار التحقق من أمان التطبيقات ما يلي:
+
+* تحقق من استخدام دورة حياة آمنة لتطوير البرمجيات تعالج الأمان في جميع مراحل التطوير.
+* تحقق من استخدام نمذجة التهديدات لكل تغيير في التصميم أو تخطيط لدورة عمل، لتحديد التهديدات والتخطيط للتدابير المضادة وتيسير الاستجابات الملائمة للمخاطر وتوجيه اختبار الأمان.
+* تحقق من أن جميع قصص المستخدم والميزات تتضمّن قيودًا أمنية وظيفية، مثل "كمستخدم، ينبغي أن أكون قادرًا على عرض ملفي الشخصي وتحريره. وينبغي ألا أكون قادرًا على عرض ملف أي شخص آخر أو تحريره"
+* تحقق من توافر قائمة تحقق للبرمجة الآمنة أو متطلبات أمنية أو دليل أو سياسة لجميع المطوّرين والمختبرين.
+* تحقق من وجود عملية مستمرة للتأكد من أن الشيفرة المصدرية للتطبيق خالية من الأبواب الخلفية والشيفرة الضارة (مثل هجمات السلامي والقنابل المنطقية والقنابل الزمنية) والميزات غير الموثّقة أو المخفية (مثل بيض الفصح وأدوات التنقيح غير الآمنة). والامتثال لهذا القسم غير ممكن دون وصول كامل إلى الشيفرة المصدرية، بما في ذلك مكتبات الأطراف الثالثة، ولذلك فهو على الأرجح مناسب فقط للتطبيقات التي تتطلّب أعلى مستويات الأمان.
+* تحقق من وجود آليات لكشف انحراف التكوين في البيئات المنشورة والاستجابة له. وقد يشمل ذلك استخدام بنية تحتية غير قابلة للتغيير أو إعادة نشر مؤتمتة من خط أساس آمن أو أدوات لكشف الانحراف تقارن الحالة الراهنة بالتكوينات المعتمدة.
+* تحقق من إجراء تحصين التكوين على جميع منتجات ومكتبات وأُطر وخدمات الأطراف الثالثة وفقًا لتوصيات كل منها.
+
+المراجع:
+
+* [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)
+* [OWASP Threat modeling](https://owasp.org/www-community/Application_Threat_Modeling)
+* [OWASP Software Assurance Maturity Model Project](https://owasp.org/www-project-samm/)
+* [Microsoft SDL](https://www.microsoft.com/en-us/securityengineering/sdl/)
diff --git a/5.0/ar/0x94-Appendix-E_Contributors.md b/5.0/ar/0x94-Appendix-E_Contributors.md
new file mode 100644
index 0000000000..e77eb82702
--- /dev/null
+++ b/5.0/ar/0x94-Appendix-E_Contributors.md
@@ -0,0 +1,71 @@
+# الملحق هـ - المساهمون
+
+نعرب عن امتناننا لإسهامات الأشخاص التالية أسماؤهم، الذين علّقوا أو فتحوا طلبات دمج منذ إصدار معيار التحقق من أمان التطبيقات 4.0.0.
+
+وإذا كنت على علم بأي أخطاء أو كنت ترغب في ظهور اسمك بصورة مختلفة، فيُرجى إخبارنا.
+
+| | | | |
+|---|---|---|---|
+| Johan Sydseter ([sydseter](https://github.com/sydseter)) | luis servin ([lfservin](https://github.com/lfservin)) | Oleksii Dovydkov ([oleksiidov](https://github.com/oleksiidov)) | IZUKA Masahiro ([maizuka](https://github.com/maizuka))  |
+| James Sulinski ([jsulinski](https://github.com/jsulinski)) | Eli Saad ([ThunderSon](https://github.com/ThunderSon)) | [kkshitish9](https://github.com/kkshitish9) | Andrew van der Stock ([vanderaj](https://github.com/vanderaj))  |
+| Rick M ([kingthorin](https://github.com/kingthorin)) | Bankde Eakasit ([Bankde](https://github.com/Bankde)) | Michael Gargiullo ([mgargiullo](https://github.com/mgargiullo)) | Raphael Dunant ([Racater](https://github.com/Racater))  |
+| Cesar Kohl ([cesarkohl](https://github.com/cesarkohl)) | [inaz0](https://github.com/inaz0) | Joerg Bruenner ([JoergBruenner](https://github.com/JoergBruenner)) | David Deatherage ([securitydave](https://github.com/securitydave))  |
+| John Carroll  ([yosignals](https://github.com/yosignals)) | Jim Fenton ([jimfenton](https://github.com/jimfenton)) | Matteo Pace ([M4tteoP](https://github.com/M4tteoP)) | Sebastien gioria ([SPoint42](https://github.com/SPoint42))  |
+| Steven van der Baan ([vdbaan](https://github.com/vdbaan)) | Jeremy Bonghwan Choi ([jeremychoi](https://github.com/jeremychoi)) | [craig-shony](https://github.com/craig-shony) | Riccardo Sirigu ([ricsirigu](https://github.com/ricsirigu))  |
+| Tomasz Wrobel ([tw2as](https://github.com/tw2as)) | Alena Dubeshko ([belalena](https://github.com/belalena)) | Rafael Green ([RafaelGreen1](https://github.com/RafaelGreen1)) | [mjang-cobalt](https://github.com/mjang-cobalt)  |
+| [clallier94](https://github.com/clallier94) | Kevin W. Wall ([kwwall](https://github.com/kwwall)) | Jordan Sherman ([jsherm-fwdsec](https://github.com/jsherm-fwdsec) / [deleterepo](https://github.com/deleterepo)) | Ingo Rauner ([ingo-rauner](https://github.com/ingo-rauner))  |
+| Dirk Wetter ([drwetter](https://github.com/drwetter)) | Moshe Zioni ([moshe-apiiro](https://github.com/moshe-apiiro)) | Patrick Dwyer ([coderpatros](https://github.com/coderpatros)) | David Clarke ([davidclarke-au](https://github.com/davidclarke-au))  |
+| Takaharu Ogasa ([takaharuogasa](https://github.com/takaharuogasa)) | Arkadii Yakovets ([arkid15r](https://github.com/arkid15r)) | Motoyasu Saburi ([motoyasu-saburi](https://github.com/motoyasu-saburi)) | [leirn](https://github.com/leirn)  |
+| [wet-certitude](https://github.com/wet-certitude) | [timhemel](https://github.com/timhemel) | RL Thornton ([thornshadow99](https://github.com/thornshadow99)) | Thomas Bandt ([aspnetde](https://github.com/aspnetde))  |
+| Roel Storms ([roelstorms](https://github.com/roelstorms)) | Jeroen Willemsen ([commjoen](https://github.com/commjoen)) | [anonymous-31](https://github.com/anonymous-31) | Kamran Saifullah ([deFr0ggy](https://github.com/deFr0ggy))  |
+| Steve Springett ([stevespringett](https://github.com/stevespringett)) | Spyros ([northdpole](https://github.com/northdpole)) | Hans Herrera ([hansphp](https://github.com/hansphp)) | [Marx314](https://github.com/Marx314)  |
+| [CarlosAllendes](https://github.com/CarlosAllendes) | Yonah Russ ([yruss972](https://github.com/yruss972)) | Sander Maijers ([sanmai-NL](https://github.com/sanmai-NL)) | Luboš Bretschneider  ([bretik](https://github.com/bretik))  |
+| Eva Sarafianou ([esarafianou](https://github.com/esarafianou)) | [ataseren](https://github.com/ataseren) | Steve Thomas ([Sc00bz](https://github.com/Sc00bz)) | Dominique RIGHETTO ([righettod](https://github.com/righettod))  |
+| Steven van der Baan ([svdb-ncc](https://github.com/svdb-ncc)) | Michael Vacarella ([Aif4thah](https://github.com/Aif4thah)) | Tonimir Kisasondi ([tkisason](https://github.com/tkisason)) | Stefan Streichsbier ([streichsbaer](https://github.com/streichsbaer))  |
+| [hi-unc1e](https://github.com/hi-unc1e) | sb3k ([starbuck3000](https://github.com/starbuck3000)) | [mario-platt](https://github.com/mario-platt) | Devdatta Akhawe ([devd](https://github.com/devd))  |
+| Michael Gissing ([scolytus](https://github.com/scolytus)) | Jet Anderson ([thatsjet](https://github.com/thatsjet)) | Dave Wichers ([davewichers](https://github.com/davewichers)) | Jonny Schnittger ([JonnySchnittger](https://github.com/JonnySchnittger))  |
+| Silvia Väli ([silviavali](https://github.com/silviavali)) | [jackgates73](https://github.com/jackgates73) | [1songb1rd](https://github.com/1songb1rd) | Timur - ([timurozkul](https://github.com/timurozkul))  |
+| Gareth Heyes ([hackvertor](https://github.com/hackvertor)) | [appills](https://github.com/appills) | [suvikaartinen](https://github.com/suvikaartinen) | chaals ([chaals](https://github.com/chaals))  |
+| DanielPharos ([AtlasHackert](https://github.com/AtlasHackert)) | will Farrell ([willfarrell](https://github.com/willfarrell)) | Alina Vasiljeva ([avasiljeva](https://github.com/avasiljeva)) | Paul McCann ([ismisepaul](https://github.com/ismisepaul))  |
+| Sage ([SajjadPourali](https://github.com/SajjadPourali)) | [rbsec](https://github.com/rbsec) | Benedikt Bauer ([mastacheata](https://github.com/mastacheata)) | James Jardine ([jamesjardine](https://github.com/jamesjardine))  |
+| Mark Burnett ([m8urnett](https://github.com/m8urnett)) | [dschwarz91](https://github.com/dschwarz91) | Cyber-AppSec ([Cyber-AppSec](https://github.com/Cyber-AppSec)) | [Tib3rius](https://github.com/Tib3rius)  |
+| BitnessWise ([bitnesswise](https://github.com/bitnesswise)) | damienbod ([damienbod](https://github.com/damienbod)) | Jared Meit ([jmeit-fwdsec](https://github.com/jmeit-fwdsec)) | Stefan Seelmann ([sseelmann](https://github.com/sseelmann))  |
+| Brendan O'Connor ([ussjoin](https://github.com/ussjoin)) | Andrei Titov ([andrettv](https://github.com/andrettv)) | Hans-Petter Fjeld ([atluxity](https://github.com/atluxity)) | [markehack](https://github.com/markehack)  |
+| Neil Madden ([NeilMadden](https://github.com/NeilMadden)) | Michael Geramb ([mgeramb](https://github.com/mgeramb)) | Osama Elnaggar ([ossie-git](https://github.com/ossie-git)) | [mackowski](https://github.com/mackowski)  |
+| Ravi Balla ([raviballa](https://github.com/raviballa)) | Hazana ([hazanasec](https://github.com/hazanasec)) | David Means ([dmeans82](https://github.com/dmeans82)) | Alexander Stein ([tohch4](https://github.com/tohch4))  |
+| BaeSenseii ([baesenseii](https://github.com/baesenseii)) | Vincent De Schutter ([VincentDS](https://github.com/VincentDS)) | S Bani ([sbani](https://github.com/sbani)) | Mitsuaki Akiyama ([mak1yama](https://github.com/mak1yama))  |
+| Christopher Loessl ([hashier](https://github.com/hashier)) | [victorxm](https://github.com/victorxm) | Michal Rada ([michalradacz](https://github.com/michalradacz)) | Veeresh Devireddy ([drveresh](https://github.com/drveresh))  |
+| [MaknaSEO](https://github.com/MaknaSEO) | [darkzero2022](https://github.com/darkzero2022) | Liam ([LiamDobbelaere](https://github.com/LiamDobbelaere)) | Frank Denis ([jedisct1](https://github.com/jedisct1))  |
+| Otto Sulin ([ottosulin](https://github.com/ottosulin)) | [carllaw6885](https://github.com/carllaw6885) | Anders Johan Holmefjord ([aholmis](https://github.com/aholmis)) | Richard Fritsch ([rfricz](https://github.com/rfricz))  |
+| [mesutgungor](https://github.com/mesutgungor) | Scott Helme ([ScottHelme](https://github.com/ScottHelme)) | Carlo Reggiani ([carloreggiani](https://github.com/carloreggiani)) | Suyash Srivastava ([suyash5053](https://github.com/suyash5053))  |
+| Mark Potter ([markonweb](https://github.com/markonweb)) | Arjan Lamers ([alamers](https://github.com/alamers)) | Gøran Breivik ([gobrtg](https://github.com/gobrtg)) | [flo-blg](https://github.com/flo-blg)  |
+| Guillaume Déflache ([guillaume-d](https://github.com/guillaume-d)) | Toufik Airane ([toufik-airane](https://github.com/toufik-airane)) | Keith Hoodlet ([securingdev](https://github.com/securingdev)) | Sinner ([SoftwareSinner](https://github.com/SoftwareSinner))  |
+| [iloving](https://github.com/iloving) | Jeroen Beckers ([TheDauntless](https://github.com/TheDauntless)) | Joubin Jabbari ([joubin](https://github.com/joubin)) | yu fujioka ([fujiokayu](https://github.com/fujiokayu))  |
+| execjosh ([execjosh](https://github.com/execjosh)) | Alicja Kario ([tomato42](https://github.com/tomato42)) | Sidney Ribeiro ([srjsoftware](https://github.com/srjsoftware)) | Gabriel Marquet ([Gby56](https://github.com/Gby56))  |
+| Drew Schulz ([drschulz](https://github.com/drschulz)) | [bedirhan](https://github.com/bedirhan) | [muralito](https://github.com/muralito) | Ronnie Flathers ([ropnop](https://github.com/ropnop))  |
+| Philippe De Ryck ([philippederyck](https://github.com/philippederyck)) | Malte ([mal33](https://github.com/mal33)) | [MazeOfThoughts](https://github.com/MazeOfThoughts) | Andreas Falk ([andifalk](https://github.com/andifalk))  |
+| Javi ([javixeneize](https://github.com/javixeneize)) | Daniel Hahn ([averell23](https://github.com/averell23)) | [borislav-c](https://github.com/borislav-c) | Robin Wood ([digininja](https://github.com/digininja))  |
+| [miro2ns](https://github.com/miro2ns) | Jan Dockx ([jandockx](https://github.com/jandockx)) | [vipinsaini434](https://github.com/vipinsaini434) | [priyanshukumar397](https://github.com/priyanshukumar397)  |
+| Nat Sakimura ([sakimura](https://github.com/sakimura)) | Benjamin Häublein ([BenjaminHae](https://github.com/BenjaminHae)) | [unknown-user-from](https://github.com/unknown-user-from) | Ali Ramazan TAŞDELEN ([alitasdln](https://github.com/alitasdln))  |
+| Pedro Escaleira ([oEscal](https://github.com/oEscal)) | Josh ([josh-hemphill](https://github.com/josh-hemphill)) | Tim Würtele ([SECtim](https://github.com/SECtim)) | AviD ([avidouglen](https://github.com/avidouglen))  |
+| SheHacksPurple ([shehackspurple](https://github.com/shehackspurple)) | [fcerullo-cycubix](https://github.com/fcerullo-cycubix) | Hector Eryx Paredes Camacho ([heryxpc](https://github.com/heryxpc)) | Irene Michlin ([irene221b](https://github.com/irene221b))  |
+| Jonah Y-M ([TG-Techie](https://github.com/TG-Techie)) | Dhiraj Bahroos ([bahroos](https://github.com/bahroos)) | Jef Meijvis ([jefmeijvis](https://github.com/jefmeijvis)) | [IzmaDoesItbeta](https://github.com/IzmaDoesItbeta)  |
+| Abdessamad TEMMAR ([TmmmmmR](https://github.com/TmmmmmR)) | [sectroyer](https://github.com/sectroyer) | Soh Satoh ([sohsatoh](https://github.com/sohsatoh)) | [regoravalaz](https://github.com/regoravalaz)  |
+| james-t ([james-bitherder](https://github.com/james-bitherder)) | Aram Hovsepyan ([aramhovsepyan](https://github.com/aramhovsepyan)) | [JaimeGomezGarciaSan](https://github.com/JaimeGomezGarciaSan) | [ValdiGit01](https://github.com/ValdiGit01)  |
+| iwatachan ([ishowta](https://github.com/ishowta)) | Vinod Anandan ([VinodAnandan](https://github.com/VinodAnandan)) | Kevin Kien ([KevinKien](https://github.com/KevinKien)) | [paul-williamson-swoop](https://github.com/paul-williamson-swoop)  |
+| [endergzr](https://github.com/endergzr) | Radhwan Alshamamri ([Rado0z](https://github.com/Rado0z)) | Grant Ongers ([rewtd](https://github.com/rewtd)) | Cure53 ([cure53](https://github.com/cure53))  |
+| [AliR2Linux](https://github.com/AliR2Linux) | Ads Dawson ([GangGreenTemperTatum](https://github.com/GangGreenTemperTatum)) | William Reyor ([BillReyor](https://github.com/BillReyor)) | gabe ([gcrow](https://github.com/gcrow))  |
+| [mascotter](https://github.com/mascotter) | [luissaiz](https://github.com/luissaiz) | Suren Manukyan ([vx-sec](https://github.com/vx-sec)) | Piotr Gliźniewicz  ([pglizniewicz](https://github.com/pglizniewicz))  |
+| Tadeusz Wachowski ([tadeuszwachowski](https://github.com/tadeuszwachowski)) | Nasir aka Nate ([andesec](https://github.com/andesec)) | [settantasette](https://github.com/settantasette) | Lars Haulin ([LarsH](https://github.com/LarsH))  |
+| Terence Eden ([edent](https://github.com/edent)) | [JasmineScholz](https://github.com/JasmineScholz) | Arun Sivadasan ([teavanist](https://github.com/teavanist)) | Yusuf GÜR ([yusuffgur](https://github.com/yusuffgur))  |
+| Troy Marshall ([troymarshall](https://github.com/troymarshall)) | Tanner Prynn ([tprynn](https://github.com/tprynn)) | Nick K. ([nickific](https://github.com/nickific)) | [raoul361](https://github.com/raoul361)  |
+| Azeem Ilyas ([TheAxZim](https://github.com/TheAxZim)) | Evo Stamatov ([avioli](https://github.com/avioli)) | Tim Potter ([timpotter87](https://github.com/timpotter87)) | Gavin Ray ([GavinRay97](https://github.com/GavinRay97))  |
+| monis ([demideus](https://github.com/demideus)) | Marcin Hoppe ([MarcinHoppe](https://github.com/MarcinHoppe)) | Grambulf ([ramshazar](https://github.com/ramshazar)) | Jordan Pike ([computersarebad](https://github.com/computersarebad))  |
+| Jason Rogers ([jason-invision](https://github.com/jason-invision)) | Ben Hall ([benbhall](https://github.com/benbhall)) | JamesPoppyCock ([jamesly123](https://github.com/jamesly123)) | WhiteHackLabs ([whitehacklabs](https://github.com/whitehacklabs))  |
+| Alex Gaynor ([alex](https://github.com/alex)) | Filip van Laenen ([filipvanlaenen](https://github.com/filipvanlaenen)) | [jeurgen](https://github.com/jeurgen) | [GraoMelo](https://github.com/GraoMelo)  |
+| Andreas Kurtz ([ay-kay](https://github.com/ay-kay)) | Tom Tervoort ([TomTervoort](https://github.com/TomTervoort)) | old man ([deveras](https://github.com/deveras)) | Marco Schnüriger ([marcortw](https://github.com/marcortw))  |
+| [stiiin](https://github.com/stiiin) | infoseclearn ([teaminfoseclearn](https://github.com/teaminfoseclearn)) | [hljupkij](https://github.com/hljupkij) | Noe ([nmarher](https://github.com/nmarher))  |
+| Lyz ([lyz-code](https://github.com/lyz-code)) | Martin Riedel ([mrtnrdl](https://github.com/mrtnrdl)) | KIM Jaesuck ([tcaesvk](https://github.com/tcaesvk)) | Barbara Schachner ([bschach](https://github.com/bschach))  |
+| René Reuter ([AresSec](https://github.com/AresSec)) | [carhackpils](https://github.com/carhackpils) | Tyler ([tyler2cr](https://github.com/tyler2cr)) | Hugo ([hasousa](https://github.com/hasousa))  |
+| Wouter Bloeyaert ([Someniak](https://github.com/Someniak)) | Mark de Rijk ([markderijkinfosec](https://github.com/markderijkinfosec)) | Ramin ([picohub](https://github.com/picohub)) | Philip D. Turner ([philipdturner](https://github.com/philipdturner))  |
+| Will Chatham ([willc](https://github.com/willc))  | | | |