نتائج تدقيق الأمان: لماذا شعرت بالإحراج
أجريت مؤخرًا تدقيقًا أمنيًا على جميع مشاريعي الجانبية. يشمل ذلك الواجهة الخلفية لـ FastAPI، وبوتات Telegram، وتطبيقات PWA، وتطبيقات Streamlit.
كنت أظن أن الكود الخاص بي آمن لأنني كنت حذرًا. لكنني كنت مخطئًا.
أنا أشارك هذه الأخطاء البرمجية الحقيقية من بيئة الإنتاج لمساعدتكم على تجنبها. هذه ليست مجرد قوائم مراجعة نظرية، بل هي أخطاء ارتكبتها بالفعل.
فخ المصادقة الشرطية كتبت كودًا يتحقق مما إذا كان سر الـ API موجودًا قبل التحقق منه. إذا كانت متغيرات البيئة (environment variable) مفقودة، يتم تخطي عملية التحقق تمامًا. وهذا يعني أن واجهة برمجة التطبيقات (API) الخاصة بي بالكامل كانت مفتوحة للعامة. القاعدة: إذا كان السر مفقودًا، يجب إيقاف العملية فورًا مع إرجاع خطأ 500. لا تتخطى المصادقة أبدًا.
تسريب سجل Git قمت ذات مرة بكتابة مفتاح API بشكل مباشر (hardcoded) لإجراء اختبار سريع. قمت بنقله لاحقًا إلى ملف
.envواعتقدت أن المشكلة قد حُلت. لكن Git يتذكر كل شيء؛ يمكن لأي شخص العثور على ذلك المفتاح في سجل الـ commits الخاص بي. القاعدة: إذا قمت بعمل commit لمفتاح ما، فافترض أنه قد سُرق. قم بتغييره (Rotate) فورًا. استخدمgit-filter-repoلتنظيف سجلك.تسريب نقطة نهاية التصحيح (Debug Endpoint) تركت نقطة نهاية
/debug/configفي بيئة الإنتاج لمساعدتي في استكشاف الأخطاء وإصلاحها. لقد كشفت هذه النقطة عن روابط قواعد البيانات وإعدادات البيئة الخاصة بي. القاعدة: قم بإزالة جميع نقاط نهاية التصحيح قبل النشر. استخدم السجلات (logs) بدلاً من ذلك.تسريب معلومات النظام عبر الأخطاء استخدمت
str(e)في استجابات الخطأ الخاصة بي. أدى ذلك إلى إرسال أخطاء قاعدة البيانات ومسارات الملفات مباشرة إلى المستخدم. يستخدم المهاجمون هذه المعلومات لرسم خريطة لبنيتك التحتية. القاعدة: قم بتسجيل الخطأ التفصيلي لنفسك في السجلات. أرسل رسالة عامة مثل "Internal Server Error" إلى العميل.مخاطر XSS في الواجهة الأمامية (Frontend) استخدمت
innerHTMLلعرض محتوى المستخدم. سمح هذا بتشغيل برمجيات نصية (scripts) في متصفحات المستخدمين الآخرين. القاعدة: قم دائمًا بعمل escape لـ HTML. تعامل معinnerHTMLكوسيلة لتنفيذ كود عشوائي.غياب حدود معدل الطلبات (Rate Limits) كانت لدي نقاط نهاية تستدعي نماذج ذكاء اصطناعي مكلفة دون أي قيود. حلقة تكرارية واحدة أو مفتاح مسروق قد يكلفني مئات الدولارات. القاعدة: المصادقة تمنع المستخدمين غير المصرح لهم. أما تحديد معدل الطلبات (Rate limiting) فيمنع المستخدمين المصرح لهم من إساءة استخدام نظامك.
سياسة CORS متساهلة استخدمت
allow_origins=["*"]في بيئة الإنتاج. هذا يسمح لأي موقع بإرسال طلبات إلى واجهة برمجة التطبيقات (API) الخاصة بك. القاعدة: اسمح فقط بنطاق (domain) الواجهة الأمامية الخاص بك.The Temporary File Leak If my code crashed while processing a file, the temporary file stayed on the disk forever. This wastes space and leaks sensitive data. Rule: Use try-finally blocks to ensure files are deleted even if an error occurs.
My new mandatory checklist:
Before coding: • Create a .gitignore • Create a .env.example
For every endpoint: • Add authentication • Use generic error messages • Add rate limits to expensive tasks
Before committing: • Scan for secrets in your diff
Before deploying: • Run security audits on your dependencies
Security issues do not happen by accident. They happen because of "TODO" comments and "temporary" fixes that stay in production forever.
Fixing a bug is boring. Fixing a breach is expensive.