Replit كشف ملف .env الخاص بك — أمّن تطبيقك المبني بالذكاء الاصطناعي قبل الإطلاق

لقد وصفت تطبيقاً لـ Replit، فبناه لك، ونشرته في فترة بعد الظهر. هذا مثير للإعجاب حقاً — وهو أيضاً حيث تبدأ المخاطر. التطبيقات المبنية بالذكاء الاصطناعي تُطلَق غير آمنة افتراضياً: نحو 91.5% منها يحمل عيباً واحداً على الأقل، ووجدت دراسة من CMU أنه بينما 61% من الكود المولَّد بالذكاء الاصطناعي صحيح وظيفياً، فإن نحو 10.5% فقط منه يجتاز مراجعة أمنية. فحصت Escape.tech 5,600 من هذه التطبيقات فوجدت 2,038 ثغرة حرجة، وأكثر من 400 سرّ مكشوف، و175 تسريباً للبيانات الشخصية. في Replit تحديداً، الطريقة الأكثر شيوعاً التي يتضرر بها المؤسسون هي كشف الأسرار في عمليات النشر الافتراضية — أي وصول ملف .env، أو القيم بداخله، إلى الإنترنت العام. يشرح هذا المقال سبب حدوث ذلك، وكيفية الفحص عنه، وكيفية إصلاحه قبل الإطلاق.

لماذا يحدث كشف ملف .env افتراضياً

ملف .env هو مجرد ملف نصي عادي موجود في مجلد مشروعك، يحمل رابط قاعدة البيانات ومفاتيح API والرموز على هيئة أزواج مفتاح-قيمة. لم يكن مقصوداً به أبداً أن يغادر الخادم. تنشأ مشكلة الكشف من عادتين يشجّعهما بناة الذكاء الاصطناعي دون تحذيرك. أولاً، تُرفَع الأسرار مع الكود بدلاً من إبقائها خارج نظام التحكم بالإصدارات، فيتمكن أي شخص يرى المستودع من قراءتها. ثانياً — وهذا هو الفخ الخاص بـ Replit — عندما يُنشَر المشروع كموقع ثابت (static) أو بخادم ويب مُهيَّأ بشكل خاطئ، يمكن أن تُقدَّم الملفات الموجودة في جذر المشروع عبر HTTP. إذا كان جذر الويب العام لتطبيقك هو نفس المجلد الذي يحتوي على .env، فإن طلباً إلى your-app-url/.env قد يعيد محتويات الملف حرفياً. لا استغلال، ولا اختراق ذكي: مجرد رابط. ولأن الإعداد الافتراضي يُحسِّن من أجل 'أنه يعمل وهو مباشر'، يسهُل أن تتلاشى الحدود بين 'الملفات التي أُرسلها للمتصفح' و'الملفات التي يجب أن تبقى على الخادم'.

كيف تتحقق مما إذا كنت مكشوفاً

يمكنك اكتشاف معظم هذا بنفسك في دقائق قليلة، ويجب أن تفعل ذلك قبل أن تخبر أي أحد بإطلاقك. أسرع إشارة هي ببساطة زيارة رابط تطبيقك المنشور مع إضافة /.env في نهايته، ورؤية ما إذا كان يعود أي شيء غير خطأ 404. افعل الشيء نفسه للنُسخ الشائعة مثل /.env.local و /.git/config وأي ملفات إعداد أو نسخ احتياطية قد يكون الذكاء الاصطناعي تركها في الجذر. ثم افحص تاريخ مستودعك: ابحث في التزاماتك (commits) عن المفاتيح والرموز ونص رابط اتصال قاعدة البيانات، لأن السرّ الذي رُفِع مرة واحدة يبقى في التاريخ حتى بعد حذفك للملف. أخيراً، انظر إلى ما يُرسَل فعلياً إلى المتصفح — افتح موقعك، واعرض مصدر الصفحة وعلامة تبويب الشبكة (network)، وتأكد من عدم وجود أي مفتاح API أو رمز خاص مضمَّن في حزمة العميل. السرّ الذي يستطيع المتصفح قراءته هو سرّ يستطيع الإنترنت كله قراءته.

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

كيف تُصلحه قبل الإطلاق

إصلاح الكشف لا يتعلق بأمر واحد بقدر ما يتعلق باستعادة الحدود التي محاها الإعداد الافتراضي. الهدف هو أن تعيش الأسرار فقط في مخزن أسرار على جانب الخادم — ومدير Secrets الخاص بـ Replit موجود لهذا الغرض تماماً — وألا تكون أبداً في ملف يستطيع خادم الويب تقديمه أو يُرفَع إلى Git. أي شيء يحتاجه المتصفح فعلاً (مفتاح عام قابل للنشر مثلاً) لا بأس بإرساله؛ أما أي شيء يمنح صلاحية الكتابة، أو يُنفق مالاً، أو يقرأ بيانات خاصة، فيجب أن يبقى على الخادم خلف مسار مُصادَق عليه. وهناك خطوة يتجاهلها الناس لأنها تبدو عملاً إضافياً: إذا كُشِف سرّ في أي وقت، ولو للحظة، فاعتبره محروقاً وقُم بتدويره (rotate). حذف الملف لا يُلغي تسرّب القيمة. القائمة أدناه هي النسخة العملية من كل هذا.

• —انقل كل سرّ من الملفات إلى مدير Secrets في Replit (أو متغيرات البيئة لدى مزوّد الاستضافة)؛ ولا يبقى أي شيء حسّاس في ملف .env داخل التطبيق المنشور.
• —أضف .env و .env.local و .git إلى ملف .gitignore، ثم تحقق بنسخة نظيفة من المستودع أنها لم تعد متتبَّعة.
• —زُر your-app-url/.env و /.env.local و /.git/config في المتصفح وتأكد أن كلاً منها يعيد خطأ 404 (لا محتوى الملف).
• —ابحث في كامل تاريخ الالتزامات عن المفاتيح ورابط قاعدة بياناتك؛ وإذا رُفِع أي سرّ يوماً ما، فقم بتدويره الآن.
• —قم بتدوير أي سرّ سبق كشفه — كلمة مرور جديدة لقاعدة البيانات، مفاتيح API جديدة — وحدّثها فقط داخل مخزن الأسرار.
• —اعرض مصدر الصفحة وعلامة تبويب الشبكة على الموقع المباشر؛ وتأكد من عدم وجود أي مفتاح خاص أو رمز في حزمة العميل.
• —تأكد أن أي نقطة نهاية تقرأ أو تكتب بيانات خاصة تتطلب مصادقة وتتحقق من أن المُستدعي يملك السجل.

هذه ليست مشكلة Replit وحدها

لكل باني ذكاء اصطناعي نقطة ضعف افتراضية خاصة به، لذا إذا استخدمت أكثر من أداة، فافحص وضع الفشل المطابق. تُطلَق تطبيقات Lovable عادةً بأمان مستوى الصفوف (RLS) في Supabase مفقوداً أو معطلاً، ما يعني أن قاعدة البيانات نفسها لا تفرض من يستطيع قراءة ماذا. وتميل Bolt.new إلى تضمين الأسرار مباشرة في حزمة العميل. وغالباً ما تعاني واجهات API المبنية بـ Cursor من خلل في التفويض على مستوى الكائن (BOLA)، حيث يتيح تغيير مُعرِّف (ID) في الطلب لمستخدم أن يقرأ سجل مستخدم آخر. وكثيراً ما تترك v0 مسارات API دون مصادقة. الخيط المشترك هو نفسه في مشكلة .env لدى Replit: الأداة تُحسِّن من أجل عرض توضيحي يعمل، وتُترَك الحدود الأمنية كتمرين لك. وهذا ليس سبباً للتوقف عن الإطلاق بالذكاء الاصطناعي — بل سبب لإجراء مراجعة حقيقية قبل الإطلاق، ولوضع التزامات الامتثال مثل PDPL أو GDPR في الحسبان لحظة تخزينك لبيانات أي شخص الشخصية.

نفّذ القائمة أعلاه وستُغلق أكثر الطرق شيوعاً التي تُسرِّب بها تطبيقات Replit — وإذا كنت تفضّل أن يتولى مهندسو برمجيات وأمن كبار إنهاءه وتأمينه وإطلاقه نيابةً عنك بدلاً من مجرد فحصه وتسليمك قائمة، فهذا بالضبط ما تفعله Comestare.