Tíz éve egy vállalati alkalmazás elkészítéséhez kellett egy fejlesztőcsapat, adatbázis-tervezés, architektúra, tesztelés, üzemeltetés és biztonsági ellenőrzés. Ma elég annyit írni egy AI-nak: „Készíts ügyfélportált bejelentkezéssel, fizetéssel és adminfelülettel.” Néhány perc múlva már villog a gomb, működik a regisztráció, és megérkezik az első dopaminlöket: kész a termék.

Nem, nincs kész. Csak van valami, ami egy boldog tesztútvonalon működik.

Az AI nem kérdezi meg, hogy a készítő látott-e már adatmodellt. Nem vizsgáztatja le tranzakciókból, jogosultságkezelésből, több-bérlős adatelválasztásból, naplózásból vagy incidenskezelésből. Udvariasan legenerálja, amit kértek tőle. Pontosabban: legenerál valamit, ami kívülről annak látszik.

A gomb működik. Hurrá, akkor kész.

A vibe coding legveszélyesebb illúziója az, hogy a látható működés bizonyítja a láthatatlan részek helyességét. Pedig a kettőnek alig van köze egymáshoz.

•     A bejelentkező képernyő még nem jogosultságkezelés.

•     Az, hogy a felhasználó nem látja más adatait a menüben, még nem jelenti azt, hogy az API-n keresztül sem éri el őket.

•     A sikeres bankkártyateszt még nem pénzügyi rendszer.

•     A „Deploy successful” felirat még nem üzemeltetési terv.

•     A napi mentés pedig csak addig megnyugtató, amíg valaki meg nem próbálta visszaállítani.

A képernyő a rendszer kirakata. A probléma az, hogy sokan a kirakat alapján veszik át az egész épületet, miközben hátul nincs fal, a pince víz alatt áll, a raktár kulcsa pedig az ajtóban maradt.

Az adatmodell nem egy később kipipálható részlet

Aki soha nem tervezett adatmodellt, gyakran csak táblákat lát: users, orders, products. Szép. Mindegyikben vannak mezők. Még kapcsolat is van köztük. Az AI rajzolt hozzá nyilakat, tehát bizonyára szakmai.

Csakhogy az adatmodell valójában üzleti szabályok kőbe vésett rendszere. Mi egyedi? Mi kötelező? Mit lehet törölni? Mi történik a kapcsolódó adatokkal? Hogyan válik el két ügyfél vagy két cég adata? Mi történik, ha ugyanaz a fizetési kérés kétszer fut le? Van tranzakció? Van auditnapló? Visszaállítható egy hibás módosítás? A törlés tényleg törlés, vagy csak eltűnik a felületről?

Ha ezekre nincs válasz, akkor nem adatmodell készült, hanem néhány tábla, amelyek jelenleg még nem vesztek össze egymással.

A klasszikus hiba egyszerű: a kliens elküldi, hogy melyik rekordot szeretné, a szerver pedig odaadja. A felületen csak a saját rekordok látszanak, ezért a készítő nyugodt. A támadó viszont nem a felületet használja. Átírja az azonosítót az API-kérésben, és máris valaki más számláját, leletét vagy szerződését olvassa. Ezt hívják hibás objektumszintű jogosultságkezelésnek. A rendszer szemszögéből ez nem „hackermágia”. Egy közönséges kérés, amelyre bután igent mondott.

Az architektúra addig felesleges, amíg le nem ég minden

Az architektúra nem azért kell, hogy egy senior fejlesztő drága dobozokat rajzolhasson egy prezentációba. Azért kell, hogy egy hiba ne tudja magával rántani az egész rendszert.

•     Fejlesztői, teszt- és éles környezet szétválasztása: hogy egy kísérlet ne az ügyfelek adatain fusson.

•     Legkisebb szükséges jogosultság: hogy egy komponens kompromittálása ne adjon kulcsot mindenhez.

•     Tranzakciók és idempotencia: hogy egy félbeszakadt vagy megismételt kérés ne könyveljen kétszer és ne hagyjon félkész állapotot.

•     Mentés és visszaállítási próba: mert a nem tesztelt backup csak remény ZIP-fájlban.

•     Naplózás, monitorozás és riasztás: hogy ne az ügyfél szóljon elsőként, amikor már egy hete viszik az adatot.

•     Sebességkorlát és erőforrás-korlát: hogy egyetlen script ne tudja letérdeltetni a szolgáltatást vagy felzabálni a felhős keretet.

2025 júliusában Jason Lemkin nyilvános Replit-kísérletében az AI-ügynök egy kódfagyasztás ellenére törölte az éles adatbázist, majd tévesen azt állította, hogy az adatok nem állíthatók helyre. A Replit vezérigazgatója elfogadhatatlannak nevezte az esetet; a mentésekből végül helyre lehetett állni. Ez nem hackerakció volt, hanem még fontosabb figyelmeztetés: ha nincs valódi környezeti elválasztás, korlátozott jogosultság és emberi jóváhagyás a romboló műveletek előtt, akkor maga a segítőkész fejlesztőeszköz is lehet incidensforrás.

A biztonság nem egy prompt

Persze meg lehet kérni az AI-t: „Tedd biztonságossá az alkalmazást.” Ettől általában bekerül néhány inputellenőrzés, esetleg egy rate limiter, és mindenki hátradől. Mintha azt mondanánk a kőművesnek, hogy „legyen földrengésálló”, majd elhagynánk a statikai tervet.

A biztonság nem funkció, hanem rendszerkövetelmény. Fenyegetési modell kell: milyen adatot tárolunk, ki férhet hozzá, honnan jöhet támadás, mi a legrosszabb lehetséges következmény, és mitől marad a hiba lokalizált. Ehhez ismerni kell legalább a hitelesítés és a jogosultságkezelés különbségét, a szerveroldali ellenőrzést, a titkok kezelését, a függőségi láncot, az injekciós hibákat, az XSS-t, CSRF-et, SSRF-et, a fájlfeltöltés veszélyeit és az alapértelmezett tiltás elvét.

Ha a készítő ezeket a fogalmakat nem ismeri, akkor az AI válaszának minőségét sem tudja megítélni. A modell magabiztosan előállíthat helyes kódot, régi mintát, félmegoldást vagy veszélyes hülyeséget. A kezdő mind a négyet ugyanazzal a zöld „Accept” gombbal fogadja el.

A számok már nem viccesek

A Veracode 2025-ös vizsgálata több mint száz nagy nyelvi modellt tesztelt valós kódolási feladatokon. A tesztek 45 százalékában az AI által előállított megoldás biztonsági hibát vitt a kódba. A nagyobb és újabb modellek sem bizonyultak automatikusan biztonságosabbnak.

Az Escape kutatócsoportja 5600 nyilvánosan elérhető, vibe coding platformokkal készült alkalmazást vizsgált. Több mint 2000 nagy hatású sérülékenységet, 400-nál több kiszivárgott titkot és 175 személyesadat-kitettséget azonosítottak. A talált adatok között egészségügyi információk, IBAN-számok, telefonszámok és e-mail-címek is voltak. A kutatók szerint sok kritikus hiba bejelentkezés nélkül, nyilvános végpontokon keresztül volt elérhető.

2026 májusában a WIRED a RedAccess kutatásáról számolt be: több mint 5000, AI-eszközökkel készített webalkalmazást találtak, amelyeknél gyakorlatilag nem volt érdemi biztonság vagy hitelesítés. A vizsgált körben mintegy 40 százalék érzékeny adatot tett hozzáférhetővé, köztük egészségügyi, pénzügyi és vállalati információkat. A különösen kínos rész: a kutatók egyszerű Google- és Bing-keresésekkel találták meg őket. Nem kellett hozzá kapucnis zseni, zölden futó terminál és három monitor. Elég volt egy keresőmező.

Konkrét esetek: a valóság már elkészítette a demót

A Lovable-höz kapcsolódó CVE-2025-48757 leírása szerint a 2025. április 15-ig érintett, generált oldalak elégtelen adatbázis-szintű Row-Level Security szabályai lehetővé tehették, hogy hitelesítés nélküli támadók tetszőleges táblákból olvassanak vagy azokba írjanak. A szállító vitatta a besorolást, és arra hivatkozott, hogy az alkalmazások adatvédelméért az egyes ügyfelek is felelősek. Ez a vita önmagában tökéletesen mutatja a problémát: a platform azt mondja, a felhasználó felelőssége; a felhasználó pedig azért választotta a platformot, mert nem ért hozzá.

A Wiz 2025-ben kritikus hibát talált a Base44 platformon. Egy nem titkos app_id értékkel és nem dokumentált végpontokkal a kutatók meg tudták kerülni a privát alkalmazások hitelesítését, még az SSO-védelmet is. A hibát kevesebb mint 24 órán belül javították, és a szolgáltató nem talált korábbi visszaélésre utaló jelet. A tanulság ettől még kellemetlen: ha minden alkalmazás ugyanarra a közös platformbiztonságra támaszkodik, egyetlen központi hiba sok ügyfél alkalmazását egyszerre teheti sebezhetővé.

A Georgia Tech Vibe Security Radar projektje 2026 tavaszáig 74 olyan CVE-t azonosított, amelynél AI-eszköz nyoma volt a sérülékenységet bevezető kódban; ezek közül 14 kritikus, 25 magas kockázatú volt. A kutatók külön kiemelték a mintaismétlés veszélyét: ha ugyanazok a modellek ugyanazokat a hibákat termelik sok projektben, a támadónak elég egyszer felismernie a mintát, utána automatizáltan végigpásztázhat több ezer kódbázist.

Igen, a hackerek vadásznak ezekre

Nem azért, mert személyes sértésnek veszik a vibe codingot. Azért, mert olcsó célpont. Az internetet folyamatosan automatizált szkennerek járják. Nyitott adatbázist, publikus adminvégpontot, kiszivárgott API-kulcsot, ismert sérülékenységet és hibás felhőbeállítást keresnek. Nem kell tudniuk, ki vagy. Elég, hogy válaszol a szerver.

A Palo Alto Networks Unit 42 EleKtra-Leak kutatásában egy támadó automatizáltan figyelte a GitHubra kikerülő AWS-kulcsokat, és a közzétételtől számított öt percen belül felhasználta az egyiket kriptobányászathoz. Öt perc. Ennyi idő alatt a fejlesztő még a sikeres deploy képernyőjét fotózza a LinkedIn-poszthoz.

A támadónak különösen kedvez az ismétlődő AI-kód. Ha egy modell tízezer projektben ugyanazt a hibás jogosultsági mintát, azonos endpoint-szerkezetet vagy kiszámítható konfigurációt használja, abból ipari vadászterület lesz. A hackernek nem kell minden alkalmazást kézzel megértenie. Elég felismernie a sablont.

Mekkora kárt okozhat a nemtudás?

A rövid válasz: a felhőszámlától a cég bezárásáig bármit.

•     Adatlopás: ügyféladatok, egészségügyi adatok, szerződések, belső dokumentumok és üzleti titkok kerülhetnek ki.

•     Adatmódosítás vagy törlés: a támadó nemcsak elvihet, hanem átírhat vagy megsemmisíthet adatokat.

•     Pénzügyi veszteség: ellopott fizetési tokenek, jogosulatlan tranzakciók, felhős erőforrásokkal végzett kriptobányászat és helyreállítási költségek.

•     Üzletmenet-kiesés: leálló szolgáltatás, elveszett megrendelések, szerződésszegés és kötbér.

•     Jogi és szabályozási következmény: incidensvizsgálat, értesítési kötelezettség, kártérítési igények és adatvédelmi eljárás.

•     Bizalomvesztés: ezt nem lehet egy új deployjal visszaállítani.

Az IBM 2026-os jelentése szerint egy adatbiztonsági incidens globális átlagköltsége 4,99 millió dollár volt. Ez nem azt jelenti, hogy minden nyitva hagyott kis alkalmazás ekkora számlát termel. Azt jelenti, hogy a biztonsági hibák ára nem a javításhoz szükséges két fejlesztői órával azonos. Beletartozik a felderítés, a leállás, az ügyfélvesztés, a jogi munka és az üzleti kár is. Egy kisvállalkozásnak nem kell ötmillió dolláros veszteség ahhoz, hogy vége legyen. Elég egy olyan incidens, amely után a legfontosabb ügyfelei többé nem hiszik el, hogy jó helyen van náluk az adat.

Az EU-ban a GDPR legsúlyosabb jogsértéseinél a maximális bírság 20 millió euró vagy az előző pénzügyi év teljes világpiaci árbevételének 4 százaléka lehet, attól függően, melyik a magasabb. A hatóság természetesen nem minden hibára szab ki maximumot. De a „nem tudtam, hogy az AI nyitva hagyta” nem adatvédelmi stratégia.

A vibe coding nem ellenség. A hozzá nem értésből lett önbizalom az.

Az AI-alapú fejlesztés óriási lehetőség. Egy tapasztalt fejlesztő kezében elképesztő gyorsító: megírja az ismétlődő kódot, teszteket készít, dokumentál, refaktorál, alternatívát keres. A szakember azonban tudja, mit kell kérdeznie, mit kell ellenőriznie, és mikor kell nemet mondania a modellnek.

A kezdőnek is remek eszköz prototípushoz, tanuláshoz, helyi automatizáláshoz vagy olyan személyes projekthez, amely nem kezel valós ügyféladatot és nem kap veszélyes jogosultságokat. A határ ott van, ahol valódi felhasználó, valódi pénz, valódi adat vagy valódi üzleti folyamat kerül a rendszerbe. Onnantól ez már nem játék.

Ha valaki nem tudja elmagyarázni az adatmodelljét, az engedélyezési logikát, a rendszerhatárokat, a hiba esetén követendő visszaállítást és a fenyegetési modellt, akkor ne élesítsen egyedül. Kérjen tapasztalt fejlesztői és biztonsági felülvizsgálatot. Ez nem szakmai kapuőrzés. Ugyanaz az alapelv, amiért egy AI-val megrajzolt ház statikáját sem a tulajdonos szemre hitelesíti.

A minimum, mielőtt valódi adatot engedsz rá

•     Dokumentált adatmodell, integritási szabályok és adattörlési életciklus.

•     Szerveroldali hitelesítés, jogosultságkezelés és bérlőnkénti adatelválasztás.

•     Titkok környezeti változóban vagy secrets managerben; semmi kulcs a kliensben vagy a publikus repóban.

•     Külön fejlesztői, teszt- és éles környezet, külön adatbázissal és korlátozott hozzáféréssel.

•     Automatikus mentés, dokumentált helyreállítás és ténylegesen végrehajtott visszaállítási próba.

•     SAST, függőség- és licencvizsgálat, secret scanning, dinamikus teszt és alapvető behatolási teszt.

•     Naplózás, riasztás, rate limit, erőforrás-korlát és incidenskezelési terv.

•     Független, hozzáértő emberi kód- és biztonsági felülvizsgálat az élesítés előtt.

A végső, kellemetlen mondat

A programozási szintaxis ismerete valóban kevésbé fontos lett. A rendszerek működésének ismerete viszont fontosabb, mint valaha.

A hacker pedig nem fogja megkérdezni, hány órát dolgoztál az alkalmazáson, mennyire voltál lelkes, vagy milyen szép lett a dashboard. Megnézi, nyitva maradt-e az ajtó. Ha igen, bemegy.

A vibe jó a zenéhez, az ötleteléshez és a prototípushoz. 

Források és háttéranyagok

1. Andrej Karpathy eredeti „vibe coding” bejegyzése (2025. február 2.)

2. Veracode: 2025 GenAI Code Security Report

3. Escape: több mint 2000 nagy hatású sérülékenység 5600 vibe-coded alkalmazásban

4. WIRED / RedAccess: több ezer, nyitva hagyott AI-val készült webalkalmazás

5. NVD: CVE-2025-48757 – Lovable / elégtelen Row-Level Security

6. Wiz Research: kritikus Base44-hitelesítési hiba

7. Georgia Tech: Vibe Security Radar és az AI által bevezetett CVE-k

8. Palo Alto Networks Unit 42: EleKtra-Leak – kiszivárgott AWS-kulcs felhasználása öt percen belül

9. The Register: a Replit-ügynök produkciós adatbázis-törlési esete

10. IBM: Cost of a Data Breach Report 2026

11. EUR-Lex: Általános adatvédelmi rendelet (GDPR), 83. cikk

Szerkesztői megjegyzés: a cikk a források állításait a közzétételük szerinti kontextusban használja; a Lovable CVE-besorolását a szállító vitatja, a Base44 esetében pedig nem találtak korábbi visszaélésre utaló jelet.