🛡️ Database Sentinel

مهارة Claude تُدقّق قواعد البيانات الخلفية لديك بحثًا عن الثغرات الأمنية.

ضعها في Claude Code أو Cursor أو أي بيئة تعمل بتقنية Claude. قل "دقّق قاعدة بياناتي" واحصل على تقرير أمني شامل مع كود إصلاح دقيق — في دقائق، لا أيام.

تم اختراق أكثر من 170 تطبيق Lovable. كُشف 20.1 مليون صف عبر شركات YC الناشئة. تُركت نحو 87,000 نسخة MongoDB عرضة لثغرة MongoBleed (CVE-2025-14847, CISA KEV). تسرّبت 1.8 مليون كلمة مرور Firebase في حادثة واحدة عام 2025. يُدخل 45% من الكود المُولَّد بالذكاء الاصطناعي ثغرات OWASP Top 10. يختبر Database Sentinel ما إذا كان تكوينك الأمني يعمل فعلًا — وليس فقط ما إذا كان موجودًا.

ماذا يفعل

ينفّذ Database Sentinel تدقيقًا أمنيًا من 7 خطوات على أيٍّ من الخلفيات التي يستخدمها مشروعك:

يكتشف الخلفيات التي تستخدمها (Supabase، Firebase، MongoDB، Postgres / MySQL مستضاف ذاتيًا)
يفحص قاعدة الكود بحثًا عن بيانات اعتماد مكشوفة ومفاتيح مكتوبة صراحةً وأسرار في git
يستكشف كل خلفية — المخطط، السياسات، القواعد، المستخدمون، الأدوار، الإعدادات
يطابق النتائج مع كتالوجات الأنماط المضادة الخاصة بكل خلفية المستمدة من CVEs وتقارير الاختراقات ومعايير CIS وأبحاث vibe-coding للأعوام 2025–2026
يجري فحوصات ديناميكية ببدائيات آمنة (tx=rollback, مجموعات كناري, كاشف MongoBleed اختياري)
يولّد تقريرًا أمنيًا بدرجة تقييم مع تفسيرات بلغة بسيطة وسيناريوهات مهاجم ملموسة
ينتج كود إصلاح دقيقًا — SQL DDL، ملفات قواعد، فروقات إعدادات، Terraform — انسخ والصق وانتهيت

يكشف الاستدلال عبر الخلفيات مشكلات لا تلتقطها الماسحات أحادية الخلفية (على سبيل المثال، معرّف Firebase Auth UID تثق به واجهة Postgres API دون التحقق من JWT).

الحالة

المرحلة	الخلفية	الحالة
1	Supabase	✅ صدرت
2	MongoDB (مستضاف ذاتيًا + Atlas)	✅ صدرت
3	Firebase (Firestore / RTDB / Storage / Functions / Remote Config)	🚧 مخطط لها
4	PostgreSQL (مستضاف ذاتيًا، بما في ذلك pgBouncer)	🚧 مخطط لها
5	MySQL (مستضاف ذاتيًا)	🚧 مخطط لها
6	تحليل التفاعلات عبر الخلفيات	🚧 مخطط لها
7	التوزيع والتحسين النهائي	🚧 مخطط لها

كان Database Sentinel يُعرف سابقًا باسم Supabase Sentinel (أحادي الخلفية). حدث تغيير الاسم خلال المرحلة 1 من التوسع متعدد الخلفيات. يحافظ غلاف التوافق الخلفي في compat/supabase-sentinel/ على اسم المهارة القديم حتى الإصدار الفرعي التالي على الأقل — لا يرى المستخدمون الحاليون أي تراجع.

بدء سريع

الخيار 1: Claude Code / Cursor

انسخ المهارة إلى دليل مهارات مشروعك، أو إلى دليل مركزي:

git clone https://github.com/Farenhytee/database-sentinel.git ~/claude-skills/database-sentinel

ثم اطلب من Claude:

Audit my database

سيكتشف Database Sentinel الخلفية (الخلفيات) التي يستخدمها مشروعك، وينفّذ عمليات التدقيق ذات الصلة، وينتج تقريرًا موحدًا. إذا وُجدت خلفيات متعددة (Firebase Auth + بيانات Postgres، إلخ)، سيتضمن التقرير قسم التفاعلات عبر الخلفيات بمجرد اكتمال المرحلة 6.

الخيار 2: استدعاء أحادي الخلفية

إذا أردت تدقيق خلفية معينة فقط، اطلب صراحة:

Audit my Supabase project
Audit my MongoDB instance

يضيّق المُوجّه (dispatcher) نطاق التدقيق.

الخيار 3: يدوي (أي مساعد ذكاء اصطناعي)

انسخ محتويات SKILL.md بالإضافة إلى ملف backends/<name>/workflow.md ذي الصلة إلى موجّه النظام لديك. مرّ بالخطوات السبع مستخدمًا بيانات اعتمادك.

ما يكتشفه

Supabase (المرحلة 1) — 27 نمطًا

الخطورة	النمط	الوصف
🔴 حرجة	`SB-001` `RLS_DISABLED`	جداول بدون أمان مستوى الصف (RLS) — مكشوفة بالكامل للإنترنت
🔴 حرجة	`SB-002` `SERVICE_ROLE_EXPOSED`	مفتاح service_role في كود الواجهة الأمامية — يتجاوز كل الأمان
🔴 حرجة	`SB-003` `POLICIES_BUT_NO_RLS`	سياسات مكتوبة لكن RLS غير مفعّل — أمان زائف
🔴 حرجة	`SB-005` `WRITE_USING_TRUE`	INSERT/UPDATE/DELETE مع `USING(true)` — يمكن لأي شخص تعديل البيانات
🟠 عالية	`SB-006` `USING_TRUE_SELECT`	جميع الصفوف قابلة للقراءة من المستخدمين المجهولين على الجداول الحساسة
🟠 عالية	`SB-007` `VIEW_NO_SECURITY_INVOKER`	العروض تتجاوز RLS وتعمل بصلاحيات المستخدم الخارق
🟠 عالية	`SB-008` `SECURITY_DEFINER_EXPOSED`	دوال في مخطط public تتجاوز RLS وقابلة للاستدعاء عبر API
🟠 عالية	`SB-009` `USER_METADATA_IN_POLICY`	سياسات تشير إلى بيانات وصفية يمكن للمستخدم تعديلها — تصعيد صلاحيات
🟠 عالية	`SB-010` `UPDATE_NO_WITHCHECK`	سياسات UPDATE بدون WITH CHECK — خطر الإسناد الجماعي
🟠 عالية	`SB-011` `GHOST_AUTH`	تسجيلات بالبريد غير المؤكد تمنح جلسات مصادقة
🟠 عالية	`SB-012` `STORAGE_NO_RLS`	Bucket تخزين بدون سياسات تحكم بالوصول
🟠 عالية	`SB-013` `JWT_SECRET_EXPOSED`	تسريب سر توقيع JWT — يمكن تزوير توكن أي مستخدم
🟡 متوسطة	+ 15 نمطًا إضافيًا	راجع `backends/supabase/anti-patterns.md`

MongoDB (المرحلة 2) — 20 نمطًا

الخطورة	النمط	الوصف
🔴 حرجة	`MG-SH-001` MongoBleed (CVE-2025-14847, CISA KEV)	كشف ذاكرة الكومة (Heap) قبل المصادقة عبر حزمة مضغوطة مُصمَّمة بعناية. نحو 87 ألف نسخة مكشوفة وقت الإفصاح.
🔴 حرجة	`MG-SH-002` المصادقة معطلة	mongod يعمل بدون مصادقة — سطح هجوم برمجية الفدية Meow
🔴 حرجة	`MG-SH-003` mongod موجّه للإنترنت	`--bind_ip_all` + منفذ 27017 قابل للوصول — يقترن مع `MG-SH-002` لاختراق كامل
🔴 حرجة	`MG-AT-001` قائمة السماح في Atlas `0.0.0.0/0`	مجموعة Atlas قابلة للوصول من أي مكان على الإنترنت
🟠 عالية	`MG-SH-004` تجاوز مصادقة localhost + تنفيذ في الحاوية	`enableLocalhostAuthBypass` true + وصول `docker exec`
🟠 عالية	`MG-SH-005` JavaScript من جانب الخادم مفعّلة	`$where` / `$function` / `mapReduce` قابلة للوصول — سطح هجوم NoSQL-RCE
🟠 عالية	`MG-SH-006` TLS غير مطلوب	حركة مرور نصية واضحة عبر الشبكة
🟠 عالية	`MG-SH-007` دور متميز على مستخدم التطبيق	يتصل التطبيق كـ `root` / `dbAdminAnyDatabase` إلخ
🟠 عالية	`MG-SH-008` مستند دور قابل للتعديل ذاتيًا	`findByIdAndUpdate(id, req.body)` + بدون مُتحقِّق + حقل دور
🟠 عالية	`MG-AT-002` دالة Atlas كعبور لقاعدة البيانات	حقن NoSQL عبر HTTPS — انتشر بعد إهمال Data API
🟠 عالية	`MG-AT-003` Data API من Atlas ما زالت في الكود	مُهمَلة في 30 سبتمبر 2025؛ معطَّلة ومن المرجح أن الاعتماد انتقل إلى Functions أقل تدقيقًا
🟡 متوسطة	`MG-SH-009` Mongoose < 8.9.5	CVE-2024-53900 / CVE-2025-23061 — حقن populate-match `$where`
🟡 متوسطة	+ 8 أنماط إضافية	راجع `backends/mongodb/anti-patterns.md`

يُشحن الفحص الشبكي لـ MongoBleed (backends/mongodb/mongobleed-probe.md) بكاشف حزمة واحدة يؤكد قابلية الاستغلال وقت التشغيل — تم التحقق منه ضد mongo:7.0.20 (قابل للاستغلال) و mongo:7.0.28 (مصحَّح). إنه للقراءة فقط، ومقيد بموافقتين اختياريتين، ولا يستخرج المحتوى أبدًا.

مثال على المخرجات

╔════════════════════════════════════════════════════════╗
║                  SENTINEL SECURITY AUDIT               ║
╠════════════════════════════════════════════════════════╣
║  Backends:   supabase, mongodb                         ║
║  Scanned:    2026-04-30 14:30 UTC                      ║
║  Score:      0/100 🔴                                  ║
║  Summary:    2 backends, 8 findings (3C / 4H / 1M)     ║
╚════════════════════════════════════════════════════════╝

─────────────────────────────────────────────────────────
  Supabase                                       35/100 🔴
─────────────────────────────────────────────────────────

🔴 CRITICAL — public.users: RLS Disabled                  [SB-001]

  Risk:     Anyone on the internet can read your entire users table.
  Attack:   Open browser DevTools → copy anon key → curl the API → dump
            all emails, names, and metadata.
  Proof:    curl returns [{"id":"...","email":"[email protected]",...}]
  Source:   CVE-2025-48757 / Splinter 0013_rls_disabled_in_public

  Fix:
  ALTER TABLE public.users ENABLE ROW LEVEL SECURITY;

  CREATE POLICY "users_select_own"
    ON public.users FOR SELECT TO authenticated
    USING ((SELECT auth.uid()) = id);

─────────────────────────────────────────────────────────
  MongoDB                                         0/100 🔴
─────────────────────────────────────────────────────────

الأكثر شعبية

database-sentinel