1. المشكلة: كتابة المفاتيح مباشرة في الكود
لما تكتب مفتاح API أو كلمة مرور قاعدة البيانات مباشرة جوه ملف الكود، وترفع الكود ده على GitHub (حتى لو في Repository خاص)، بيبقى المفتاح موجود في تاريخ المشروع بالكامل — وأي شخص وصل للـ Repository، أو أي أداة فحصت الكود تلقائيًا، ممكن تلاقيه.
2. الحل: Environment Variables
بدل كتابة المفتاح مباشرة، بتخزّنه كمتغيّر بيئة (Environment Variable) في مكان منفصل عن الكود — في إعدادات الاستضافة نفسها (Heroku، Azure، Appwrite، إلخ) أو في ملف `.env` محلي لا يُرفع على GitHub أبدًا. الكود بعدين بيقرأ القيمة من البيئة وقت التشغيل، مش بيحتفظ بها فيه.
القاعدة الذهبية: أي مفتاح، كلمة مرور، أو Token — لو ظهر داخل ملف كود بيُرفع لـ Git، فهو مكشوف. لا استثناءات.
3. لا تنسَ .gitignore
ملف `.env` نفسه (اللي بيحتوي القيم الفعلية محليًا) لازم يكون مُدرجًا في `.gitignore` من أول يوم في المشروع، عشان ما يترفعش بالغلط مع أول Commit.
4. ماذا لو المفتاح اتسرّب بالفعل؟
حذف المفتاح من الكود لوحده مش كافي — لو كان موجودًا في تاريخ الـ Repository ولو لمرة واحدة، يُعتبر مكشوفًا. الإجراء الصحيح هو تغيير المفتاح نفسه (Rotate) من مصدره (لوحة تحكم الخدمة نفسها)، مش بس حذفه من الملف.
5. لمشاريع أكبر: Secrets Management
مع نمو المشروع وزيادة عدد المفاتيح والبيئات (Development، Staging، Production)، إدارة كل ده يدويًا بيبقى صعب ومعرّض للخطأ. هنا بييجي دور إدارة مركزية للمفاتيح (Secrets Management) بتنظّمها وتربطها بعملية النشر بشكل آمن.
خلاصة سريعة
- لا تكتب أي مفتاح أو كلمة مرور مباشرة داخل ملفات الكود.
- استخدم Environment Variables، وخزّنها في إعدادات الاستضافة أو ملف `.env` غير مرفوع.
- أضف `.env` إلى `.gitignore` من أول يوم.
- أي مفتاح اتسرّب ولو مرة، غيّره فورًا — لا تكتفِ بالحذف.