हर वाइब कोडर द्वारा किए जाने वाली 5 सुरक्षा गलतियाँ (और उन्हें कैसे ठीक करें)

AI-जनित कोड काम करता है। यह चलता है। यह सही दिखता है। यह लगभग हर प्रोजेक्ट में एक जैसी पांच सुरक्षा कमजोरियों के साथ भी आता है। ये काल्पनिक जोखिम नहीं हैं — ये वह विशिष्ट छेद हैं जो Claude, Cursor, Replit, या Copilot द्वारा उत्पादित लगभग हर कोडबेस में दिखाई देते हैं जब आप स्पष्ट रूप से सुरक्षा मांगते हैं।

मैंने पिछले साल दर्जनों vibe-coded प्रोजेक्ट का ऑडिट किया है, और एक ही पांच गलतियां कम से कम 80% में दिखाई देती हैं। प्रत्येक को ठीक करने में 30 मिनट से कम समय लगता है। यहाँ है कि क्या देखना है और इसे ठीक करने का तरीका।

गलती 1: Frontend कोड में API कुंजियां Hardcoded

यह कैसे होता है: आप Claude को "Supabase से जुड़ें" या "Stripe भुगतान जोड़ें" कहते हैं, और यह API कुंजी को सीधे एक React कंपोनेंट में पेस्ट किए गए कोड को जेनरेट करता है। कोड परफेक्ट काम करता है — और आपकी secret कुंजी किसी को भी दिखाई देती है जो ब्राउज़र DevTools खोलता है और Network टैब या JavaScript स्रोत की जांच करता है।

यह खतरनाक क्यों है: आपकी Supabase service role कुंजी सभी डेटाबेस सुरक्षा को बाईपास करती है। आपकी Stripe secret कुंजी किसी को कार्ड चार्ज करने या refunds जारी करने देती है। आपकी OpenAI कुंजी किसी को आपके खाते पर हजारों डॉलर API कॉल में रैक करने देती है। Bots सक्रिय रूप से सार्वजनिक GitHub repos और तैनात साइटों को exposed कुंजियों के लिए स्कैन करते हैं।

समाधान: प्रत्येक secret को environment variables में स्थानांतरित करें। Next.js में, केवल NEXT_PUBLIC_ से शुरू होने वाले variables ब्राउज़र तक पहुंचते हैं। कोई भी कुंजी जो write access, admin access, या financial access दे, वह केवल server-side होनी चाहिए।

कुंजियों को .env.local में स्थानांतरित करने के बाद, अपने पूरे codebase में पुरानी कुंजी मानों को खोजें ताकि सुनिश्चित हो सकें कि वे चले गई हैं। फिर अपने Git history की जांच करें — अगर कुंजी कभी committed थी, तो यह आपके repo history में भी है भले ही आपने इसे हटा दिया हो। किसी भी कुंजी को regenerate (rotate) करें जो कभी भी exposed थी, यहां तक कि briefly भी।

ठीक करने का समय: 15–30 मिनट।

गलती 2: Supabase टेबल बिना Row-Level Security के

यह कैसे होता है: AI Supabase table creation queries और CRUD operations जेनरेट करता है, लेकिन Row-Level Security (RLS) को enable नहीं करता। डिफ़ॉल्ट रूप से, RLS अक्षम वाली Supabase टेबलें आपके project URL और anon कुंजी वाले किसी के लिए भी पूरी तरह से accessible होती हैं — दोनों ही सार्वजनिक हैं (और होनी चाहिए)।

यह खतरनाक क्यों है: RLS के बिना, User A, User B के डेटा को query कर सकता है। ब्राउज़र कंसोल से एक सरल fetch कॉल हर टेबल की हर row को निकाल सकता है। आपका संपूर्ण डेटाबेस प्रभावी रूप से सार्वजनिक है।

इसे कैसे spot करें: अपने Supabase dashboard → Table Editor पर जाएं। अगर कोई भी टेबल "RLS Disabled" दिखाता है, तो आपको यह समस्या है। यह भी जांचें कि क्या आपका client-side कोड service_role कुंजी के बजाय anon कुंजी का उपयोग करता है — वह और भी बदतर है।

समाधान: हर टेबल पर RLS को enable करें। फिर ऐसी policies बनाएं जो आपके ऐप के access patterns से match करें। सबसे common policy: उपयोगकर्ता केवल उन rows को SELECT, INSERT, UPDATE, और DELETE कर सकते हैं जहां auth.uid() = user_id। एक उपयोगकर्ता के रूप में login करके और Supabase REST API के माध्यम से किसी अन्य उपयोगकर्ता के डेटा तक पहुंचने का प्रयास करके परीक्षण करें।

ठीक करने का समय: table count के आधार पर 30–60 मिनट।

गलती 3: Forms या API Routes पर कोई Input Validation नहीं

यह कैसे होता है: AI forms जेनरेट करता है जो कोई भी input स्वीकार करते हैं और API routes जो जो कुछ भी डेटा आता है उस पर विश्वास करते हैं। form में एक "required" attribute है HTML में, लेकिन कोई server-side validation नहीं। कोई form को पूरी तरह से बाईपास करके direct API request भेजकर जो चाहे वह payload भेज सकता है।

यह खतरनाक क्यों है: Server-side validation के बिना, attackers आपके डेटाबेस में scripts inject कर सकते हैं (stored XSS), oversized payloads भेज सकते हैं जो आपके server को crash करते हैं, या ऐसा डेटा submit कर सकते हैं जो आपके ऐप की logic को तोड़ता है (जैसे negative price या SQL युक्त email field)।

इसे कैसे spot करें: अपने codebase में किसी भी API route या server action को खोलें। अगर यह req.body या form data को बिना हर field की shape, type, और length की जांच किए उपयोग करता है, तो आपको यह समस्या है।

समाधान: एक schema validation library का उपयोग करके हर endpoint पर server-side validation जोड़ें। Zod TypeScript projects के लिए standard है:

import { z } from 'zod';

const taskSchema = z.object({
  title: z.string().min(1).max(200),
  description: z.string().max(2000).optional(),
  priority: z.enum(['low', 'medium', 'high']),
});

// आपके API route में:
const parsed = taskSchema.safeParse(req.body);
if (!parsed.success) {
  return Response.json({ error: parsed.error }, { status: 400 });
}

किसी भी field के लिए जो HTML के रूप में render होता है (comments, descriptions, bios), इसे दिखाने से पहले DOMPurify के साथ output को भी sanitize करें।

ठीक करने का समय: 30–60 मिनट।

गलती 4: API Endpoints पर कोई Rate Limiting नहीं

यह कैसे होता है: AI कभी rate limiting नहीं जोड़ता जब तक आप इसके लिए न कहें। आपका ऐप जो हर API route expose करता है उसे script वाले किसी भी व्यक्ति द्वारा प्रति सेकंड हजारों बार hit किया जा सकता है।

यह खतरनाक क्यों है: Rate limiting के बिना, कोई आपके login endpoint को brute-force कर सकता है, list endpoints को बार-बार hit करके आपके डेटाबेस को scrape कर सकता है, आपके server को overwhelm कर सकता है (denial of service), या अपनी API quota को जला सकता है अगर आपके endpoints OpenAI या Stripe जैसी external services को call करते हैं।

इसे कैसे spot करें: अगर आपके किसी भी API route में यह check नहीं है कि एक single IP या user ने हाल ही में कितने requests बनाए हैं, तो आपके पास कोई rate limiting नहीं है।

समाधान: Vercel-hosted apps के लिए सबसे सरल तरीका development के लिए in-memory rate limiter है और production के लिए Redis-based एक है। Vercel का Edge Middleware basic rate limiting को संभाल सकता है। Upstash Redis (free tier) @upstash/ratelimit के साथ production-grade rate limiting को कम कोड में देता है।

एक उचित starting point: authenticated users के लिए 60 requests per minute, unauthenticated users के लिए 20 per minute, और login/signup endpoints के लिए 5 per minute (brute forcing को रोकने के लिए)।

ठीक करने का समय: 20–45 मिनट।

गलती 5: Protected Pages और APIs पर Auth Checks गायब

यह कैसे होता है: AI एक सुंदर dashboard page और API routes जेनरेट करता है जो user data return करते हैं, लेकिन middleware नहीं जोड़ता कि user वास्तव में logged in है। page "काम करता है" क्योंकि development के दौरान आप हमेशा logged in होते हैं। Production में, कोई dashboard URL को directly access कर सकता है बिना login के, या API endpoint को hit कर सकता है और data वापस पा सकता है।

यह खतरनाक क्यों है: Protected pages पर unauthenticated access का मतलब कोई भी user dashboards, admin panels, या private data देख सकता है बस URL को guess करके। Unprotected API routes का मतलब कोई भी Postman या curl जैसी tool बिना credentials के data निकाल सकता है।

इसे कैसे spot करें: एक incognito browser window खोलें (logged in नहीं) और अपने dashboard, settings, या admin URLs पर directly navigate करें। अगर आप login page पर redirect होने के बिना बिना content देख सकते हैं, तो आपको यह समस्या है। फिर अपने API routes को directly hit करने का प्रयास करें — अगर वे valid session cookie या auth token के बिना data return करते हैं, तो वह unprotected हैं।

समाधान: एक authentication middleware जोड़ें जो हर protected route से पहले चलता है। Next.js App Router में, अपने project root पर middleware.ts बनाएं:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session');
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/api/protected/:path*'],
};

हर route को cover करने के लिए matcher को adapt करें जिसे authentication की आवश्यकता होनी चाहिए। Implement करने के बाद incognito में परीक्षा करें।

ठीक करने का समय: 15–30 मिनट।

भविष्य के प्रोजेक्ट्स में इन्हें कैसे रोकें

pattern स्पष्ट है: AI functional रूप से काम करने वाला कोड जेनरेट करता है लेकिन security को छोड़ देता है क्योंकि आपने इसके लिए नहीं कहा। fix यह है कि आप इसे upfront के लिए कहें।

किसी भी vibe-coded project के लिए अपने initial prompt के अंत में यह जोड़ें:

SECURITY REQUIREMENTS:
- सभी secrets environment variables में (कभी hardcoded नहीं)
- सभी tables पर Supabase RLS enabled per-user policies के साथ
- हर API route पर Server-side input validation (Zod का उपयोग करें)
- सभी public endpoints पर Rate limiting
- सभी protected routes पर Authentication middleware
- Client-side code में कोई service role key नहीं

यह सब कुछ नहीं पकड़ेगा, लेकिन यह बाद में cleanup की आवश्यकता के बजाय first pass पर पांच सबसे common vulnerabilities को eliminate करता है।

अगर आप AI से ज्यादा secure code निकलवाने के लिए ऐसे prompts लिखना सीखना चाहते हैं, तो हमरा free prompt optimizer आपको अपनी instructions को structure करने में मदद दे सकता है। और एक complete security walkthrough के लिए, हमारी step-by-step guide देखें: Clients को देने से पहले Vibe-Coded App को Secure कैसे करें।

Disclosure: इस लेख में कुछ links affiliate links हैं। हम केवल उन tools की सलाह देते हैं जिन्हें हमने व्यक्तिगत रूप से परीक्षण किया है और नियमित रूप से उपयोग करते हैं। हमारी full disclosure policy देखें।