// docs / security guides / pre-ship checklist

वाइब कोडिंग सुरक्षा चेकलिस्ट: शिप करने से पहले 44 आइटम

Cursor, Claude Code, Lovable, Bolt, v0, Replit, और Windsurf के साथ निर्मित ऐप्स के लिए एक व्यावहारिक, चरण-संगठित चेकलिस्ट। प्रत्येक आइटम पर पांच मिनट से कम समय में कार्रवाई की जा सकती है। उत्पादन पर आगे बढ़ने से पहले, फिर प्रत्येक प्रमुख रिलीज़ से पहले इसका अध्ययन करें। आइटम को सात श्रेणियों में बांटा गया है - रहस्य, डेटाबेस, ऑथ, हेडर, तृतीय-पक्ष, परिनियोजन, निगरानी - और जिस परिनियोजन चरण पर वे लागू होते हैं, उसके साथ टैग किया गया है।

PRE = पूर्व-तैनाती (अपने स्रोत का ऑडिट करें)। DEPLOY = तैनाती के समय। POST = तैनाती के बाद सत्यापन। आइटम संदर्भ FixVibe जहां प्रासंगिक हो वहां category.check-id फॉर्म में आईडी जांचें।

रहस्य और API कुंजियाँ (8 आइटम)

हार्डकोडेड कुंजियाँ वाइब-कोडेड ऐप्स में सबसे आम खोज हैं। उन्हें बाहर रखने के लिए आठ वस्तुएँ:

PRE — Audit NEXT_PUBLIC_ env vars. NEXT_PUBLIC_ उपसर्ग वाली कोई भी चीज़ क्लाइंट बंडलों में भेजी जाती है। यदि कोई Supabase service_role कुंजी है ("role":"service_role" के साथ JWT पर डिकोड होता है), तो इसे हटाएं और केवल सर्वर क्लाइंट (src/lib/supabase/service.ts के साथ import 'server-only') के माध्यम से रूट करें।
PRE — Grep for hardcoded provider keys. sk_live_, pk_live_, STRIPE_SECRET, sk-ant-, sk-, AIza, AKIA, और JWT-लुकिंग स्ट्रिंग्स (eyJ) के लिए खोज स्रोत। प्रत्येक हिट को .env.local में ले जाएं और केवल process.env.* सर्वर-साइड के माध्यम से संदर्भित करें।
PRE — Verify .gitignore. पुष्टि करें .env*.local, .npmrc, .yarnrc, और किसी भी प्रदाता-विशिष्ट क्रेडेंशियल फ़ाइलों को अनदेखा कर दिया जाता है। पहले से प्रतिबद्ध किसी भी चीज़ को खोजने के लिए अपने प्रदाता पैटर्न के माध्यम से git ls-files चलाएँ।
PRE — Scan the built bundle. समान पैटर्न के लिए npm run build चलाएँ, फिर grep .next/static और कोई भी dist/ आउटपुट चलाएँ। यदि कोई कुंजी बंडल तक पहुंचती है, तो देव के पास कभी भी स्वच्छ एनवी पृथक्करण नहीं होता है।
DEPLOY — Set secrets per environment. Vercel: सेटिंग्स → पर्यावरण चर, प्रत्येक का दायरा Proडक्शन/पूर्वावलोकन/विकास। पूर्वावलोकन वातावरण के साथ कभी भी sk_live_* साझा न करें। Vercel के एन्क्रिप्टेड env-var स्टोरेज का उपयोग करें, इनलाइन वर्कफ़्लो रहस्यों का नहीं।
DEPLOY — Disable build-log secret echo. निर्माण के दौरान कुछ CI कॉन्फ़िगरेशन echo env vars। किसी भी echo $SECRET के लिए अपने vercel.json, GitHub एक्शन वर्कफ़्लो, या Cloudflare पेज सेटिंग्स का ऑडिट करें जो मान को सार्वजनिक बिल्ड लॉग में धकेल देगा।
POST — Run a passive scan. FixVibe का Free टियर इसे कवर करता है: तैनात किए गए URL को पेस्ट करें, ~20 सेकंड तक प्रतीक्षा करें, secrets.* निष्कर्षों को देखें। secrets.browser-storage चेक उन कुंजियों को पकड़ता है जो SDK के दुरुपयोग के माध्यम से localStorage या sessionStorage में आती हैं।
POST — Rotate any key that ever shipped. यदि कोई कुंजी कुछ मिनट के लिए भी सार्वजनिक बंडल में थी, तो इसे समझौता हुआ माना जाए। डैशबोर्ड के माध्यम से Supabase सेवा-भूमिका कुंजियाँ घुमाएँ, Stripe प्रतिबंधित कुंजियाँ पुन: उत्पन्न करें, एन्थ्रोपिक / ओपनएआई / Google कुंजियाँ उनके कंसोल के माध्यम से निरस्त करें।

डेटाबेस अभिगम नियंत्रण: RLS और फायरस्टोर नियम (6 आइटम)

BaaS डिफ़ॉल्ट जानबूझकर अनुमेय हैं इसलिए पहला ट्यूटोरियल काम करता है। Proडक्शन को स्पष्ट नीतियों की आवश्यकता है।

PRE — Force RLS on every public.* table. Supabase में: प्रत्येक तालिका में ALTER TABLE ... ENABLE ROW LEVEL SECURITY और FORCE ROW LEVEL SECURITY होना चाहिए। Force मायने रखता है: इसके बिना, पोस्टग्रेज़ टेबल मालिकों के लिए RLS को बायपास कर देता है।
PRE — Write a policy per (table, role, action). न्यूनतम: एक SELECT पॉलिसी जो auth.uid() पर जुड़ती है। बेहतर: INSERT / UPDATE / DELETE नीतियों को अलग करें ताकि UPDATE स्वामित्व को पुनः निर्देशित करने वाले user_id परिवर्तनों में घुसपैठ न कर सके।
PRE — Replace default Firebase rules. डिफ़ॉल्ट परीक्षण-मोड नियम allow read, write: if true; पढ़ें। प्रति संग्रह प्रामाणिक-बाध्य नियमों से बदलें: match /users/{userId} के साथ allow read, write: if request.auth.uid == userId;
PRE — Lint migrations in CI. विलय से पहले supabase db lint या समकक्ष चलाएँ। यदि किसी CREATE TABLE public.* में मिलान वाली RLS नीति का अभाव है तो CI का निर्माण विफल हो जाना चाहिए।
DEPLOY — Confirm RLS survived deploy. परिनियोजन के बाद Supabase स्टूडियो में दोबारा जांचें: टेबल्स → प्रत्येक पंक्ति → RLS टॉगल ON है। Proडक्शन डेटाबेस माइग्रेशन कभी-कभी नीति फ़ाइलों से आगे निकल जाता है; सत्यापित करें कि नीति लाइव है।
POST — Run an active scan against a verified domain. baas.supabase-rls सक्रिय चेक एनॉन कुंजी का उपयोग करके एक छोटी बीज पंक्ति को लिखता है और यदि लेखन सफल हो जाता है तो वापस रिपोर्ट करता है - i.e। RLS वास्तव में लागू नहीं कर रहा है।

प्रमाणीकरण और सत्र (7 आइटम)

AI-कोडित ऐप्स में प्रामाणिक बग सूक्ष्म होते हैं: टोकन सत्यापन में एक-एक करके, एक छूटा हुआ HttpOnly ध्वज, एक getSession() जहां एक getUser() होना चाहिए।

PRE — Replace getSession() with getUser(). getSession() कुकी पढ़ता है और उस पर भरोसा करता है; getUser() Supabase बैकएंड से सत्यापन करता है। सर्वर रूट पर हमेशा getUser() का उपयोग करें।
PRE — Confirm token expiry. मैजिक-लिंक, पासवर्ड-रीसेट और ईमेल-सत्यापन टोकन के लिए सर्वर-प्रवर्तित समाप्ति की आवश्यकता होती है। डिफ़ॉल्ट Supabase मैजिक-लिंक 1 घंटे के बाद समाप्त हो जाते हैं - बिना किसी वास्तविक कारण के इसे अधिक संख्या में ओवरराइड न करें।
PRE — Verify JWT aud and exp. यदि आप कहीं भी टोकन को मैन्युअल रूप से डिकोड करते हैं, तो दोनों दावों की जांच करें। बेहतर: SDK के getUser() का उपयोग करें जो यह आपके लिए करता है।
PRE — Audit cookie flags. कस्टम सत्र कुकीज़ Secure; HttpOnly; SameSite=Lax (या गैर-OAuth प्रवाह के लिए Strict) होनी चाहिए। localStorage में कोई सत्र सामग्री नहीं।
PRE — Validate the next redirect param. साइन-इन के बाद next क्वेरी पैरामीटर / से शुरू होना चाहिए न कि // से (ओपन-रीडायरेक्ट attacker.example पर)। सर्वर-साइड किसी भी अन्य चीज़ को अस्वीकार करें।
POST — Test logout. साइन इन करें, साइन आउट करें, कुकीज़ का निरीक्षण करें (DevTools → एप्लिकेशन → कुकीज़)। सत्र कुकी को उसी प्रतिक्रिया पर साफ़ किया जाना चाहिए। यदि यह बना रहता है, तो लॉगआउट हैंडलर वास्तव में सर्वर-साइड स्थिति को नष्ट नहीं कर रहा है।
POST — Active probe. active.auth-flow और active.account-enumeration सतह टूटी हुई प्रामाणिक सीमाओं की जाँच करता है - "उपयोगकर्ता मौजूद है" बनाम "गलत पासवर्ड" पर अलग-अलग प्रतिक्रियाएँ, लॉगिन पर दर-सीमा गायब, अहस्ताक्षरित रीसेट टोकन।

HTTP सुरक्षा शीर्षलेख और सामग्री सुरक्षा नीति (6 आइटम)

हेडर पूरी पाइपलाइन में सबसे सस्ता हार्डनिंग है और कोडजन द्वारा सबसे लगातार छोड़ा गया है।

PRE — Ship a real CSP. न्यूनतम: script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. script-src में कोई 'unsafe-inline' नहीं। Next.js जब मिडलवेयर x-nonce अनुरोध हेडर सेट करता है तो नॉन स्वचालित रूप से लागू होता है।
PRE — Add the legacy three. X-Content-Type-Options: nosniff, X-Frame-Options: DENY (या अकेले CSP frame-ancestors पर भरोसा करें), Strict-Transport-Security: max-age=31536000; includeSubDomains।
PRE — Tighten Referrer-Policy. डिफ़ॉल्ट strict-origin-when-cross-origin अधिकांश ऐप्स के लिए ठीक है। unsafe-url या कोई हेडर बिल्कुल न भेजें।
PRE — Replace Access-Control-Allow-Origin: *. इसके लिए धन्यवाद। स्पष्ट मूल अनुमति सूची से बदलें। कहीं भी यह * के साथ-साथ credentials: include है, ब्राउज़र अनुरोध को अस्वीकार कर देगा - लेकिन यह गलत कॉन्फ़िगर किए गए बैकएंड के खिलाफ कोई बचाव नहीं है।
DEPLOY — Verify headers post-deploy. DevTools खोलें → नेटवर्क → अपने रूट दस्तावेज़ → हेडर टैब पर क्लिक करें। CSP, HSTS, एक्स-फ़्रेम-विकल्प, एक्स-सामग्री-प्रकार-विकल्प मौजूद होने चाहिए। CSP में script-src में 'unsafe-inline' नहीं होना चाहिए।
POST — Run headers.security-headers. पैसिव हेडर चेक तैनाती-प्लेटफॉर्म फिक्स मार्गदर्शन (Vercel vercel.json, Cloudflare पेज _headers, नेटलिफाई _headers, Next.js मिडलवेयर) के साथ प्रत्येक लापता हेडर की रिपोर्ट करता है।

तृतीय-पक्ष एकीकरण और APIs (5 आइटम)

आपके द्वारा शामिल की गई प्रत्येक स्क्रिप्ट एक CSP छूट और एक संभावित आपूर्ति-श्रृंखला सतह है। तीसरे पक्षों को अपनी विश्वास सीमा का हिस्सा मानें।

PRE — Reverse-proxy analytics where possible. PostHog, प्रशंसनीय, उमामी सभी आपके अपने डोमेन (e.g. /api/posthog) के माध्यम से प्रॉक्सी का समर्थन करते हैं। यह connect-src को एक ही मूल पर रखता है और विज्ञापन-अवरोधकों से बचा रहता है।
PRE — CSP-allowlist the rest. Google Analytics, Stripe.js, सेंट्री, इंटरकॉम, GTM आदि के लिए, प्रत्येक विक्रेता के मूल को मिलान वाले CSP निर्देश (script-src लोडर के लिए, connect-src टेलीमेट्री के लिए, frame-src आईफ्रेम के लिए, img-src पिक्सल के लिए) में जोड़ें।
PRE — Use Stripe Checkout, not raw card forms. Stripe चेकआउट एक शीर्ष-स्तरीय रीडायरेक्ट है; स्क्रिप्ट के लिए कोई CSP प्रविष्टि आवश्यक नहीं है। होस्ट किया गया PCI सरफेस पूरी तरह से Stripe के डोमेन पर रहता है। यदि आपके पास कोई ठोस कारण हो तो ही अपना रोल करें।
PRE — Lock package-lock.json in CI. प्रोडक्शन बिल्ड में npm ci (नहीं npm install) चलाएँ। प्रत्येक रिलीज़ से पहले npm audit या Snyk के साथ निर्भरता का ऑडिट करें।
POST — Watch discovery.tech-fingerprint. निष्क्रिय तकनीक-स्टैक खोज लाइब्रेरी संस्करणों को क्रॉलर के लिए दृश्यमान बनाती है। यदि आप EOL रिएक्ट, jQuery, या बूटस्ट्रैप भेजते हैं, तो FixVibe इसे ध्वजांकित करता है और ज्ञात सीवीई से लिंक करता है।

परिनियोजन स्वच्छता और बुनियादी ढाँचा (8 आइटम)

आप कैसे तैनात करते हैं यह उतना ही मायने रखता है जितना कि आप क्या तैनात करते हैं। AI-कोडित ऐप्स विशेष रूप से स्पष्ट परिनियोजन कठोरता से लाभान्वित होते हैं।

PRE — Disable x-powered-by. में next.config.js: poweredByHeader: false। मुफ़्त संस्करण-प्रकटीकरण संकेत हटाता है।
PRE — Confirm middleware lives at src/middleware.ts. src/ निर्देशिका लेआउट के साथ, Next.js रूट-स्तर middleware.ts को अनदेखा करता है। गलत स्थान पर रखा गया मिडलवेयर चुपचाप CSP/ऑथ हेडर/दर सीमा निर्धारित करने में विफल रहता है।
PRE — Sanity-check Vercel deployment protection. Pro कटौती सार्वजनिक होनी चाहिए; पूर्वावलोकन पासवर्ड से सुरक्षित होना चाहिए या संगठन सदस्यों तक सीमित होना चाहिए। discovery.platform-vercel सतह की रिपोर्ट करता है।
PRE — Block dotfile and config probes at the edge. /.env, /.git/*, /.aws/*, /.next/trace पैटर्न के लिए पुनः लिखें या अस्वीकार नियम जोड़ें। Vercel इनमें से कई के लिए डिफ़ॉल्ट रूप से 403 लौटाता है; क्रॉस चेक।
DEPLOY — Separate environments. Proसंचालन, पूर्वावलोकन, विकास। प्रत्येक को रहस्यों का अपना सेट मिलता है। लाइव कुंजियाँ कभी भी पूर्वावलोकन तक नहीं पहुँचतीं, Stripe परीक्षण मोड कभी भी Proडक्शन तक नहीं पहुँचता।
DEPLOY — Enable Vercel Web Application Firewall. Pro और एंटरप्राइज़ योजनाओं में प्रबंधित नियमों के साथ WAF शामिल है। Cloudflare पेज में बॉट फाइट मोड है। दोनों स्वचालित-स्कैनर दुरुपयोग और पासवर्ड-स्प्रे लोड को कम करते हैं।
POST — Verify TLS configuration. SSL लैब्स या testssl.sh आपके उत्पादन डोमेन के विरुद्ध। TLS 1.2 न्यूनतम, TLS 1.3 को प्राथमिकता दें, कोई कमजोर सिफर नहीं, HSTS प्रीलोड योग्य।
POST — Confirm health-check endpoints are minimal. A /api/health को बिना किसी कारण के 200 OK लौटना चाहिए। पर्यावरण को प्रतिध्वनित न करें, हैश न बनाएं, या बिना प्रमाणीकरण के टाइमस्टैम्प तैनात न करें।

निरंतर निगरानी और पुन: स्कैनिंग (4 आइटम)

सुरक्षा एक-शॉट प्री-शिप ऑडिट नहीं है। बहाव प्रत्येक परिनियोजन पर होता है।

Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT या HTTP फ़ाइल सत्यापन। यह निर्धारित पुन: स्कैन, सक्रिय जांच और लाइव खतरे की निगरानी को अनलॉक करता है।
Schedule passive re-scans. Pro योजनाएं 3-घंटे की ताल का समर्थन करती हैं; Unlimited 6-घंटे की ताल का समर्थन करता है। प्रत्येक शेड्यूल किया गया स्कैन जो एक नई खोज को सामने लाता है, एक ईमेल ट्रिगर करता है (और यदि आपने एक वेबहुक वायर्ड किया है)।
Wire outbound webhooks. Account → Webhooks → एक HTTPS समापन बिंदु जोड़ें, scan.completed + finding.created + scan.active_api.first_used की सदस्यता लें। स्लैक/डिस्कॉर्ड/पेजरड्यूटी में रूट करें।
Enable live threat monitoring on Unlimited. प्रमाणपत्र-पारदर्शिता लॉग में अंतर, DNS परिवर्तन, JS बंडल गुप्त लीक, ख़तरा-इंटेल लिस्टिंग - जैसे ही उनका पता चलता है, उन्हें सक्रिय कर दिया जाता है, अगले निर्धारित स्कैन पर नहीं।

अगले चरण

शैक्षिक पृष्ठभूमि चाहते हैं कि ये वस्तुएँ क्यों मायने रखती हैं? AI-generated code security scanning पढ़ें. प्रत्येक सख्त चरण के लिए ठोस कोड स्निपेट चाहते हैं? How to secure an app built with AI coding tools देखें.