FixVibe

// docs / security guides / pre-ship checklist

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

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

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

الأسرار ومفاتيح 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 in JavaScript Bundles بالتقاط المفاتيح التي وصلت إلى localStorage أو sessionStorage عبر سوء استخدام SDK.
  8. POST — Rotate any key that ever shipped. إذا كان المفتاح موجودًا في حزمة عامة لمدة دقائق، فاعتبره مخترقًا. قم بتدوير Supabase مفاتيح دور الخدمة عبر لوحة المعلومات، وأعد إنشاء المفاتيح المقيدة Supabase، وقم بإلغاء مفاتيح Anthropic / OpenAI / Google عبر وحدات التحكم الخاصة بهم.

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

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

  1. PRE — Enable RLS on every public.* table. In Supabase: each table needs ALTER TABLE ... ENABLE ROW LEVEL SECURITY plus explicit policies for each role. RLS is what stops the anon and authenticated API roles; FORCE ROW LEVEL SECURITY only extends it to the table owner and is optional defence in depth.
  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. يكتب الفحص النشط Supabase Row-Level Security إلى صف أولي صغير باستخدام المفتاح المجهول ويقدم تقريرًا إذا نجحت الكتابة - 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. يتحقق Auth Flow Defects و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 HTTP 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 Technology Fingerprinting. يظهر اكتشاف مكدس التكنولوجيا السلبي إصدارات المكتبة المرئية للزاحف. إذا قمت بإرسال 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 يجب أن يكون الاستقراء عامًا؛ يجب أن تكون المعاينة محمية بكلمة مرور أو تقتصر على أعضاء المؤسسة. Vercel-Specific Exposure يُبلغ عن السطح.
  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 or HTTP file verification. Active scans require Hobby or above, scheduled scans require Pro or Unlimited, and live threat monitoring requires Unlimited.
  2. Schedule passive re-scans on Pro or Unlimited. Choose an available cadence for your verified domain. Scheduled runs share your scan allowance; enable completion notifications and signed webhooks as needed. A scheduled scan observes the app at run time, not continuously.
  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. Periodic certificate, DNS, bundle, and threat-intelligence checks can surface changes between scheduled scans. Coverage and alert timing depend on the signal and successful polling.

Replit Agent

If you build with Replit Agent, also check:

  1. Don't paste keys into the Agent prompt. Add them in Secrets and give the Agent the variable name instead, so the value never appears in generated code or chat history.
  2. Test CORS on the production domain. The preview pane and your deployed URL are different origins. Check your CORS allowlist against the domain users actually load.
  3. Replit Agent sometimes hardcodes test values. قد يقوم الوكيل بإنشاء تعليمات برمجية باستخدام API_URL = 'http://localhost:5000</code>. قبل الشحن، استبدله بـ <code>os.environ[API_URL'].

Firebase Studio

If you build with Firebase Studio, also check:

  1. Test-mode rules are temporary by intent, not by default. Test mode lets anyone read and overwrite data. If the generated rule carries a date cutoff, client access stops on that date; if not, the database stays open. Replace test rules before launch either way.
  2. Security rules protect data, not Hosting. Firestore and Storage rules don't govern what Firebase Hosting serves: everything in the public directory is public. Keep exports, backups and admin pages out of it.

Claude Code

If you build with Claude Code, also check:

  1. PRE — Keep personal Claude Code settings out of git. Commit .claude/settings.json for shared project settings, but keep .claude/settings.local.json out of the repo: Claude Code excludes it from git when it creates the file, so check it if you created it by hand. Session history lives in ~/.claude, outside the project (Claude Code docs).
  2. Bash operations are unverified. Claude Code ينفذ أوامر bash مباشرة. يعد git commit -m "fix" أمرًا ملائمًا، ولكن إذا كان دليل العمل يحتوي على ملف .env ويتضمنه الكرة الأرضية، فإنه يلتزم. قم دائمًا بمراجعة git diff --cached قبل تنفيذ Claude Code.

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

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

// scan your app

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

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • 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: 51 عنصرًا قبل الإطلاق · FixVibe