FixVibe

// docs / security guides / pre-ship checklist

قائمة فحص أمان vibe coding: 44 عنصرًا قبل الإطلاق

قائمة مرجعية عملية ومنظمة على مراحل للتطبيقات التي تم إنشاؤها باستخدام Cursor وClaude Code وLovable وBolt وv0 وReplit وWindsurf. كل عنصر قابل للتنفيذ في أقل من خمس دقائق. قم بالمراجعة قبل الانتقال إلى مرحلة الإنتاج، ثم مرة أخرى قبل كل إصدار رئيسي. يتم تجميع العناصر في سبع فئات - الأسرار، وقاعدة البيانات، والمصادقة، والرؤوس، والجهات الخارجية، والنشر، والمراقبة - ويتم وضع علامة عليها بمرحلة النشر التي تنطبق عليها.

PRE = النشر المسبق (تدقيق المصدر). DEPLOY = في وقت النشر. POST = التحقق بعد النشر. تشير العناصر إلى FixVibe وتحقق من المعرفات في النموذج category.check-id عند الاقتضاء.

الأسرار ومفاتيح API (8 عناصر)

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

  1. PRE — Audit NEXT_PUBLIC_ env vars. يتم شحن أي شيء مسبوق بـ NEXT_PUBLIC_ في حزم العميل. إذا كان أحد المفاتيح هو Supabase service_role (يتم فك ترميزه إلى JWT باستخدام "role":"service_role")، فاحذفه وقم بالتوجيه عبر عميل الخادم فقط (src/lib/supabase/service.ts مع import 'server-only').
  2. PRE — Grep for hardcoded provider keys. مصدر البحث عن sk_live_، pk_live_، STRIPE_SECRET، sk-ant-، sk-، AIza، AKIA، وJWT- أبحث عن سلاسل (eyJ). انقل كل نتيجة إلى .env.local وقم بالإشارة إليها عبر process.env.* من جانب الخادم فقط.
  3. PRE — Verify .gitignore. قم بتأكيد .env*.local، .npmrc، .yarnrc، ويتم تجاهل أي ملفات بيانات اعتماد خاصة بالموفر. قم بتشغيل git ls-files من خلال أنماط الموفر الخاص بك للعثور على أي شيء تم الالتزام به بالفعل.
  4. PRE — Scan the built bundle. قم بتشغيل npm run build، ثم grep .next/static وأي مخرجات dist/ لنفس الأنماط. إذا وصل المفتاح إلى الحزمة، فلن يكون لدى المطور مطلقًا فصل نظيف عن البيئة.
  5. DEPLOY — Set secrets per environment. Vercel: الإعدادات → متغيرات البيئة، قم بنطاق كل منها إلى Proالإخراج / المعاينة / التطوير. لا تشارك أبدًا sk_live_* مع بيئة المعاينة. استخدم وحدة تخزين env-var المشفرة Vercel، وليس أسرار سير العمل المضمنة.
  6. DEPLOY — Disable build-log secret echo. بعض تكوينات CI echo env vars أثناء الإنشاء. قم بتدقيق vercel.json، أو GitHub سير عمل الإجراءات، أو Cloudflare إعدادات الصفحات لأي echo $SECRET من شأنها دفع القيمة إلى سجلات البناء العامة.
  7. POST — Run a passive scan. FixVibe تغطي طبقة Free هذا: الصق URL المنشورة، وانتظر ~20 ثانية، وابحث عن نتائج secrets.*. يقوم التحقق secrets.browser-storage بالتقاط المفاتيح التي وصلت إلى localStorage أو sessionStorage عبر سوء استخدام SDK.
  8. POST — Rotate any key that ever shipped. إذا كان المفتاح موجودًا في حزمة عامة لمدة دقائق، فاعتبره مخترقًا. قم بتدوير Supabase مفاتيح دور الخدمة عبر لوحة المعلومات، وأعد إنشاء المفاتيح المقيدة Supabase، وقم بإلغاء مفاتيح Anthropic / OpenAI / Google عبر وحدات التحكم الخاصة بهم.

التحكم في الوصول إلى قاعدة البيانات: RLS وقواعد Firestore (6 عناصر)

BaaS الإعدادات الافتراضية مسموحة عن قصد لذا يعمل البرنامج التعليمي الأول. Proيحتاج الإنتاج إلى سياسات واضحة.

  1. PRE — Force RLS on every public.* table. في Supabase: يجب أن يحتوي كل جدول على ALTER TABLE ... ENABLE ROW LEVEL SECURITY وFORCE ROW LEVEL SECURITY. Force مهم: بدونه، يتجاوز Postgres RLS لأصحاب الجداول.
  2. PRE — Write a policy per (table, role, action). الحد الأدنى: سياسة SELECT التي تنضم إلى auth.uid(). الأفضل: فصل السياسات INSERT / UPDATE / DELETE بحيث لا يتمكن UPDATE من تهريب التغييرات user_id التي تعيد توجيه الملكية.
  3. PRE — Replace default Firebase rules. قراءة قواعد وضع الاختبار الافتراضية allow read, write: if true;. استبدل القواعد المرتبطة بالمصادقة لكل مجموعة: match /users/{userId} بـ allow read, write: if request.auth.uid == userId;
  4. PRE — Lint migrations in CI. قم بتشغيل supabase db lint أو ما يعادله قبل الدمج. يجب أن يفشل CI في الإنشاء إذا كان أي CREATE TABLE public.* يفتقر إلى سياسة RLS المطابقة.
  5. DEPLOY — Confirm RLS survived deploy. أعد تسجيل الدخول إلى Supabase Studio بعد النشر: الجداول → كل صف → RLS التبديل هو ON. Pro تسبق عمليات ترحيل قاعدة البيانات أحيانًا ملفات السياسة؛ التحقق من أن السياسة حية.
  6. POST — Run an active scan against a verified domain. يكتب الفحص النشط baas.supabase-rls إلى صف أولي صغير باستخدام المفتاح المجهول ويقدم تقريرًا إذا نجحت الكتابة - i.e. RLS لا يتم فرضه فعليًا.

المصادقة والجلسات (7 عناصر)

تميل أخطاء المصادقة في التطبيقات المشفرة AI- إلى أن تكون خفية: التحقق من الرمز المميز، وعلامة HttpOnly المفقودة، وgetSession() حيث يجب أن يكون هناك getUser().

  1. PRE — Replace getSession() with getUser(). getSession() يقرأ ملف تعريف الارتباط ويثق به؛ getUser() يتم التحقق باستخدام الواجهة الخلفية Supabase. في مسارات الخادم، استخدم دائمًا getUser().
  2. PRE — Confirm token expiry. تحتاج الرموز المميزة للارتباط السحري وإعادة تعيين كلمة المرور والتحقق من البريد الإلكتروني إلى انتهاء صلاحية يفرضها الخادم. تنتهي صلاحية الروابط السحرية الافتراضية Supabase بعد ساعة واحدة - لا تتجاوز ذلك إلى رقم أعلى دون سبب حقيقي.
  3. PRE — Verify JWT aud and exp. إذا قمت بفك تشفير الرموز المميزة يدويًا في أي مكان، فتحقق من كلا المطالبتين. الأفضل: استخدم SDK getUser() الذي يقوم بذلك نيابةً عنك.
  4. PRE — Audit cookie flags. يجب أن تكون ملفات تعريف الارتباط المخصصة للجلسة Secure; HttpOnly; SameSite=Lax (أو Strict للتدفقات غير OAuth). لا توجد مادة للجلسة في localStorage.
  5. PRE — Validate the next redirect param. يجب أن تبدأ معلمة الاستعلام next بعد تسجيل الدخول بـ / وليس // (إعادة التوجيه المفتوحة إلى attacker.example). رفض أي شيء آخر من جانب الخادم.
  6. POST — Test logout. قم بتسجيل الدخول، وتسجيل الخروج، وفحص ملفات تعريف الارتباط (DevTools → Application → Cookies). يجب مسح ملف تعريف الارتباط للجلسة على نفس الاستجابة. إذا استمر الأمر، فإن معالج تسجيل الخروج لا يقوم فعليًا بتدمير الحالة من جانب الخادم.
  7. POST — Active probe. يتحقق active.auth-flow وactive.account-enumeration من حدود المصادقة المكسورة - استجابات مختلفة حول "المستخدم موجود" مقابل "كلمة مرور خاطئة"، والحد الأقصى للمعدل عند تسجيل الدخول، ورموز إعادة التعيين غير الموقعة.

HTTP رؤوس الأمان وسياسة أمان المحتوى (6 عناصر)

الرؤوس هي أرخص عملية تصلب في المسار بأكمله والأكثر تخطيًا باستمرار من خلال إنشاء الكود.

  1. PRE — Ship a real CSP. الحد الأدنى: script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. لا يوجد 'unsafe-inline' في script-src. Next.js يطبق الرقم nonce تلقائيًا عندما تقوم البرامج الوسيطة بتعيين رأس الطلب x-nonce.
  2. PRE — Add the legacy three. X-Content-Type-Options: nosniff، X-Frame-Options: DENY (أو اعتمد على CSP frame-ancestors وحده)، Strict-Transport-Security: max-age=31536000; includeSubDomains.
  3. PRE — Tighten Referrer-Policy. الافتراضي strict-origin-when-cross-origin مناسب لمعظم التطبيقات. لا تشحن unsafe-url أو لا تشحن أي رأس على الإطلاق.
  4. PRE — Replace Access-Control-Allow-Origin: *. جربها. استبدلها بالقائمة المسموح بها للأصل الصريح. في أي مكان يكون فيه * إلى جانب credentials: include، سيرفض المتصفح الطلب - ولكن هذا ليس دفاعًا ضد الواجهة الخلفية التي تمت تهيئتها بشكل خاطئ.
  5. DEPLOY — Verify headers post-deploy. افتح DevTools ← الشبكة ← انقر على المستند الجذر ← علامة تبويب الرؤوس. CSP، HSTS، يجب أن تكون خيارات X-Frame-Options وX-Content-Type-Options موجودة. CSP يجب ألا يكون لديه 'unsafe-inline' في script-src.
  6. POST — Run headers.security-headers. يقوم فحص الرأس الخامل بالإبلاغ عن كل رأس مفقود مع إرشادات إصلاح النظام الأساسي للنشر (Vercel vercel.json، Cloudflare الصفحات _headers، Netlify _headers، Next.js البرامج الوسيطة).

عمليات تكامل الجهات الخارجية وAPIs (5 عناصر)

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

  1. PRE — Reverse-proxy analytics where possible. PostHog، معقول، تدعم جميع Umami التفويض من خلال المجال الخاص بك (e.g. /api/posthog). يؤدي هذا إلى إبقاء connect-src على نفس الأصل ويتغلب على أدوات حظر الإعلانات.
  2. PRE — CSP-allowlist the rest. بالنسبة إلى Google Analytics، Stripe.js، وSentry، وIntercom، وGTM، وما إلى ذلك، أضف أصول كل بائع إلى التوجيه المطابق CSP (script-src للتحميل، connect-src للقياس عن بعد، frame-src لإطارات iframe، img-src للبكسل).
  3. PRE — Use Stripe Checkout, not raw card forms. Stripe Checkout عبارة عن عملية إعادة توجيه عالية المستوى؛ لا يلزم إدخال CSP للبرنامج النصي. السطح المستضاف PCI موجود بالكامل في نطاق Stripe. لفة بنفسك فقط إذا كان لديك سبب قوي.
  4. PRE — Lock package-lock.json in CI. قم بتشغيل npm ci (وليس npm install) في بنيات الإنتاج. قم بتدقيق التبعيات باستخدام npm audit أو Snyk قبل كل إصدار.
  5. POST — Watch discovery.tech-fingerprint. يظهر اكتشاف مكدس التكنولوجيا السلبي إصدارات المكتبة المرئية للزاحف. إذا قمت بإرسال EOL React أو jQuery أو Bootstrap، فإن FixVibe تضع علامة عليها وتربطها بـ CVEs المعروفة.

نظافة النشر والبنية التحتية (8 عناصر)

إن كيفية النشر مهمة بقدر أهمية ما تنشره. AI- تستفيد التطبيقات المشفرة بشكل خاص من تقوية النشر الصريحة.

  1. PRE — Disable x-powered-by. في next.config.js: poweredByHeader: false. يزيل إشارة الكشف عن النسخة المجانية.
  2. PRE — Confirm middleware lives at src/middleware.ts. باستخدام تخطيط الدليل src/، يتجاهل Next.js مستوى الجذر middleware.ts. تفشل البرامج الوسيطة في غير مكانها بصمت في تعيين CSP / رؤوس المصادقة / حدود المعدل.
  3. PRE — Sanity-check Vercel deployment protection. Pro يجب أن يكون الاستقراء عامًا؛ يجب أن تكون المعاينة محمية بكلمة مرور أو تقتصر على أعضاء المؤسسة. discovery.platform-vercel يُبلغ عن السطح.
  4. PRE — Block dotfile and config probes at the edge. أضف قاعدة إعادة كتابة أو رفض لأنماط /.env، /.git/*، /.aws/*، /.next/trace. Vercel يُرجع 403 للعديد من هذه العناصر بشكل افتراضي؛ شيك مسطر.
  5. DEPLOY — Separate environments. Proالإخراج والمعاينة والتطوير. كل منهم يحصل على مجموعة من الأسرار الخاصة به. لا تصل المفاتيح المباشرة إلى المعاينة مطلقًا، ولا يصل وضع الاختبار Stripe أبدًا إلى Proالإنتاج.
  6. DEPLOY — Enable Vercel Web Application Firewall. Pro وخطط Enterprise تتضمن WAF مع القواعد المُدارة. Cloudflare يحتوي Pages على وضع Bot Fight. يعمل كلاهما على تقليل إساءة استخدام الماسح الضوئي الآلي وتحميل رش كلمة المرور.
  7. POST — Verify TLS configuration. SSL Labs أو testssl.sh مقابل مجال الإنتاج الخاص بك. TLS 1.2 كحد أدنى، يفضل TLS 1.3، لا توجد شفرات ضعيفة، HSTS مؤهل للتحميل المسبق.
  8. POST — Confirm health-check endpoints are minimal. يجب أن يعود /api/health 200 OK بدون أي نص. لا تقم بتكرار البيئة أو إنشاء التجزئة أو نشر الطابع الزمني بدون مصادقة.

المراقبة المستمرة وإعادة المسح (4 عناصر)

الأمان ليس عملية تدقيق لمرة واحدة قبل الشحن. يحدث الانجراف عند كل عملية نشر.

  1. Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT أو HTTP التحقق من الملف. يؤدي هذا إلى فتح عمليات إعادة الفحص المجدولة، والتحقيق النشط، ومراقبة التهديدات المباشرة.
  2. تدعم خطط Schedule passive re-scans. Pro إيقاعًا مدته 3 ساعات؛ Unlimited يدعم الإيقاع لمدة 6 ساعات. يؤدي كل فحص مجدول يظهر اكتشافًا جديدًا إلى تشغيل بريد إلكتروني (وخطاف اتصال عبر الويب إذا قمت بتوصيله).
  3. Wire outbound webhooks. Account → Webhooks → أضف نقطة نهاية HTTPS، واشترك في scan.completed + finding.created + scan.active_api.first_used. الطريق إلى Slack / Discord / PagerDuty.
  4. Enable live threat monitoring on Unlimited. اختلافات سجل شفافية الشهادات، DNS التغييرات، JS التسريبات السرية للحزمة، وقوائم التهديدات الاستخباراتية - يتم إطلاقها في اللحظة التي يتم اكتشافها فيها، وليس في عملية الفحص المجدولة التالية.

الخطوات التالية

هل تريد الخلفية التعليمية حول سبب أهمية هذه العناصر؟ اقرأ AI-generated code security scanning. هل تريد مقتطفات برمجية محددة لكل خطوة تقوية؟ راجع How to secure an app built with AI coding tools.

// scan your app

كفّ عن القراءة. ابدأ بإيجاد الثغرات في تطبيقك.

أدخل URL — FixVibe يُجري كل فحص سلبي من هذا الدليل بالإضافة إلى أكثر من 200 فحص آخر في أقل من دقيقة. Free، بدون تثبيت، بدون بطاقة.

  • Free الطبقة — 3 عمليات مسح/شهر، بدون بطاقة.
  • عمليات الفحص السلبي ضد أي URL — لا حاجة للتحقق من المجال.
  • تم ضبطه على Cursor، Claude Code، Lovable، Bolt، v0، Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
قائمة فحص أمان vibe coding: 44 عنصرًا قبل الإطلاق — Docs · FixVibe