كثير من تطبيقات الويب تستخدم Cookie للجلسة و CSRF token منفصلًا لمنع الطلبات من origins غير موثوقة. عند اختبار endpoint في Web Postman أو API Tester، قد تنجح GET وتفشل POST رغم نفس المستخدم. السبب غالبًا أن دورة CSRF لم تُحاكَ بالكامل.
اعرف مصدر ال ـToken
قد يأتي CSRF في meta tag أو hidden input أو cookie أو endpoint bootstrap. لا تفترض أن اسمه X-CSRF-Token دائمًا. راقب request ناجحًا في المتصفح لتحديد المصدر وال header أو body field.
حافظ على Cookie Jar
API Tester يحتاج إرسال نفس session cookies بين خطوات login وجلب token و POST. إذا كانت الأداة لا تدير cookies تلقائيًا، أضف jar per workspace ولا تنسخ cookies يدويًا إلى history عام.
نفذ التسلسل الحقيقي
ابدأ login أو session bootstrap، ثم endpoint يعطي token، ثم الطلب mutating. إذا انتهت الجلسة، أعد الدورة بدل retry بنفس token.
خطوات عملية
- login.
- store cookies.
- fetch CSRF.
- send write request.
راجع Origin و Referer
بعض frameworks تتحقق من Origin أو Referer بالإضافة لل token. Web tool يعمل من origin مختلف قد يتأثر ب ـCORS قبل CSRF. فرق browser enforcement عن server CSRF check.
اختبر الأخطاء عمدًا
أرسل الطلب بدون token ثم token خاطئ ثم cookie مختلفة. يجب أن تفهم error لكل حالة. هذا يثبت أنك اختبرت الحماية لا مجرد happy path.
قائمة مراجعة
- missing token.
- wrong token.
- wrong session.
- expired token.
احمِ الأسرار في History
لا تحفظ Cookie أو CSRF token في export مشترك أو logs. استخدم متغيرات secrets و redaction، وحدد مدة لل cookie jar.
اختبر Rotation وانتهاء صلاحية Session و CSRF
بعض التطبيقات تغيّر CSRF token بعد login أو بعد write ناجح، وقد تدور Session Cookie نفسها. نفذ سلسلة من طلبين أو ثلاثة mutating بدل طلب واحد، وسجل هل token أو cookie تغيرت في response. Web Postman الاحترافي يجب أن يسمح باستخراج قيمة جديدة إلى variable آمنة وربطها بالطلب التالي، مع عدم إظهار السر في history أو export. اختبر كذلك انتهاء الجلسة: request قد يرجع login HTML بدل JSON أو 419/403 حسب framework. يجب أن يميز ال ـclient هذا عن network failure وألا يعيد نفس write بلا login جديد. هذه السيناريوهات تمنع نجاح demo أول ثم فشل الاستخدام الواقعي بعد عدة عمليات.
قائمة مراجعة
- Token قبل وبعد write.
- Cookie jar تتحدث تلقائيًا.
- Expired session لها error واضح.
- Secrets لا تظهر في history.
اختبر Multi-tab Session State
افتح تبويبين من نفس البروفايل، جدّد CSRF أو سجّل خروجًا في أحدهما ثم نفذ write في الآخر. بعض التطبيقات تبطل token القديمة أو تدور session، ما يكشف مشكلة لا تظهر في تبويب واحد. API Tester يمكنه محاكاة ذلك بجارين أو snapshots منفصلة لل cookies، ويجب أن يوضح أي سياق يُستخدم لكل طلب حتى لا تختلط الحالة.
من المثال إلى تطبيق يمكن صيانته
في «كيف تختبر API يستخدم Cookies و CSRF معًا من Web Postman» جرّب الحل على حالة صغيرة ثم أضف failure path واضحًا واختبارًا آليًا يحمي السلوك المتوقع. حدّد contract للمدخلات والمخرجات، وتعامل مع القيم الناقصة قبل الوصول إلى طبقة التنفيذ. إذا كان الحل يتعامل مع API أو ملف أو DOM، أضف logging مختصرًا يوضح المرحلة وكود الخطأ دون بيانات حساسة. بعد ذلك اختبر التوافق مع نسخة سابقة أو بيئة مختلفة. هذه الخطوات تجعل المثال مفيدًا في مشروع حقيقي بدل أن يبقى snippet يعمل فقط في المسار المثالي.
قائمة مراجعة
- Contract للمدخلات والمخرجات.
- اختبار failure path.
- رسائل خطأ قابلة للتشخيص.
- Regression test قبل الدمج.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…