Safe Logging: كيف تسجل الأخطاء بدون تخزين Cookies أو Tokens

Logs ضرورية لتشخيص الأعطال، لكنها قد تلتقط Authorization headers و cookies و query parameters و request bodies أو رموز جلسات دون قصد. في تطبيق يدير حسابات متعددة تصبح المخاطرة أكبر لأن log واحد قد يجمع أسرار عدة بروفايلات. Safe Logging يعني تصميم البيانات التي يسمح بتسجيلها منذ البداية، لا محاولة تنظيف ملفات ضخمة بعد وقوع المشكلة.

اعتمد Allowlist للحقول

حدد حقولًا آمنة مثل timestamp، error code، component، profile pseudonymous ID، duration، و network stage. لا تسجل كل object ثم تحذف بعض الحقول؛ هذا يفشل عند إضافة مفتاح جديد. ال ـallowlist تجعل القيمة الجديدة غير مسجلة تلقائيًا حتى يراجعها الفريق.

نقّح URLs وال Headers قبل الكتابة

احذف أو hash query values الحساسة، وامنع Authorization و Cookie و Set-Cookie بالكامل. انتبه لل ـReferer و Location لأنها قد تحمل tokens. نفّذ redaction في logger مركزي قبل وصول البيانات إلى sink حتى لا يعتمد كل module على نفسه.

استخدم معرفات غير مباشرة

بدل البريد أو اسم الحساب استخدم profile ID داخليًا لا يكشف هوية المستخدم، ويفضل أن يكون scoped أو pseudonymous في تقارير الدعم. إذا احتجت ربط حادثة بمستخدم، اجعل الربط في نظام صلاحيات منفصل وليس في ملف log الخام.

ضع حدودًا للاحتفاظ والوصول

Logs التشخيصية لا يجب أن تبقى للأبد. عرّف retention حسب النوع، ودوّر الملفات، وقيّد الوصول، وسجّل من قام بالتصدير. عند مشاركة bundle للدعم طبّق redaction مرة أخرى كطبقة دفاع إضافية.

اختبر ال ـlogger بمحتوى سام

أنشئ اختبارات تحتوي قيمًا مثل bearer token و cookie و password و email و API key داخل headers و URL و body ثم تأكد أنها لا تظهر في الناتج. أضف الاختبار إلى CI حتى لا يعيد refactor لاحق تسريب البيانات.

احتفظ بسياق يكفي للتشخيص

الأمان لا يعني log فارغًا. error code، correlation ID، component، operation، timing، و state transition غالبًا تكفي لإعادة بناء التسلسل دون المحتوى الحساس. الهدف هو أعلى قيمة تشخيصية بأقل بيانات شخصية.

اجمع الدليل قبل تغيير الإعدادات

في «Safe Logging: كيف تسجل الأخطاء بدون تخزين Cookies أو Tokens» اجمع timestamp وكود الخطأ والمكوّن والبروفايل ومسار الشبكة قبل أي تعديل. بعد ذلك قارن حالة سليمة بحالة متأثرة مع تغيير عامل واحد فقط، مثل proxy أو extension أو policy. إذا اختفى الخطأ، أعد العامل مرة أخرى للتأكد من السببية بدل الاكتفاء بتحسن مؤقت. احفظ النتيجة في checklist أو test يمكن تشغيله بعد الإصلاح. التشخيص الأمني الجيد يقلل البيانات التي يجمعها، لكنه يحتفظ بما يكفي لإثبات أين بدأت المشكلة وأين انتهت دون تخزين cookies أو tokens أو محتوى حسابات.

معيار القبول قبل الإغلاق

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

حالة فشل يجب اختبارها

في «Safe Logging: كيف تسجل الأخطاء بدون تخزين Cookies أو Tokens» أعد إنتاج الخطأ مرة تحت logging عادي ومرة تحت logging تشخيصي مؤقت، ثم قارن هل المعلومات الإضافية ساعدت فعلًا. إذا لم تضف قيمة، لا تحتفظ بها في الإنتاج. الهدف أن يكون كل حقل في السجل مرتبطًا بسؤال تشخيصي واضح، لا جمع بيانات احتياطيًا.