Zpět na blog
    bezpecnost
    bezpečnost
    security
    vibecoding

    Bezpečnost ve Vibe Codingu: Jak zajistit, že AI negeneruje zranitelný kód

    Vibecoderi Team
    Tým expertů na bezpečnost AI-generovaného kódu.
    23. dubna 2025
    14 min čtení

    TL;DR

    AI-generovaný kód může obsahovat bezpečnostní zranitelnosti jako SQL injection, XSS, nebo chybějící autorizaci. Klíčové je: vždy používat RLS policies v Supabase, validovat vstupy na serveru, nikdy neukládat secrets v kódu, a pravidelně revidovat AI výstupy z bezpečnostního hlediska.

    Bezpečnost ve Vibe Codingu: Jak zajistit, že AI negeneruje zranitelný kód

    Úvod: Bezpečnost není volitelná

    AI nástroje pro vibe coding jsou neuvěřitelně mocné, ale mají jednu významnou slabinu: nerozumí kontextu bezpečnosti vaší aplikace. Generovaný kód může být funkční a elegantní, ale zároveň obsahovat kritické bezpečnostní zranitelnosti.

    Tento článek vás provede nejčastějšími bezpečnostními problémy AI-generovaného kódu a naučí vás, jak je identifikovat a předcházet jim.

    Nejčastější zranitelnosti v AI kódu

    1. SQL Injection

    AI často generuje kód, který přímo vkládá uživatelský vstup do SQL dotazů:

    // NEBEZPEČNÉ - AI může vygenerovat toto
    const query = `SELECT * FROM users WHERE email = '${email}'`;
    
    // BEZPEČNÉ - vždy používejte parametrizované dotazy
    const { data } = await supabase
      .from('users')
      .select()
      .eq('email', email);

    2. Cross-Site Scripting (XSS)

    Renderování uživatelského vstupu bez sanitizace:

    // NEBEZPEČNÉ
    <div dangerouslySetInnerHTML={{ __html: userContent }} />
    
    // BEZPEČNÉ - používejte knihovny pro sanitizaci
    import DOMPurify from 'dompurify';
    <div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userContent) }} />

    3. Broken Authentication

    Nedostatečná validace session a tokenů:

    // NEBEZPEČNÉ - žádná validace
    const user = localStorage.getItem('user');
    
    // BEZPEČNÉ - vždy validujte session na serveru
    const { data: { user }, error } = await supabase.auth.getUser();

    4. Insecure Direct Object References (IDOR)

    Přístup k datům bez ověření oprávnění:

    // NEBEZPEČNÉ - kdokoliv může přistoupit k jakémukoliv profilu
    const profile = await getProfile(params.userId);
    
    // BEZPEČNÉ - ověřte oprávnění
    const profile = await getProfile(params.userId);
    if (profile.userId !== currentUser.id && !currentUser.isAdmin) {
      throw new Error('Unauthorized');
    }

    5. Sensitive Data Exposure

    Logování nebo vracení citlivých dat:

    // NEBEZPEČNÉ
    console.log('User data:', { ...user, password: user.password });
    
    // BEZPEČNÉ - nikdy nelogujte citlivá data
    console.log('User logged in:', { id: user.id, email: user.email });

    Row Level Security (RLS) - Váš první obranný val

    Při použití Supabase je RLS absolutně kritický. AI často generuje tabulky bez RLS policies, což znamená, že data jsou přístupná komukoli.

    Základní RLS pravidla

    -- Vždy povolte RLS
    ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
    
    -- Users mohou vidět jen svá data
    CREATE POLICY "Users can view own profile"
    ON profiles FOR SELECT
    USING (auth.uid() = user_id);
    
    -- Users mohou upravovat jen svá data
    CREATE POLICY "Users can update own profile"
    ON profiles FOR UPDATE
    USING (auth.uid() = user_id);
    
    -- Pouze autentizovaní users mohou vkládat
    CREATE POLICY "Authenticated users can insert"
    ON profiles FOR INSERT
    WITH CHECK (auth.uid() = user_id);

    Checklist pro RLS

    • ✅ Je RLS povolen na všech tabulkách s uživatelskými daty?
    • ✅ Existují policies pro všechny operace (SELECT, INSERT, UPDATE, DELETE)?
    • ✅ Jsou policies dostatečně restriktivní?
    • ✅ Testovali jste policies s různými user roles?

    API a Edge Functions Security

    Validace vstupů

    Vždy validujte všechny vstupy na serveru, nejen na klientovi:

    import { z } from 'zod';
    
    const createUserSchema = z.object({
      email: z.string().email(),
      name: z.string().min(2).max(100),
      age: z.number().min(18).max(120).optional()
    });
    
    export async function POST(req: Request) {
      const body = await req.json();
      
      // Validace vstupu
      const result = createUserSchema.safeParse(body);
      if (!result.success) {
        return new Response(JSON.stringify({ error: result.error }), { status: 400 });
      }
      
      // Pokračujte s validovanými daty
      const validatedData = result.data;
    }

    Rate Limiting

    Chraňte API před abuse:

    // Jednoduchý rate limiter pro Edge Functions
    const rateLimitMap = new Map();
    
    function rateLimit(ip: string, limit: number = 10, window: number = 60000) {
      const now = Date.now();
      const windowStart = now - window;
      
      const requests = rateLimitMap.get(ip) || [];
      const recentRequests = requests.filter(time => time > windowStart);
      
      if (recentRequests.length >= limit) {
        return false;
      }
      
      recentRequests.push(now);
      rateLimitMap.set(ip, recentRequests);
      return true;
    }

    Správa secrets a API klíčů

    Nikdy neukládejte secrets v kódu

    // NEBEZPEČNÉ
    const STRIPE_KEY = 'sk_live_xxx';
    
    // BEZPEČNÉ - používejte environment variables
    const STRIPE_KEY = Deno.env.get('STRIPE_SECRET_KEY');

    Rozdělte klíče podle prostředí

    • Development: Testovací API klíče
    • Staging: Sandbox klíče
    • Production: Produkční klíče s omezeným přístupem

    Pravidelně rotujte klíče

    Nastavte si reminder na rotaci API klíčů každých 90 dní.

    Security Checklist pro každý projekt

    Před spuštěním

    • ☐ RLS povoleno na všech tabulkách
    • ☐ Všechny API klíče jsou v environment variables
    • ☐ Input validace na všech formulářích
    • ☐ HTTPS povoleno
    • ☐ CORS správně nakonfigurován
    • ☐ Citlivá data nejsou logována
    • ☐ Error messages neodhalují implementační detaily

    Autentizace

    • ☐ Password requirements (min 8 znaků, komplexita)
    • ☐ Session timeout implementován
    • ☐ Logout invaliduje session
    • ☐ Password reset flow je bezpečný

    Data

    • ☐ Citlivá data jsou šifrována
    • ☐ Backup strategie existuje
    • ☐ GDPR compliance (pokud relevantní)
    • ☐ Data retention policy

    Testování bezpečnosti

    Manuální testování

    1. Test autorizace: Zkuste přistoupit k datům jiných uživatelů
    2. Test vstupů: Zadejte neočekávané hodnoty do formulářů
    3. Test session: Zkuste použít staré tokeny po logout

    Automatizované nástroje

    • Snyk: Skenování dependencies na zranitelnosti
    • OWASP ZAP: Web application security scanner
    • GitHub Dependabot: Automatické aktualizace závislostí

    Co dělat při bezpečnostním incidentu

    Okamžité kroky

    1. Containment: Izolujte postižené systémy
    2. Assessment: Zjistěte rozsah útoku
    3. Notification: Informujte dotčené uživatele
    4. Recovery: Obnovte ze zálohy pokud nutné
    5. Post-mortem: Analyzujte příčiny a zaveďte prevenci

    Závěr: Bezpečnost je kontinuální proces

    Bezpečnost není jednorázový úkol, ale kontinuální proces. Při vibe codingu je obzvláště důležité:

    • Vždy revidovat AI-generovaný kód z bezpečnostního hlediska
    • Implementovat RLS policies před prvním deploy
    • Pravidelně aktualizovat dependencies
    • Vzdělávat se v security best practices

    Pamatujte: bezpečnostní incident může zničit reputaci i byznys. Investice do bezpečnosti se vždy vyplatí.

    Často kladené otázky

    Zdroje

    1. [1]
      OWASP Top 10— OWASP Foundation
    2. [2]
    3. [3]
    4. [4]

    Štítky

    bezpečnost
    security
    vibecoding
    RLS
    SQL injection
    XSS
    OWASP

    Chcete se stát vibecoderem?

    Zaregistrujte se a získejte přístup k práci, kurzům a komunitě.

    Vytvořit účet zdarma