جدار حماية تطبيقات الويب (WAF)

أي خدمة رقمية متاحة للجمهور تحتاج إلى استقبال الطلبات باستمرار. يسجّل العملاء الدخول، ويرسلون النماذج، ويرفعون الملفات، وينفذون عمليات الشراء والدفع. وفي الخلفية، تتصل تطبيقات الهاتف وشركاء الأعمال بالخدمة نفسها عبر API. المشكلة أن المهاجم لا يحتاج غالبًا إلى باب منفصل؛ بل يستخدم المسار نفسه الذي يستخدمه العميل الحقيقي.

من منظور الشبكة، قد يبدو الاتصالان طبيعيين تمامًا. كلاهما يصل عبر HTTPS إلى المنفذ 443، وكلاهما يطلب خدمة سمحت المؤسسة بنشرها على الإنترنت. لكن أحدهما عميل يراجع حسابه، بينما يحاول الآخر إرسال مدخلات خبيثة، أو اختبار بيانات دخول مسروقة، أو تشغيل وظيفة مكلفة آلاف المرات.

لهذا لا يكفي أن نعرف أن الاتصال مسموح. المطلوب هو فهم ما الذي يحاول العميل تنفيذه داخل التطبيق، وهنا يأتي دور Web Application Firewall (WAF).

ما هو Web Application Firewall (WAF)؟#

الـ WAF هو طبقة حماية تعمل على مستوى التطبيق وتفحص حركة HTTP وHTTPS المتجهة إلى المواقع Web Applications وواجهات API. وعندما يكون في موضع يسمح له برؤية الحركة بعد فك تشفير TLS، يستطيع تحليل الطلب وسياقه، ثم تطبيق الإجراء المناسب وفق السياسة: السماح، أو التسجيل، أو طلب Challenge إضافي، أو تطبيق Rate Limiting، أو الحجب.

لا ينظر الـ WAF إلى عنوان IP والمنفذ فقط، بل يقرأ تفاصيل التفاعل مع التطبيق: الصفحة المطلوبة، وطريقة HTTP، والـ Headers، والـ Cookies، والـ Parameters، والـ Request Body، وأحيانًا الملفات المرفوعة والاستجابة الصادرة  Response  . هذه الرؤية تمنحه قدرة لا يملكها Network Firewall وحده.

يحمي Network Firewall مسار الوصول إلى الخدمة، بينما يفحص WAF  كل طلب  يحدث مع التطبيق.

وجود الـ WAF لا يلغي الحاجة إلى Network Firewall، كما لا يلغي أي ضابط أمني آخر. لكل طبقة وظيفة مختلفة، والقيمة الحقيقية تظهر عندما تعمل هذه الطبقات معًا ضمن نهج Defense in Depth.

لماذا لا يكفي Network Firewall؟#

يجيب Network Firewall عن أسئلة تتعلق بالاتصال: من أين جاءت الحركة؟ إلى أي وجهة تتجه؟ ما البروتوكول والمنفذ المستخدمان؟ وهل تسمح سياسة الشبكة بهذا الاتصال؟ هذه الأسئلة أساسية، لكنها لا تكشف بالضرورة ما إذا كان طلب مسموح عبر HTTPS يحاول استغلال التطبيق.

فعند فتح المنفذ 443 لخدمة عامة، سيعبر منه العميل والمهاجم معًا. قد يمنع Network Firewall اتصالًا من شبكة محظورة أو إلى منفذ غير مصرح به، لكنه لا يفهم عادةً أن قيمة أُرسلت في حقل البحث تشبه SQL Injection، أو أن ملفًا مرفوعًا قد يحتوي على Web Shell، أو أن حسابًا واحدًا يتعرض لحملة Credential Stuffing موزعة على آلاف العناوين.

هذه ليست مقارنة بين أداة جيدة وأخرى ضعيفة؛ بل بين وظيفتين مختلفتين. يحمي Network Firewall طبقة الشبكة، بينما يضيف WAF سياق Layer 7 الذي تحتاج إليه حماية Web Applications وواجهات API.

ماذا يرى WAF داخل الطلب؟#

يحتوي طلب الويب  Requestعلى معلومات أكثر بكثير مما يظهر للمستخدم على الشاشة. هناك طريقة الطلب مثل GET أو POST، والمسار المطلوب، والـ Query Parameters، والـ Headers، والـ Cookies، والـ Content Type. وقد يحمل الـ Body بيانات Form أو JSON أو XML أو ملفًا مرفوعًا.

يفحص الـ WAF هذه العناصر معًا بدل التعامل مع الطلب ككتلة نصية واحدة. فقد تكون علامة اقتباس عادية داخل اسم شخص، لكنها غير منطقية في حقل لا يقبل سوى رقم تعريف. وقد يكون POST متوقعًا في صفحة تسجيل الدخول، لكنه غير معتاد في مسار صُمم للقراءة فقط. كما أن امتداد الملف أو الـ Content Type المعلن لا يثبت وحده أن محتواه آمن.

السياق مهم أيضًا عبر الزمن. محاولة دخول فاشلة واحدة أمر طبيعي، لكن مئات المحاولات السريعة على حساب واحد قد تعني Brute Force، ومحاولات قليلة موزعة على عدد كبير من الحسابات قد تشير إلى Password Spraying. والطلبات التي تبدو سليمة منفردة قد تكشف نمطًا مسيئًا عندما تُحلل كسلسلة واحدة.

لذلك لا تتمثل مهمة الـ WAF في البحث عن كلمات «خطرة» فقط، بل في تقدير ما إذا كان الطلب منطقيًا لهذا التطبيق، وهذا المسار، وهذا النوع من البيانات، وفي هذا التوقيت.

كيف يقرر WAF  ما اذا كان الطلب مريب؟#

لا توجد إشارة واحدة تكشف جميع الهجمات، لذلك تجمع منصات WAF عادةً أكثر من أسلوب. تستخدم Attack Signatures للتعرف إلى أنماط معروفة، وتطبق Protocol Validation لاكتشاف الطلبات المشوهة، والـ Headers المتعارضة، والترميز غير الصحيح، والأحجام غير المنطقية، وغيرها من مخالفات HTTP.

يمكن أيضًا تطبيق Positive Security Model، أي تحديد ما يسمح التطبيق باستقباله بدل الاكتفاء بحظر ما يشبه الهجمات المعروفة. فإذا كان Endpoint معين لا يقبل إلا POST مع بنية JSON محددة، يمكن رفض الطرق أو الحقول أو أنواع البيانات الخارجة عن هذا التعريف. هذا الأسلوب مهم خصوصًا لحماية API، لأن البنية المتوقعة تكون غالبًا أوضح من صفحات الويب التقليدية.

وتضيف بعض المنصات Threat Intelligence، وسمعة عناوين IP، وتحليل السلوك، وMachine Learning. تساعد هذه الإشارات في اكتشاف المسح الآلي، والـ Bots المسيئة، والأنماط التي لا تظهر في طلب واحد. لكنها لا تعمل بالسحر؛ فإذا كانت السياسة غير دقيقة، أو لم يُضبط المنتج بما يناسب التطبيق، فلن تعوض التقنية وحدها غياب الفهم التشغيلي.

هجمات تستغل المدخلات والملفات#

تشمل التهديدات التي يتعامل معها WAF عائلات متعددة، وليس SQL Injection وحده. قد يستهدف الهجوم قاعدة البيانات، أو نظام التشغيل، أو متصفح المستخدم، أو مسارات الملفات، أو خاصية رفع الملفات. وقد يستخدم المهاجم أكثر من تقنية في المحاولة نفسها.

SQL Injection وCommand Injection وXSS#

تحدث هجمات Injection عندما ينجح المهاجم في جعل بيانات أرسلها تُفسر على أنها أمر أو جزء من استعلام. في SQL Injection يكون الهدف عادةً استعلام قاعدة البيانات، وفي Command Injection يحاول المهاجم التأثير في أوامر نظام التشغيل. يستطيع WAF اكتشاف عدد كبير من الأنماط المعروفة، وفك الترميزات قبل التحليل، ورفض القيم التي لا تتفق مع نوع الحقل أو بنيته المتوقعة.

أما XSS فيستهدف متصفح المستخدم. يزرع المهاجم محتوى قابلًا للتنفيذ في موضع يفترض أن يعرض نصًا عاديًا، وقد يُنفذ هذا المحتوى عندما يفتح مستخدم آخر الصفحة. يخفف WAF كثيرًا من المحاولات الشائعة، لكنه لا يستبدل Output Encoding، والتحقق الصحيح من المدخلات، وسياسة Content Security Policy (CSP)، وتصميم التطبيق بطريقة آمنة.

Path Traversal وFile Inclusion ورفع الملفات الخبيثة#

قد يسمح التعامل غير الآمن مع أسماء الملفات والمسارات للمهاجم بتنفيذ Path Traversal أو Local/Remote File Inclusion والوصول إلى ملفات أو موارد لم تكن مخصصة للنشر. لا تكمن الخطورة في الرمز المستخدم وحده، بل في الطريقة التي يفسر بها التطبيق المسار والوجهة التي يمكن أن يصل إليها.

رفع الملفات يحتاج إلى عناية خاصة، لأن الملف قد يُخزن أو يُحلل أو يُعرض أو حتى يُنفذ لاحقًا. يمكن لملف يبدو اسمه طبيعيًا أن يحتوي على Malware أو Web Shell. وبحسب إمكانات المنصة وتكاملاتها، يستطيع WAF أو نظام الحماية المرتبط به فرض قيود على الحجم والنوع، ومقارنة الامتداد بالتوقيع الحقيقي للملف، وفحص المحتوى، أو إرساله إلى Malware Scanning.

مع ذلك، تبقى الضوابط الأساسية داخل التطبيق ضرورية: تخزين الملفات خارج Web Root، ومنع صلاحية التنفيذ، وإعادة تسمية الملفات، والتحقق منها في الخادم، وعزل المحتوى الخطر.

الـ WAF يضيف طبقة كشف Detection ومنع Prevention مهمة ، لكنه لا يجعل آلية رفع الملفات سيئة التصميم آمنة تلقائيًا.

عندما يتحول الاستخدام الطبيعي إلى إساءة#

ليست كل الهجمات تحتوي على Payload واضحًا. في Brute Force وPassword Spraying وCredential Stuffing، يستخدم المهاجم صفحة تسجيل الدخول الحقيقية ويرسل طلبات صحيحة من الناحية التقنية. ما يكشف الهجوم هو النمط: عدد المحاولات، وتوزيعها على الحسابات، وسرعتها، والأجهزة المستخدمة، وسمعة المصدر، وعلاقة المحاولات بعضها ببعض.

ينطبق الأمر نفسه على الـ Bots. بعض الـ Bots تعتبر مشروعة وليست خبيثة، مثل محركات البحث وأدوات المراقبة وتكاملات الأعمال. لكن بعضها يجمع المحتوى دون إذن، أو ينشئ حسابات وهمية ، أو يختبر بطاقات دفع وبيانات دخول مسروقة. لذلك يجب أن يركز Bot Management على السلوك والهوية والهدف، لا على حجب كل حركة آلية.

وتأتي هجمات DDoS على مستوى التطبيق بصورة مختلفة عن إغراق الشبكة بالحزم. قد يكرر المهاجم عمليات بحث مكلفة، أو يولد تقارير كبيرة، أو يستدعي Endpoint يستهلك موارد كثيرة، أو يوزع الطلبات على مصادر عديدة لتبدو كل جهة ضمن الحد الطبيعي. هنا تساعد Rate Limiting، وتتبع الـ Sessions والعملاء، وتحليل تكلفة كل طلب، والتكامل مع حماية DDoS.

السياسة الجيدة لا تضع حدًا واحدًا على الجميع. فالحد المناسب لصفحة تسجيل الدخول قد لا يناسب API يستخدمه مستخدم موثوق، فقد يحتاج تطبيق شراء التذاكر إلى قواعد تختلف عن صفحة المحتوى العام. الهدف هو الحد من الإساءة مع الحفاظ على تجربة المستخدم الحقيقي.

وهنا تظهر أهمية الـ WAF؛ إذ إن دوره لا يقتصر على البحث عن Payload أو توقيع معروف داخل الطلب، بل يمتد إلى تحليل السياق والسلوك المصاحب للطلب. فالحماية الفعالة تتطلب الجمع بين Rate Limiting، وBot Management، وتحليل سلوك المستخدم والجلسات، وسمعة عناوين IP، وربط المحاولات المتكررة، وحماية الـ APIs، والتكامل مع أنظمة DDoS وإدارة الهوية.

كل طبقة من هذه الطبقات تضيف سياقًا لا يستطيع Signature وحده توفيره، ما يساعد على التمييز بين الاستخدام المشروع والسلوك الآلي أو المسيء. لذلك فإن الـ WAF    لا يحمي التطبيق فقط من الطلبات الخبيثة الواضحة، بل يراقب كيفية استخدام وظائف التطبيق، وهوية المستخدم أو المصدر، ومعدل الطلبات ونمطها، ثم يطبق الإجراء المناسب مع تقليل التأثير على المستخدمين الشرعيين.

حماية APIs تحتاج إلى فهم البنية والسياق#

تعتمد التطبيقات الحديثة على APIs لخدمة الويب والهاتف والأنظمة الداخلية. غالبًا ما تحمل الطلبات بيانات JSON أو XML ذات بنية محددة، ولذلك يكون الفحص أدق عندما يعرف النظام الـ Endpoints، والـ Methods، والحقول المطلوبة، وأنواع البيانات، والقيم المسموح بها.

يمكن لبعض منصات WAF وWAAP  اكتشاف  APIs، أو استيراد تعريفات  OpenAPI ، ثم التحقق من الطلبات وفق الـ Schema.  كما توجد قدرات لحماية GraphQL، مثل تقييد مدئ الاستعلام وتكلفته، ودعم WebSocket عندما تكون المنصة قادرة على فحص الرسائل بعد ترقية الاتصال. تختلف هذه القدرات من منتج إلى آخر، ولا ينبغي افتراض توافرها لمجرد وجود كلمة WAF في اسم المنتج.

هناك أيضًا حدود مهمة. قد يكون طلب API صحيح البنية وصادرًا من مستخدم موثّق، لكنه يطلب سجلًا لا يحق لذلك المستخدم رؤيته. هذه مشكلة Authorization مرتبطة بقواعد العمل وملكية البيانات، ولا يستطيع WAF استنتاجها دائمًا من شكل الطلب. يجب أن يفرض التطبيق صلاحيات الوصول على مستوى كل Object وكل Function.

توضح OWASP API Security Top 10 — 2023 هذه الفجوة بوضوح؛ فمخاطر مثل Broken Object Level Authorization، والاستعلام غير المقيد للموارد، وإساءة استخدام المسارات الحساسة لا تُحل بقاعدة عامة واحدة. يستطيع WAF تقليل جزء من الخطر، لكن حماية API تبدأ من تصميم الصلاحيات والمنطق داخل الخدمة نفسها.

قد يكون الطلب سليمًا بينما تكون الاستجابة خطرة#

أحيانًا لا يحتوي الطلب على أي هجوم. يطلب المستخدم صفحة عادية، لكن خطأ داخل التطبيق يجعل الاستجابة تعرض Stack Trace، أو رسالة من قاعدة البيانات، أو مسارًا داخليًا، أو بيانات شخصية، أو Secret كان يجب ألا يغادر الخادم. في هذه الحالة يكون مصدر الخطر هو ما أرسله التطبيق إلى الخارج، لا ما أرسله المستخدم إلى الداخل.

إذا كانت خاصية Response Inspection مدعومة ومفعلة، فقد يتعرف WAF إلى مؤشرات تسرب المعلومات أو أنماط بيانات حساسة، ثم يسجل الحدث أو يحجب الاستجابة أو يخفي الجزء الحساس وفق قدرات المنتج. وقد تندرج بعض هذه الوظائف تحت DLP. لكنها تبقى شبكة أمان؛ فالواجب الأساسي هو إصلاح معالجة الأخطاء ومنع التطبيق من إنتاج هذه البيانات أصلًا.

التنبيه Alert  الصادر من WAF لا يعني تلقائيًا أن الطلب Request الوارد كان هجومًا؛ فقد يكون الاكتشاف متعلقًا بالاستجابة الصادرة.

عند التحقيق في أي حدث، يجب قراءة اتجاه الحركة ومرحلة الفحص والإجراء الذي اتخذته السياسة. هل اكتُشف النمط في Request أم Response؟ هل تم الحجب فعلًا أم كان الوضع Detection Only؟ وهل أخفى الـ WAF المشكلة عن المستخدم بينما ما زال التطبيق يولدها؟ هذه الأسئلة تمنع التشخيص الخاطئ وتوجّه الإصلاح إلى مكانه الصحيح.

من WAF إلى WAAP#

يركز WAF التقليدي على فحص HTTP و HTTPS وتطبيق سياسات حماية على مستوى التطبيق. أما منصات Web Application and API Protection (WAAP)   فتجمع عادةً عدة قدرات في خدمة واحدة، مثل WAF، وAPI Security، وBot Management، وحماية DDoS على Layer 7، وThreat Intelligence، وأحيانًا DLP وMalware Scanning  ومراقبة المخاطر في المتصفح.

هذا التصنيف مفيد، لكنه ليس ضمانًا بأن كل ميزة موجودة أو مفعلة. قد يحتاج API Security إلى تعريف OpenAPI أو مرحلة Discovery، وقد يعتمد Bot Management على JavaScript أو إشارات من الجهاز، وقد يتطلب فحص الملفات محركًا منفصلًا. كما أن Response Inspection قد يكون محدودًا لأنواع محتوى أو أحجام معينة، أو معطلًا افتراضيًا لأسباب تتعلق بالأداء والخصوصية.

ويحتاج جانب المتصفح إلى ضوابط خاصة. فالصفحات الحديثة تحمل Scripts من خدمات الدفع والتحليلات والدعم والإعلانات وCDNs، وقد يؤدي اختراق طرف ثالث إلى سرقة بيانات المستخدم دون اختراق خادم التطبيق. قد تساعد قدرات Client-Side Protection، إلى جانب Content Security Policy (CSP) وSubresource Integrity (SRI)، لكن هذه ليست وظيفة أساسية في كل WAF.

لذلك يجب تقييم ال WAF حسب قدراته الفعلية: ما الحركة التي يراها؟ هل يفحص Request وResponse؟ ما البروتوكولات المدعومة؟ ما الذي يعمل تلقائيًا، وما الذي يحتاج إلى ترخيص أو تهيئة أو تكامل إضافي؟ الاسم التجاري وحده لا يكفي للإجابة.

الدقة أهم من الحجب المفرط#

لا يوجد تطبيقان يتصرفان بالطريقة نفسها. قد يسمح نظام إدارة المحتوى بإدخال  HTML ، وقد يقبل محرك بحث رموزًا تقنية، وقد تستقبل API قيمة طويلة ومشفرة تبدو مريبة في سياق آخر. لذلك قد تؤدي قاعدة صحيحة عمومًا إلى نتيجة خاطئة إذا طُبقت بلا فهم للتطبيق.

عندما يحجب WAF طلبًا مشروعًا، تكون النتيجة False Positive؛ وعندما يمر هجوم دون اكتشاف، تكون النتيجة False .Negative.  فرفع مستوئ حساسية الفحص إلى أقصى حد قد يزيد عدد الاكتشافات، لكنه قد يعطل العملاء والعمليات المهمة. وفي المقابل، كثرة الاستثناءات قد تجعل لوحة التنبيهات هادئة على حساب الحماية الحقيقية.

تبدأ عملية تثبيت ونشر ال  WAFالجيد غالبًا بوضع المراقبة أو Detection Only، ثم بناء Baseline للحركة، ومراجعة التنبيهات، وضبط القواعد، واختبار أثرها قبل الانتقال إلى الحجب. ويجب أن تكون الاستثناءات ضيقة ومحددة بمسار أو حقل أو حالة معروفة، لا تعطيلًا عامًا لقاعدة حماية بسبب حدث واحد.

يستمر الضبط بعد الإطلاق. فالإصدارات الجديدة تضيف Endpoints وحقولًا، وتتغير رحلات تسجيل الدخول والدفع، ويظهر شركاء جدد، وتتبدل أنماط الاستخدام. وتشير OWASP عن WAF إلى أن تخصيص الحماية حسب التطبيق قد يحتاج إلى جهد، وأن القواعد تحتاج إلى صيانة مع تغير التطبيق.

الـ WAF ليس منتجًا يُركب ثم يُنسى؛ إنه سياسة أمنية يجب أن تتطور مع التطبيق.

Virtual Patching: حماية مؤقتة وليست إصلاحًا#

لا تستطيع الفرق  والمهندسين دائمًا إصلاح ثغرة فور اكتشافها. قد يحتاج التعديل إلى تطوير واختبارات Regression ونافذة نشر، أو قد تكون المشكلة في مكون خارجي لم يصدر له Update بعد. خلال هذه الفترة تظل الثغرة موجودة، ويظل التطبيق العام معرضًا لمحاولات الاستغلال.

إذا كان نمط الاستغلال معروفًا ويمكن اكتشافه في حركة الويب، فمن الممكن إضافة قاعدة WAF تمنع المحاولة قبل وصولها إلى الجزء الضعيف. يسمى هذا الأسلوب Virtual Patching، وهو Compensating Control يقلل فترة التعرض ويمنح الفريق وقتًا لتنفيذ الإصلاح الدائم بطريقة آمنة.

لكن Virtual Patching لا يزيل الثغرة من الشيفرة، وقد لا يغطي كل طرق الاستغلال، كما يحتاج إلى اختبار ومراقبة وضبط. توضح OWASP Virtual Patching Cheat Sheetأن إصلاح الشيفرة وVirtual Patching عمليتان متكاملتان وليستا بديلين متنافسين

ما الذي لا يستطيع WAF عمله؟#

لا يجعل WAF التطبيق الضعيف آمنًا بمجرد وضعه أمامه. فهو لا يستبدل Secure Coding، ولا Input Validation داخل الخادم، ولا Authentication وAuthorization، ولا إدارة الـ Secrets، ولا تحديث الـ Dependencies، ولا Code Review وSecurity Testing، ولا Logging وIncident Response.

يظهر هذا بوضوح في أخطاء الصلاحيات و ال Business  logic. إذا سمح التطبيق لمستخدم موثّق بشراء منتج بسعر جرى تعديله بطريقة غير مشروعة، أو بقراءة سجل يخص مستخدمًا آخر، فقد يكون الطلب سليم البنية ومتوافقًا مع الـ Schema. التطبيق وحده يعرف ملكية السجل وقواعد الخصم وتسلسل العملية الصحيح، ولذلك يجب أن يفرض هذه القواعد بنفسه.

تعرض OWASP Top 10:2025  نطاقًا أوسع من المخاطر، من Broken Access Control وSecurity Misconfiguration إلى Injection وInsecure Design ومشكلات Software Supply Chain وAuthentication وLogging.  قد يخفف WAF جانبًا من بعضها، لكن معالجة الخلل قد تكون في المعمارية أو الشيفرة أو الهوية أو إدارة المكونات أو العمليات التشغيلية.

التصور الصحيح هو Defense in Depth. يضيف WAF طبقة مهمة للفحص والمنع والرؤية وسرعة الاستجابة، بينما تتولى بقية المنظومة الضوابط التي لا يستطيع تنفيذها: تصميم آمن، وصلاحيات دقيقة، وتحديثات، واختبارات، ومراقبة مستمرة.

القيمة الحقيقية لـ WAF#

تظهر قيمة WAF في المنطقة التي لا تكفي فيها رؤية الشبكة وحدها: اللحظة التي يتحول فيها اتصال مسموح إلى تفاعل خطر داخل التطبيق. قد تكون المدخلات بداية SQL Injection، أو محاولة تسجيل الدخول جزءًا من Credential Stuffing، أو الملف المرفوع Web Shell، أو طلب API مخالفًا للـ Schema، أو الاستجابة نفسها حاملة لبيانات حساسة.

الـ WAF الجيد يقلل مساحة الهجوم، ويمنع عددًا كبيرًا من المحاولات المعروفة، ويكشف أنماط الإساءة، ويوفر بيانات مفيدة للتحقيق، ويدعم Virtual Patching عند الحاجة. لكنه يحقق أفضل نتيجة عندما يُضبط لكل تطبيق، ويرتبط بعملية مراقبة واستجابة واضحة، ويعمل إلى جانب Secure Development وIdentity Security  وحماية الشبكة.

الخلاصة بسيطة: السماح بالاتصال لا يعني الثقة في التفاعل. Network Firewall يقرر ما إذا كان الطريق مفتوحًا، أما WAF فيفحص ما يحدث على هذا الطريق عند وصوله إلى التطبيق. ولهذا يظل WAF طبقة أساسية في حماية الخدمات الرقمية الحديثة، لا حلًا منفردًا ولا بديلًا عن بناء التطبيق بطريقة آمنة.

مراجع إضافية#

·        OWASP: Web Application Firewall

·        OWASP Top 10:2025

·        OWASP API Security Top 10 — 2023

·        OWASP Virtual Patching Cheat Sheet