في 20 مايو 2026، أكدت GitHub أن مهاجمين سرقوا بيانات من حوالي 3800 مستودع شيفرة داخلي. لم تكن نقطة الدخول ثغرة يوم-صفر في خوادم GitHub، بل إضافة VS Code مخترقة مثبتة على حاسوب محمول لموظف واحد. عندما تعمل الإضافة بصلاحيات المطور نفسها، يمكنها قراءة الشيفرة، ملفات التهيئة، وبيانات الاعتماد الموجودة في مساحة العمل. الدرس العملي: لا تفترض أن السحابة هي نقطة الضعف دائمًا؛ جهاز المطور والأدوات التي تعمل عليه غالبًا هي السطح الأخطر.

جرّب Apidog اليوم

TL;DR

لحماية مفاتيح API من إضافات IDE المخترقة أو المستودعات المسربة:

• لا تضع مفاتيح حية داخل الشيفرة.
• لا تلتزم بملفات .env.
• لا تعتبر .gitignore تحكمًا أمنيًا.
• افصل مفاتيح التطوير، الاختبار، والإنتاج.
• استخدم أقل الامتيازات وأقصر مدة صلاحية ممكنة.
• دوّر المفاتيح وفق جدول ثابت.
• خزّن بيانات اعتماد API في متغيرات بيئة أو مدير أسرار بدل ملفات نصية داخل مساحة العمل.

تساعد أدوات مثل Apidog في تقليل التعرض عبر تخزين بيانات اعتماد API كمتغيرات بيئة بقيم محلية فقط، بدل نشرها كنص عادي في المستودع أو ملفات المشروع.

لماذا يُعد اختراق GitHub جرس إنذار لكل مطور

تبدو حادثة GitHub كهجوم سلسلة توريد عملي. المجموعة المهددة، المعروفة باسم TeamPCP، لها تاريخ في إدخال أحصنة طروادة في حزم عبر npm وPyPI وPHP. هذه المرة جاءت الحمولة الخبيثة عبر إضافة VS Code.

وفقًا لتقرير TechCrunch، سرّب المهاجمون بيانات من حوالي 3800 مستودع داخلي، ويبيعون مجموعة البيانات بأكثر من 50,000 دولار في المنتديات السرية. تقول GitHub إنه لا يوجد دليل على تأثر بيانات العملاء المخزنة خارج تلك المستودعات الداخلية، والتحقيق مستمر.

النقطة العملية للمطورين: إضافة VS Code هي كود يعمل داخل المحرر بصلاحيات المستخدم. يمكنها عادةً:

• سرد الملفات داخل مساحة العمل.
• فتح الملفات وقراءة محتواها.
• مراقبة تغييرات الملفات.
• إرسال طلبات شبكة خارجية.

هذا ليس بالضرورة خللًا في VS Code؛ إنه جزء من نموذج الإضافات. كثير من الإضافات تحتاج الوصول إلى الملفات كي تعمل. المشكلة أن إضافة خبيثة أو مخترقة تستخدم الوصول نفسه لجمع الأسرار.

في مشروع عادي، قد تجد الإضافة:

• ملف .env في جذر المشروع.
• ملفات مثل config/secrets.yml.
• توكن مؤقت داخل سكريبت اختبار.
• بيانات AWS في ~/.aws/credentials.
• ملف .npmrc يحتوي رمز مصادقة.
• مفاتيح SSH.
• رموز CI/CD أو أدوات ذكاء اصطناعي.

هذا النمط مشابه لما ناقشناه في دروس أمان API من اختراق Vercel، ويتقاطع مع آليات سلسلة التوريد التي غطيناها في دليل أمان سلسلة توريد npm.

السؤال العملي الذي يجب أن تطرحه الآن:

إذا عملت إضافة خبيثة داخل محررك اليوم، ما الأسرار التي ستجدها؟

المفاتيح المبرمجة ثابتًا وملفات .env الملتزم بها مشكلة دائمة

معظم تسريبات بيانات الاعتماد لا تحتاج هجومًا معقدًا. غالبًا تبدأ بأحد هذين الخطأين:

1. مطور يلصق مفتاحًا داخل الشيفرة "مؤقتًا".
2. ملف .env يدخل في commit بالخطأ.

مثال واضح على الخطأ الأول:

import requests

# Quick test of the payments endpoint
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"

response = requests.post(
    "https://api.stripe.com/v1/charges",
    auth=(STRIPE_KEY, ""),
    data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)

print(response.json())

هذا المفتاح أصبح الآن:

• موجودًا كنص عادي داخل الملف.
• قابلًا للقراءة من أي إضافة أو أداة محلية.
• جزءًا من سجل Git إذا تم الالتزام بالملف.
• قابلًا للاسترجاع حتى لو حذفت السطر في commit لاحق.

هل يحل .env المشكلة؟

ملف .env أفضل من hardcoding، لكنه ليس حلًا كاملًا. مثال:

# .env  (loaded at runtime, never meant to ship)
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350

هذا النمط يحل مشكلة واحدة فقط: إبقاء الأسرار خارج الشيفرة إذا لم يتم الالتزام بالملف أبدًا.

لكنه لا يحل مشكلة الأداة المحلية المخترقة. بالنسبة لإضافة خبيثة، لا يوجد فرق كبير بين:

• app.py
• .env
• config/secrets.yml

كلها ملفات نصية يمكن قراءتها من نظام الملفات.

إذا تم الالتزام بملف .env مرة واحدة، فالمفتاح أصبح في سجل Git. حتى بعد حذفه لاحقًا، تبقى القيمة في التاريخ. ناقشنا زاوية تسرب المستودعات بتفصيل أكبر في مقال توثيق API وأمان مستودع Git.

.gitignore ليس تحكمًا أمنيًا

إضافة .env إلى .gitignore خطوة جيدة، لكنها ليست دفاعًا أمنيًا. هي فقط تعليمات لـ Git كي يتجاهل ملفات غير متعقبة عند git add.

لها ثلاث نقاط فشل مهمة.

1. لا تؤثر على الملفات المتعقبة مسبقًا

إذا تم الالتزام بـ .env قبل إضافته إلى .gitignore، سيستمر Git في تتبعه.

تحتاج إلى:

git rm --cached .env
git commit -m "Stop tracking .env"

لكن هذا لا يزيل السر من التاريخ السابق.

2. لا تحمي الملف الموجود على القرص

حتى لو تجاهله Git، يبقى .env في مساحة العمل كنص عادي. إضافة VS Code خبيثة لا تحتاج فهرس Git؛ يمكنها قراءة الملف مباشرة.

3. يمكن تجاوزها بسهولة

يمكن تجاوز القاعدة عبر:

git add -f .env

أو عبر واجهة تحكم مصدر داخل محرر، أو عبر قواعد .gitignore غير متسقة في مجلدات فرعية.

كيف تفحص سجل Git بحثًا عن .env

ابدأ بهذه الأوامر:

# اعرض كل commit لمس ملف .env
git log --all --full-history --oneline -- .env

# ابحث عن قيم حساسة داخل التاريخ
git log -p --all -- .env | grep -iE "key|secret|token|password"

إذا ظهر أي شيء، تعامل مع السر على أنه مكشوف.

الإجراء الصحيح:

1. دوّر المفتاح فورًا.
2. أوقف القيمة القديمة.
3. نظّف السجل باستخدام أداة مثل git filter-repo.
4. ادفع التاريخ النظيف بعد التنسيق مع الفريق.
5. انقل الأسرار إلى مكان لا يكون ملفًا نصيًا داخل مساحة العمل.

أربع عادات تقلل أثر التسريب

لا يمكنك ضمان عدم تسرب أي مفتاح أبدًا. لكن يمكنك جعل المفتاح المسرب قليل القيمة.

1. حدّد نطاق كل سر حسب البيئة

لا تستخدم المفتاح نفسه في:

• التطوير
• الاختبار
• الإنتاج

بدلًا من ذلك:

إذا تسرب مفتاح التطوير، يجب أن يصل المهاجم إلى بيئة تجريبية فقط، لا إلى بيانات العملاء.

2. افصل البيئات فعليًا

الفصل لا يعني فقط أسماء مفاتيح مختلفة. يجب أن تكون الموارد نفسها منفصلة:

• قاعدة بيانات التطوير ليست نسخة إنتاج حية.
• مزود الدفع في الاختبار يستخدم sandbox.
• إعدادات التطوير لا يمكنها الوصول إلى بيانات الإنتاج بتغيير متغير واحد.
• مفاتيح الإنتاج لا تُنسخ إلى أجهزة المطورين.

هدفك أن يكون سؤال "من أي بيئة جاء هذا المفتاح؟" قابلًا للإجابة فورًا.

3. استخدم أقل الامتيازات وأقصر مدة صلاحية

كل مفتاح يجب أن يمتلك أقل صلاحيات ممكنة.

مثال:

• واجهة أمامية تقرأ كتالوج منتجات عام: مفتاح قراءة فقط.
• سكريبت CI ينشر توثيقًا: صلاحية النشر المطلوبة فقط.
• خدمة دفع: صلاحيات محددة لنطاق الدفع، لا صلاحيات إدارية عامة.

إذا كان مزود API يدعم رموزًا قصيرة الأجل أو OAuth، ففضّلها على المفاتيح الثابتة. راجع مقارنة مفاتيح API مقابل OAuth لمعرفة متى تكون الرموز قصيرة الأجل أفضل.

قاعدة عملية:

• مفتاح ينتهي خلال ساعة: ضرره محدود.
• مفتاح يعيش إلى الأبد: يظل صالحًا حتى يلاحظه أحد، وقد يستغرق ذلك شهورًا.

4. دوّر المفاتيح وفق جدول ثابت

لا تنتظر حادثًا كي تتعلم تدوير المفاتيح.

ضع جدولًا واضحًا:

• مفاتيح إنتاج عالية الامتيازات: شهريًا.
• مفاتيح أقل خطورة: ربع سنويًا.
• مفاتيح مؤقتة أو تجريبية: أقصر ما يمكن.

التدوير المنتظم يحقق فائدتين:

1. يقلل عمر أي تسريب غير مكتشف.
2. يجعل عملية التدوير إجراءً معتادًا لا حالة طوارئ.

لإدارة أوسع، راجع أدوات إدارة مفاتيح API.

احتفظ ببيانات الاعتماد في متغيرات بيئة Apidog بدل نشرها في مساحة العمل

تقدم Apidog إضافة VS Code وخادم MCP. الهدف هنا ليس الادعاء بأن أي أداة عميل محصنة ضد هجمات سلسلة التوريد. لا توجد أداة من جانب العميل محصنة بالكامل.

النقطة العملية هي: أين تعيش أسرارك؟

عند بناء واختبار API، تحتاج غالبًا إلى:

• bearer token
• API key
• base URL
• database connection string
• credentials للاختبار

الحل السريع المعتاد هو وضعها في .env أو سكريبت محلي. هذا يضع الأسرار الحية في ملفات نصية داخل مساحة العمل، وهي بالضبط الملفات التي تستهدفها الإضافات الخبيثة.

استخدم متغيرات البيئة بدل النصوص الصريحة

في Apidog، يمكنك تخزين بيانات الاعتماد كـ متغيرات بيئة.

بدل كتابة التوكن مباشرة:

Authorization: Bearer sk-proj-aB3dEf9hKlMnOpQrStUvWxYz

اكتب:

Authorization: Bearer {{access_token}}

ويقوم Apidog بحل القيمة وقت الإرسال.

الميزة العملية: تعريف الطلب لا يحتوي السر الحرفي. السر لا يجلس داخل .env في جذر المشروع ولا داخل ملف قابل للالتزام.

استخدم القيم المحلية للأسرار

يميز Apidog بين نوعين من القيم لكل متغير:

• قيمة مشتركة أو أولية: يمكن أن تتزامن وتكون مرئية للفريق.
• قيمة محلية أو حالية: تبقى على جهازك ولا يتم تحميلها.

للأسرار مثل التوكنات وكلمات المرور، استخدم القيمة المحلية فقط.

النتيجة:

• يرى الفريق اسم المتغير مثل access_token.
• لا يرى الفريق القيمة السرية الخاصة بك.
• كل مطور يملأ قيمته المحلية.
• لا تنتقل مفاتيح الإنتاج عبر بيانات المشروع المتزامنة.

افصل البيئات داخل Apidog

تستند إدارة بيئة Apidog إلى فكرة العزل.

يمكنك تعريف بيئات مثل:

• Development
• Staging
• Production

كل بيئة تحتوي:

• base_url
• access_token
• payment_api_key
• أي متغيرات أخرى خاصة بها

مثال عملي:

Development:
  base_url = https://dev.example.com
  payment_api_key = sandbox_key

Production:
  base_url = https://api.example.com
  payment_api_key = production_key

عند التبديل بين البيئات، تتبدل مجموعة القيم بالكامل. لا تحتاج إلى تعديل الطلب نفسه.

هذا يقلل أخطاء مثل:

• استخدام مفتاح إنتاج في طلب تطوير.
• إرسال طلب اختباري إلى API إنتاجي.
• تخزين سر إنتاجي داخل مساحة عمل تطوير محلية.

للفرق التي تحتاج حدودًا أقوى: Vault Secret

إذا كان فريقك لا يريد أن تلمس أسرار الإنتاج عميل API أصلًا، تضيف خطة Apidog Enterprise ميزة Vault Secret.

تسمح هذه الميزة بجلب الأسرار من:

• HashiCorp Vault
• Azure Key Vault
• AWS Secrets Manager

في هذا النمط، يخزن Apidog مسار السر والبيانات الوصفية فقط. يتم جلب القيم عند الطلب، وتبقى إدارة السر في مدير الأسرار المخصص.

لتجربة سير العمل الأساسي، قم بتنزيل Apidog، أنشئ مشروعًا، افتح إدارة البيئة، وأضف بيانات اعتمادك كمتغيرات بيئة بقيم محلية فقط.

تحذير مهم: نقل الأسرار إلى Apidog يقلل عدد الأسرار النصية داخل المستودع ومساحة العمل، لكنه لا يجعل جهازك محصنًا. لا يزال عليك تدقيق الإضافات، تقليل صلاحيات المفاتيح، وتدويرها بانتظام.

قائمة تنفيذ سريعة

استخدم هذه القائمة على مستودعك الحالي.

1. ابحث عن أسرار داخل الملفات

grep -RniE "api[_-]?key|secret|token|password|authorization|bearer" .

استثنِ مجلدات مثل node_modules عند الحاجة:

grep -RniE "api[_-]?key|secret|token|password|authorization|bearer" . \
  --exclude-dir=node_modules \
  --exclude-dir=.git

2. افحص سجل Git

git log -p --all | grep -iE "api[_-]?key|secret|token|password|authorization|bearer"

3. تحقق من الملفات الحساسة المتعقبة

git ls-files | grep -E "\.env|secrets|credentials|\.npmrc|\.pypirc"

4. أضف قواعد تجاهل مناسبة

.env
.env.*
!.env.example

*.pem
*.key
*.p12

.aws/
.npmrc
.pypirc

تذكر: هذا يمنع أخطاء مستقبلية، لكنه لا يحمي ملفًا موجودًا على القرص ولا ينظف التاريخ.

5. أنشئ ملف مثال آمن

بدل مشاركة .env حقيقي، شارك .env.example بلا أسرار:

DATABASE_URL=
STRIPE_SECRET_KEY=
OPENAI_API_KEY=
JWT_SIGNING_SECRET=

6. دوّر أي مفتاح ظهر في الشيفرة أو التاريخ

لا تكتفِ بحذف السطر. إذا ظهر المفتاح في Git، اعتبره مكشوفًا.

الخلاصة

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

ابدأ بخطوات عملية:

1. ابحث عن key وsecret وtoken وpassword في مستودعاتك.
2. افحص سجل Git لملفات .env والأسرار القديمة.
3. دوّر أي قيمة ظهرت في الشيفرة أو التاريخ.
4. افصل مفاتيح التطوير والاختبار والإنتاج.
5. استخدم أقل الامتيازات وأقصر مدة صلاحية.
6. انقل بيانات اعتماد API إلى متغيرات بيئة أو مدير أسرار.

يمكنك تنزيل Apidog واستخدام متغيرات البيئة بقيم محلية بدل تخزين بيانات الاعتماد في ملف نصي داخل المشروع.

للمتابعة، اقرأ أيضًا أدوات API المستضافة ذاتيًا بعد اختراق GitHub وأدوات إدارة مفاتيح API.

الأسئلة الشائعة

هل يمكن لإضافة VS Code قراءة ملف .env ومفاتيح API؟

نعم. تعمل إضافة VS Code بصلاحيات المستخدم داخل المحرر. يمكنها قراءة الملفات في مساحة العمل، بما في ذلك .env وملفات التهيئة وملفات بيانات الاعتماد مثل ~/.aws/credentials. هذا جزء طبيعي من نموذج الإضافات، لكنه يصبح خطرًا عندما تكون الإضافة خبيثة أو مخترقة.

هل يكفي إضافة .env إلى .gitignore؟

لا. .gitignore يمنع Git من إضافة الملفات غير المتعقبة تلقائيًا، لكنه لا:

• يحذف أسرارًا موجودة في سجل Git.
• يحمي الملف الموجود على القرص.
• يمنع أداة محلية من قراءة الملف.
• يمنع استخدام git add -f.

استخدمه كوسيلة نظافة، لا كحد أمني.

ماذا أفعل إذا وجدت مفتاح API في سجل Git؟

تعامل معه كمفتاح مكشوف:

1. دوّر المفتاح فورًا.
2. عطّل القيمة القديمة.
3. نظّف سجل Git باستخدام أداة مثل git filter-repo.
4. نسّق مع الفريق قبل force-push.
5. انقل السر إلى مدير أسرار أو متغيرات بيئة لا تُلتزم بالمستودع.

كيف يقلل Apidog تعرض مفاتيح API للخطر؟

يسمح Apidog بتخزين بيانات الاعتماد كمتغيرات بيئة والإشارة إليها بالاسم داخل الطلبات، مثل {{access_token}}. كما يدعم القيم المحلية التي تبقى على جهازك ولا تتزامن مع الفريق. هذا يقلل وجود الأسرار كنص عادي داخل ملفات المشروع، لكنه لا يلغي الحاجة إلى أقل الامتيازات، التدوير، وتدقيق الأدوات المحلية.

هل وجود إضافة Apidog لـ VS Code يمثل خطرًا؟

أي إضافة عميل يمكن أن تكون جزءًا من سطح الهجوم إذا اختُرقت. الهدف ليس افتراض أن أداة معينة محصنة، بل تقليل عدد الأسرار النصية الموجودة في مساحة العمل. احتفظ بالأسرار في متغيرات محلية أو مدير أسرار، وراجع الإضافات التي تثبتها، ودوّر المفاتيح بانتظام.

ما الفرق بين تحديد النطاق والتدوير؟

تحديد النطاق يحدد ما يمكن للمفتاح فعله وأين يعمل. مثال: مفتاح تطوير لا يصل إلى الإنتاج، ومفتاح قراءة فقط لا يستطيع الكتابة.

التدوير يغير قيمة المفتاح بحيث تتوقف القيمة القديمة عن العمل.

تحتاج الاثنين معًا: النطاق يقلل الضرر، والتدوير يقلل مدة صلاحية المفتاح المسرب.

كم مرة يجب تدوير مفاتيح API؟

ابدأ بقاعدة عملية:

• مفاتيح الإنتاج عالية الامتيازات: شهريًا.
• المفاتيح الأقل خطورة: ربع سنويًا.
• الرموز المؤقتة: أقصر مدة ممكنة.

عدّل الجدول حسب مستوى المخاطر ومتطلبات الامتثال.

هل يجب أن تكون مفاتيح الإنتاج على جهاز المطور؟

يفضل ألا تكون كذلك. يجب أن تبقى بيانات اعتماد الإنتاج في مدير أسرار وبيئات التشغيل الإنتاجية فقط. يجب أن يعمل المطورون بمفاتيح تطوير أو اختبار محددة النطاق. إذا اختُرق جهاز مطور، يجب أن يصل المهاجم إلى sandbox فقط، لا إلى أنظمة العملاء الحية.