قائمة فحص أمان Claude Code لفحوصات سريعة لتطبيقات الويب

ما هو فحص أمان خفيف الوزن

فحص الأمان الخفيف هو مراجعة سريعة (غالبًا 30–60 دقيقة) تهدف لالتقاط المشاكل الواضحة وعالية التأثير قبل النشر. ليس بديلاً عن تدقيق كامل. اعتبره جولة تفقد سلامة: تمسح المسارات التي تفشل غالبًا في التطبيقات الحقيقية وتبحث عن دليل واقعي، ليس افتراضات.

تركّز هذه القائمة من Claude Code على المجالات التي تنكسر غالبًا في تطبيقات الويب اليومية:

• افتراضات المصادقة (كيف تعرف من هو المستخدم)
• ثغرات التفويض (ما المسموح له فعله)
• التحقق من المدخلات
• معالجة الأسرار
• أسطح الحقن الشائعة (SQL، تشغيل أوامر، عرض قوالب، إعادة توجيه، تحميل ملفات)

لا تحاول إثبات عدم وجود أخطاء، ولا تصور خصوم تهديد معقدين، ولا تحل محل اختبار الاختراق.

"النتائج الملموسة" تعني أن كل مشكلة تسجلها تحتوي على دليل يمكن للمطوّر التعامل معه فورًا. لكل نتيجة، التقط:

• الملف(الملفات) والدالة/معالج الطلب بالضبط
• السلوك الخطر في جملة واحدة
• خطوة تكرار بسيطة (طلب، حمولة، أو مسار نقر)
• لماذا يهم (التأثير) ومن يمكنه إثارة ذلك
• اتجاه إصلاح آمن (ليس إعادة كتابة كاملة)

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

حدّد النطاق خلال 10 دقائق

لا يعمل المراجعة السريعة إلا إن قَصرت الهدف. قبل أن تطلب من Claude Code فحص أي شيء، قرّر ماذا تريد إثبات اليوم وما الذي لن تفحصه.

ابدأ بمسار مستخدم واحد إلى ثلاثة حيث تكون الأخطاء مكلفة ماديًا، تكشف بيانات، أو تمنح صلاحيات. مرشّحون جيدون: تسجيل الدخول، إعادة تعيين كلمة المرور، إتمام الدفع، وشاشات تحرير المسؤول.

بعدها، سمّ الأصول التي يجب حمايتها بدقة: حسابات المستخدمين، إجراءات الدفع، البيانات الشخصية، عمليات خاصة بالمسؤول فقط.

ثم اكتب افتراضات التهديدات بكلمات بسيطة. هل تدافع ضد مستخدم فضولي ينقر، مهاجم خارجي به سكربتات، أم داخلي لديه بعض الوصول؟ إجابتك تغير معنى "جيد بما يكفي".

أخيرًا، عرّف نجاح وفشل حتى تنتهي المراجعة بنتائج قابلة للتنفيذ وليس بانطباعات. قواعد بسيطة تعمل جيدًا:

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

إن لم تستطع وصف شكل الفشل، فالنطاق لا يزال غامضًا.

حضّر السياق الذي تسمّيه لClaude Code

لا يعمل الفحص إلا إذا كان النموذج ينظر للأماكن الصحيحة. اجمع حزمة صغيرة من الشيفرة والملاحظات حتى تنتج المراجعة دليلاً، لا تخمينًا.

ابدأ بمشاركة مسار الأهمية الأمنية: نقاط دخول الطلب والشيفرة التي تقرر من هو المستخدم وماذا يمكنه فعل. أدرج ما يكفي من الشيفرة المحيطة لتظهر كيف يتدفّق البيانات.

حزمة عملية عادة تضم:

• مدخل المصادقة: تحليل الجلسة/JWT، إعدادات الكوكيز، ردود استدعاء تسجيل الدخول، ميدل وير المصادقة
• المسارات والمعالجات: المتحكمات، طرق RPC،Resolvers في GraphQL، معالجات مهام الخلفية
• طبقة البيانات: استعلامات ORM، مساعدي SQL الخام، منشئي الاستعلامات، هجرات الجداول الحساسة
• فحوص السياسات: فحوص الأدوار، فحوص الملكية، أعلام الميزات، نقاط نهاية خاصة بالمسؤول
• التحقق: مخططات التحقق من الطلبات، معالجات تحميل الملفات، كود إلغاء التسلسل

أضف بضعة أسطر من ملاحظات البيئة لتوضيح الافتراضات: جلسة مقابل JWT، أين تُخزن التوكنات (كوكي أو هيدر)، سلوك البروكسي العكسي أو بوابة API، العمال/المهام المجدولة، وأي نقاط نهاية "داخلية فقط".

قبل مطاردة الأخطاء، اطلب جردًا: نقاط الدخول، نقاط النهاية المميزة، ومخازن البيانات المتأثرة. هذا يمنع إغفال السطوح.

اتفق أيضًا على صيغة إخراج تُجبر على نتائج ملموسة. جدول بسيط يعمل جيدًا: النتيجة، الشدة، نقطة النهاية/الملف المتأثر، الدليل (مقتطف أو نطاق أسطر دقيق)، سيناريو الاستغلال، اقتراح الإصلاح.

سير العمل خطوة بخطوة لمراجعة 30–60 دقيقة

حدد الوقت:

• 10 دقائق للتوجيه
• 15–30 دقيقة لتتبع التدفقات
• 10 دقائق للكتابة والتوثيق

الهدف ليس تغطية كاملة. إنه مجموعة صغيرة من النتائج القابلة للاختبار.

ابقَ التطبيق مفتوحًا أثناء القراءة. انقر عبر الواجهة وراقب الطلبات التي تُرسل. يجب أن تشير الملاحظات إلى نقاط نهاية محددة، معلمات، ومصادر بيانات.

سير عمل يناسب جلسة واحدة:

1. ارسم نقاط الدخول وحدود الثقة. لاحظ المسارات العامة، المسارات لِما بعد الدخول، مسارات المسؤول، الويب هوكس، التحميلات، واستدعاءات أطراف ثالثة. علّم أين ينتقل البيانات من متحكّم به المستخدم إلى موثوق به الخادم.
2. لكل نقطة نهاية مهمة، دوّن ما يثبت الهوية وأين يحدث ذلك. إذا كان الفحص في "ميدل وير"، تأكد أن كل مسار فعلاً يستخدمه.
3. افعل نفس الشيء للتفويض. اختر إجراءً خطيرًا واحدًا (عرض بيانات مستخدمين آخرين، تغيير أدوار، تصدير، حذف) وتتبّع قرار الإذن حتى الاستعلام في قاعدة البيانات.
4. تتبّع مدخلات المستخدم نحو المصافي. اتبع معلمة واحدة من الطلب حتى SQL/ORM، عرض القوالب، تنفيذ الأوامر، جلب URL (SSRF)، إعادة التوجيهات، ومسارات الملفات.
5. امسح تدفقات الأسرار أثناء التتبّع. ابحث عن توكنات في السجلات، شيفرة العميل، رسائل خطأ، تفريغات البيئة، وأنماط تخزين ضعيفة.

عادة مفيدة: لكل "يبدو جيدًا" اكتب ما ستفعله لكسره. إن لم تستطع وصف محاولة كسر، فأنت لم تتحقق كفاية.

فحوص المصادقة: إثبات هوية المستخدم

المصادقة هي المكان الذي يقرر فيه التطبيق: "هذا الطلب يعود لهذا الشخص". فحص سريع لا يعني قراءة كل سطر. يعني العثور على المكان الذي تُنشأ أو تُقبل فيه الهوية، ثم فحص الاختصارات ومسارات الفشل.

عثر على حد الثقة: أين تُنشأ الهوية أو تُقبل أول مرة؟ قد تكون كوكي جلسة، توكن JWT، مفتاح API، أو mTLS على الحافة. اطلب من Claude Code الإشارة إلى الملف والدالة التي تحوّل "مجهول" إلى معرّف مستخدم، وذكر كل مسار آخر يمكنه فعل الشيء نفسه.

فحوص مصادقة تستحق المسح:

• حدد كل مدخلات المصادقة (تسجيل ويب، توكنات API، مصادقة الجوال، مصادقة خدمات داخلية) وتحقق أنها تتوحد على نموذج هوية واحد ثابت.
• افحص تسجيل الدخول وإعادة الضبط لوجود حدود معدل، إقفال حساب، وإمكانية تعداد المستخدمين (رسائل خطأ أو توقيت مختلف للحسابات الموجودة مقابل غير الموجودة).
• فحص الجلسات والكوكيز: HttpOnly، Secure، SameSite، انتهاء الصلاحية، تدوير عند تسجيل الدخول وتغيير الصلاحيات، وإبطال الجلسة عند تسجيل الخروج (على الخادم، ليس فقط "حذف الكوكي").
• راجع MFA ومسارات الاسترداد حتى لا تكون مسار الاسترداد أضعف من MFA (مثال: إعادة ضبط عبر البريد فقط تتجاوز MFA).
• راجع سجلات فشل المصادقة: مفيدة للتشغيل، لكن لا تكشف تفاصيل تساعد المهاجم (لا "المستخدم موجود" أو تفريغ توكنات).

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

فحوص التفويض: إثبات أن للمستخدم الإذن

التفويض يسبب أكبر ضرر عندما يكون خاطئًا: "هل يُسمح لهذا المستخدم بهذا الإجراء على هذا المورد بالذات؟" فحص سريع يجب أن يحاول كسر هذا الافتراض عمدًا.

اكتب الأدوار والصلاحيات بلغة بسيطة:

• المالك يمكنه دعوة أعضاء
• العضو يمكنه تعديل ملفه الشخصي فقط
• الدعم يمكنه عرض بيانات الفواتير لكن لا يغير الخطة
• المسؤول يمكنه حذف المشاريع

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

فحص سريع عادةً يكشف مشاكل حقيقية:

• اعثر على نقاط النهاية/المتحولات التي تنشئ، تحذف، تصدر، تغيّر أدواراً، أو تصل لبيانات الفوترة
• لكل منها، اعثر على فحص الصلاحية على جانب الخادم (ليس الواجهة)
• ابحث عن معرّفات يسيطر عليها المستخدم (projectId, userId, orgId) وتأكد من فحوص الملكية
• تأكد أن المسارات الخاصة بالمسؤول تفشل مغلقة عند غياب الدور
• افحص حدود المستأجر: يجب أن يأتي orgId/accountId من سياق الجلسة، ليس فقط من مدخل الطلب

الرائحة الكلاسيكية لـ IDOR بسيطة: طلب مثل GET /projects/{id} حيث {id} قابل للتحكم من المستخدم، والخادم يحمله دون التحقق من أنه يخص المستخدم أو المستأجر الحالي.

مطالبة تجبر إجابة حقيقية:

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

التحقق من المدخلات: إبقاء البيانات السيئة خارجًا مبكرًا

معظم مشاكل تطبيقات الويب السريعة تبدأ بثغرة: التطبيق يقبل مدخلات لم يتوقعها المطور. عامل "المدخل" كأي شيء يمكن لمستخدم أو نظام آخر التأثير فيه، حتى لو بدا غير ضار.

ابدأ بتسمية المدخلات لنقطة النهاية التي تفحصها:

• قيم استعلام URL ومساراته
• حقول جسم الطلب (بما في ذلك JSON المتداخل)
• رؤوس الطلب (رؤوس المصادقة، نوع المحتوى، IP المعاد توجيهه)
• الكوكيز
• تحميلات الملفات (الاسم، الحجم، النوع، البيانات الوصفية)

يجب أن يحدث التحقق بالقرب من مكان دخول البيانات إلى التطبيق، ليس عميقًا في منطق الأعمال. افحص الأساسيات: النوع (سلسلة مقابل رقم)، الحد الأقصى للطول، مطلوب أم اختياري، والصيغة (بريد إلكتروني، UUID، تاريخ).

للقيم المعروفة مثل الأدوار، حالات، أو اتجاهات الفرز، فضّل قائمة سماح. أصعب لتجاوزها من "حظر بعض القيم السيئة".

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

خطة مصغّرة "مدخلات سيئة" لنقاط النهاية الخطرة (تسجيل الدخول، البحث، التحميل، إجراءات المسؤول):

• سلاسل طويلة جدًا (10,000+ حرف)
• أنواع خاطئة (مصفوفة بدل سلسلة)
• قيم تعداد غير متوقعة
• أحرف خاصة تغير المعنى
• قيم فارغة لحقول مطلوبة

مثال: باراميتر الفرز الذي يقبل أي سلسلة قد يتحوّل إلى شظية SQL لاحقًا. قائمة سماح مثل "date" أو "price" تمنع هذه الفئة من الأخطاء مبكرًا.

أسطح الحقن الشائعة للفحص السريع

معظم المراجعات السريعة تجد مشاكل في نفس الأماكن: أي مكان يُفسّر فيه إدخال المستخدم ككود، استعلام، مسار، أو URL. هنا تصطاد لحظات "المدخل يعبر حد الثقة".

تتبّع البيانات من نقاط الدخول (باراميترات الاستعلام، الرؤوس، الكوكيز، التحميلات، نماذج المسؤول) إلى حيث تنتهي.

أهداف فحص سريعة

ابحث عن هذه الأنماط واطلب موقع نداء ومثال حمولة ملموس لكل منها:

• SQL injection: الاستعلامات المبنية كسلسلة، ORDER BY ديناميكي، وبناة IN (...) التي تَجمَع قيم المستخدم
• XSS: العرض HTML، القوالب، معاينات Markdown، محررات النص الغني حيث يُفترض "التعقيم لاحقًا"
• حقن أوامر: استدعاءات الشيل حول معالجة الصور، أدوات PDF، أو خطوات "convert" التي تمرر أعلام من المستخدم
• SSRF: جلب عناوين URL لويب هوكس، معاينات الروابط، استيراد من URL، وفحوص داخلية تقبل URL من المستخدم
• تسلّل المسار: نقاط تحميل/تنزيل ملفات، فك ضغط ملف zip، وخطوط أنابيب التحميل التي تقرأ الملفات لاحقًا بالاسم

راقب أيضًا إلغاء التسلسل وحقن القوالب. أي شيء يحلّل JSON أو YAML أو سلاسل قالب من المستخدم يمكن أن يخفي سلوكًا خطيرًا، خاصة عند دعم أنواع مخصصة أو تعابير أو عرض على الخادم.

إن قبلت ميزة URL أو اسم ملف أو نص منسق، افترض أنه قابل لسوء الاستخدام حتى تثبت العكس بمسارات الشيفرة والاختبارات.

معالجة الأسرار: العثور على التسريبات والتخزين الضعيف

مشاكل الأسرار عادة ما تكون صاخبة عندما تعرف أين تبحث. ركّز على أين تعيش الأسرار وأين تُنسخ عن غير قصد.

أماكن شائعة لظهور الأسرار:

• متغيرات البيئة وملفات تهيئة التطبيق
• مخرجات CI وسجلات البناء (بما في ذلك سجلات نشر فاشلة)
• حزم العميل وبناءات المحمول (أي شيء يُشحن للمستخدم)
• نقاط نهاية التصحيح، صفحات الحالة، وأدوات الإدارة
• صفحات الأخطاء، تتبعات المكدس، وأحداث التحليلات

ثم اجبر إجابة ملموسة: إن كان السر معرضًا اليوم، ما الذي سيحدث بعد ذلك؟ نظام جيد لديه مسار تدوير (مفتاح جديد)، إبطال (تعطيل المفتاح القديم)، وطريقة لإعادة النشر بسرعة. إن كانت الإجابة "سنغيره لاحقًا" فاعتبر ذلك نتيجة.

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

مطالبات فحص سريعة يمكنك لصقها في Claude Code:

• "ابحث عن توكنات صلبة، كلمات مرور، ومفاتيح خاصة. اذكر مسارات الملفات الدقيقة ونماذج السلاسل التي طابقتها."
• "اعثر على أي كود يسجل رؤوس الطلب، الكوكيز، متغيرات البيئة، أو كائنات الأخطاء كاملة. اعرض أسطر السجل وما الحقول الحساسة التي قد تظهر."
• "تحقق إن كانت الأسرار يمكن أن تنتهي في لقطات، صادرات، أو قطع بناء. حدد ماذا يُلتقط وأين يُخزن."

أخيرًا، أكد الضوابط: امنع الأسرار من التحكم بالمصدر (فحوص قبل الالتزام/CI)، وتحقق أن النسخ الاحتياطية أو اللقطات لا تحتوي على بيانات اعتماد نصية صريحة. إن كانت منصتك تدعم اللقطات والتراجع، تحقق أن الأسرار تُحقن وقت التشغيل، لا تُخبَز داخل الصور المحفوظة.

مطالبات تجبر نتائج ملموسة (نُسخ للصق)

المطالبات الغامضة تعطي إجابات غامضة. اجبر النموذج على الالتزام بدليل: مواقع دقيقة، تتبّع يمكنك اتباعه، تكرار يمكنك تشغيله، وما الذي يجعل الادعاء خطأ.

استخدم نمطًا واحدًا في كل مرة ثم اطلب مراجعة بعد تأكيد أو رفض التفاصيل.

• دليل على مستوى الملف: "ابحث في المستودع عن auth، sessions، tokens، وmiddleware. سمّ الملفات، الدوال، ونطاقات الأسطر المعنية. اقتبس المقتطفات. إن لم تستطع الإشارة للشيفرة، قل 'لا يوجد دليل'."
• تتبع من المدخل إلى المصب: "اختر مدخلاً واحدًا يسيطر عليه المستخدم (رأس، استعلام، جسم، كوكي). اعرض تدفّق البيانات خطوة بخطوة من نقطة الدخول إلى حيث تُستخدم (SQL، HTML، شيل، قالب، إعادة توجيه، مسار ملف). اذكر كل دالة في السلسلة."
• خطوات التكرار: "أعطِ تكرارًا بسيطًا باستخدام curl (الطريقة، شكل URL، الرؤوس، الجسم). ادرج رمز الحالة المتوقع ومثال استجابة للنجاح/الفشل. اذكر الافتراضات (الأدوار، حالة المصادقة)."
• التحكم في الإيجابيات الكاذبة: "ما الذي ينقض هذه النتيجة؟ اذكر 2–3 فحوص: إعدادات التهيئة، ترتيب middleware، تحقق بقائمة سماح، استعلامات مُعلّمة، هروب الإطار. إن وُجد أي منها، فسّر لماذا يتغير الخطر."
• أصغر إصلاح آمن + اختبار: "اقترح أصغر تغيير يمنع المشكلة دون كسر الحالات الصحيحة. ثم اكتب اختبارًا واحدًا تضيفه (اسم، الهدف، المدخلات، النتيجة المتوقعة). إن وُجدت مفاضلات، اذكرها."

إن بدا الإخراج غامضًا، حاصره:

"أجب فقط بـ: مسار الملف، اسم الدالة، السطر الخطر، وجملة واحدة عن التأثير."

مثال واقعي: تحويل حدس إلى مشكلة موثقة

نقاط تحديث الملف الشخصي غالبًا ما تخفي مشاكل تحكم بالوصول. هنا حالة صغيرة يمكنك تمريرها عبر هذه القائمة.

السيناريو: نقطة نهاية API تحدّث ملف المستخدم:

PATCH /api/profile?accountId=123 مع JSON مثل { "displayName": "Sam" }.

تطلب من Claude Code العثور على المعالج، تتبّع كيفية استخدام accountId، وإثبات إن كان الخادم يفرض الملكية.

ما يظهر غالبًا:

• المصادقة: الطلب يتطلب جلسة أو توكن، فيبدو محميًا.
• التفويض: المعالج يثق في accountId من سلسلة الاستعلام ويحدّث ذلك الحساب دون التحقق أنه يطابق المستخدم المسجّل.
• التحقق من المدخلات: displayName يُقصّر، لكن accountId لا يُتحقق أنه عدد صحيح.
• سطح الحقن: SQL يُبنى بتجميع سلاسل مثل "... WHERE account_id=" + accountId.

كتابة جيدة تكون ملموسة:

• الشدة: عالية (IDOR + احتمال SQL injection)
• الدليل: طلب بتسجيل دخول صالح يغيّر حساب آخر عند تعديل accountId; SQL يُبنى من مدخل غير موثوق
• الإصلاح: تجاهل accountId من العميل، استخدم معرّف الحساب من المستخدم المصادق على الخادم؛ استعمل استعلامات مُعلّمة
• الاختبار: حاول تحديث حساب آخر وتوقع 403؛ ارفض accountId غير الرقمي

بعد التصحيح، أعد الفحص سريعًا:

• جرّب نفس الطلب مع accountId مختلف وتأكد أنه يفشل.
• تأكد أن السجلات تُظهر أن الخادم يستخدم المعرّف المصادق، ليس باراميتر الاستعلام.
• تأكد أن الاستعلام يستخدم الباراميترات وليس بناء سلاسل.
• نفّذ اختبار سلبي لمدخلات خاطئة (حروف، رقم كبير جدًا).

الفخاخ الشائعة التي تجعل الفحوص السريعة تفوّت مشاكل حقيقية

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

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

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

طرق سريعة تخلِّي الفحوص عن المسار الصحيح

تظهر هذه الفخاخ مرارًا:

• افتراض "خاص بالمسؤول" لأنه صفحة مسؤول، وليس لأن الخادم يفرض ذلك
• طلب نتائج مراجعة عامة بدلًا من "أرني الطلب المحدد الذي يتجاوز X"
• قبول "احتمال SQL injection" بلا نقطة بناء الاستعلام ومسار المدخل
• تجاهل نقاط الدخول الأقل وضوحًا مثل الويب هوكس، مهام مجدولة، أدوات الاستيراد، وإجراءات الإدارة الداخلية
• إصلاح الأعراض (إضافة فلتر أو regex) بينما سبب الجذر هو التحقق المفقود أو التفويض المفقود

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

فحوص سريعة يمكن تنفيذها قبل النشر

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

خمسة فحوص سريعة عادةً مجدية:

• احتكاك المصادقة: جرّب 10 محاولات تسجيل فاشلة متتالية. هل ترى حدود معدل، إقفال حساب، أو على الأقل تباطؤ؟ هل يمكن معرفة وجود بريد إلكتروني من رسائل الخطأ أو التوقيت؟
• التفويض بتبديل المعرف: اختر موردًا حقيقيًا (طلب، فاتورة، ملف تعريف). غيّر المعرف في URL، جسم JSON، أو متغيرات GraphQL. هل تحصل على بيانات ليست لك، حتى لو مجرد "ميتاداتا"؟
• ضوابط المدخلات: لحقول رئيسية (البريد، الاسم، البحث، تحميل الملف)، جرّب سلاسل طويلة جدًا، يونيكود غريب، وأنواع غير متوقعة (رقم بدلًا من سلسلة). هل تفرض حدود الطول وقوائم السماح حيث تهم؟
• تعريض الأسرار: ابحث في السجلات والحقائب العميلية عن توكنات، مفاتيح API، JWTs، أو "Authorization: Bearer". تحقق أيضًا من صفحات الأخطاء. "كان في الستاجنغ فقط" غالبًا ما يصبح "شحن في الإنتاج".
• أسطح الحقن: ابحث عن تجميع السلاسل في SQL، عوامل تصفية، عرض القوالب، أو أوامر شيل، أو عناوين إعادة توجيه. إن وصلت المدخلات إلى أحد هذه المواقع دون تحقق قوي، افترض الخطر حتى تثبت العكس.

دوّن أهم 3 إصلاحات يمكنك شحنها هذا الأسبوع، لا قائمة أمنيات. مثال: (1) أضف حد معدل لتسجيل الدخول وإعادة الضبط، (2) فرض فحوص ملكية على نقطة النهاية "get by id"، (3) تحديد طول المدخلات ورفض الأحرف غير المتوقعة لحقل البحث.

الخطوات التالية: اجعل هذه القائمة جزءًا من عملية البناء

فحص سريع يؤتي ثماره فقط إن غيّر ما تُشحنه. عامل هذه القائمة كخطوة بناء صغيرة قابلة للتكرار، ليست مهمة إنقاذ لمرة واحدة.

حوّل كل نتيجة إلى عنصر في لوحة العمل يصعب إساءة فهمه:

• الإصلاح: ما الذي سيتغير في الشيفرة أو التهيئة
• الاختبار: كيف ستثبت أنه مُصلَح (طلب واحد، اختبار وحدة، خطوة QA)
• المالك: شخص واحد مسؤول
• تاريخ مستهدف: الإصدار القادم أو يوم محدد
• الدليل: الملف/النقطة النهاية والطلب أو الحمولة التي أظهرت المشكلة

اختر إيقاعًا يناسب مستوى المخاطر وحجم الفريق. للعديد من الفرق، كل إصدار هو الأفضل. إن كانت الإصدارات متكررة، قم بمراجعة 30–60 دقيقة شهريًا وفحص أقصر قبل الشحن.

سَهِّل التكرار بإنشاء حزمة مطالبات قابلة لإعادة الاستخدام ونموذج قائمة فحص. اجعل المطالبات مركزة على مخرجات ملموسة: عرض المسار، الحارس، الطلب الفاشل، والسلوك المتوقع. خزّن الحزمة حيث يعمل فريقك بالفعل حتى لا تُهمل.

إن بنيت التطبيقات عبر الدردشة، ادخل القائمة في التخطيط. أضف ملاحظة قصيرة "افتراضات أمنية" للمصادقة/التفويض، المدخلات، والأسرار، ثم نفّذ الفحص مباشرة بعد النسخة الأولى العاملة.

المنصات مثل Koder.ai (koder.ai) قد تناسب هذه العادة لأنها تتيح التكرار السريع مع نقاط مراجعة. استخدام اللقطات والتراجع حول التغييرات الخطرة يجعل من الأسهل شحن إصلاحات أمنية دون التوقف عندما يكسر تغيير ما سلوكًا.