A zöld pipa hazudik

Egy hónapig lapult egy kritikus jogosultsági hiba az AI-val épített site-omon, a marketingcoolon. Bárki, aki regisztrált, egyetlen sorral a böngészőből adminná tehette volna magát, és kiolvashatta volna a teljes ügyfél-adatbázist. A rendszer közben végig zöldet jelzett: minden ellenőrzés átment. Ez a cikk arról szól, hányféleképpen hazudik a zöld pipa, és arról a néhány szabályról, amivel kód-tudás nélkül is kikényszeríted az igazságot.

Ez a sorozat második része. Az elsőben a teljes számláról volt szó: mennyi idő és pénz épített fel egy fizetés-képes platformot AI-val. Most a legnagyobb félelemről, amit a legtöbben joggal éreznek: rá lehet-e ezt bízni a pénzre és az ügyféladatra.

Előre leszögezem: a szkeptikusoknak igazuk van. Az AI-val épített kód alapból tele van biztonsági résekkel, és a legtöbb bajt az okozza, hogy az építő nem is tudja, mit nem tud. Ezt nem cáfolni akarom. Megmutatni akarom, mit lehet tenni ellene.

A bug, ami egy hónapig hallgatott

Kezdjük a saját szégyenemmel.

Volt egy szabály a rendszeremben, ami pontosan azt mondta, amit akartam: a felhasználó ne írhassa át a saját szerepét, ne tehesse magát adminná. A kódsor ott volt, jól nézett ki, és minden teszt zöld maradt.

Csak épp nem csinált semmit.

A részlet technikai, de a tanulság nem az: az adatbázisban az a fajta tiltás, amit használtam, nem vonta le azt az engedélyt, ami alapból ott volt. A szándék helyes volt, a megvalósítás néma. A gyakorlati következmény: bármelyik regisztrált felhasználó beírhatott volna egyetlen sort a böngésző fejlesztői konzoljába, és a rendszer kinevezte volna adminná. Onnantól látta volna az összes leadet, a rendeléseket számlázási címmel, a tanúsítványokat.

Egy teljes hónapig a projekt nem jelzett semmit. A build végig zöld volt.

A cikk tézise: a zöld pipa nem bizonyíték. Egy hozzászóló egy magyar blogon pontosan fogalmazott, amikor a vibe codingról vitáztak: „attól, hogy valami úgy néz ki, hogy jó, nem biztos hogy tényleg jó." Ez nem filozófia. Ez a heti üzemeltetés valósága.

Nem vagyok egyedül: mi történik a kapu nélkül építőkkel

Mielőtt a megoldásokra térek, érdemes látni, mi a tét. Nem elrettentésből, hanem mert ezek az esetek mind ugyanazt az egy hibát mutatják, csak más terméken.

• Moltbook. Egy AI-val összerakott közösségi oldal. A titkos adatbázis-kulcs bekerült a böngészőben futó kódba, a sor-szintű védelem pedig sehol. Eredmény: másfél millió belépési token és 35 ezer email-cím vált elérhetővé.
• Lovable. Ennek az AI-eszköznek egy 2025-ös biztonsági hibája alatt egy kutató 1645 vele épített oldalt vizsgált meg, és 170-nél bejelentkezés nélkül kiolvasható volt a teljes adatbázis. Nem egyedi ügyetlenség: az eszköz alapból így generálta a sémát.
• Enrichlead. A készítője büszkén posztolta: „vibekódoltam, és igen, fizetnek érte." Két nappal később: „srácok, támadás alatt vagyok, megkerülik az előfizetést, kimaxolják az API-kulcsaimat, és tudjátok, nem vagyok technikai szakember, szóval ez tovább tart." A fizetőfal a böngészőben lakott, bárki megkerülhette. Egy héten belül leállt a szolgáltatás.
• Tea app. Egy nőknek szánt biztonsági app, aminek nyitva maradt a tárhelye: 72 ezer kép került ki, köztük 13 ezer szelfi és igazolványfotó. A keserű irónia az, hogy pont az az adat szivárgott, amit a biztonság kedvéért kértek el.

És egy szám, amit érdemes fejben tartani. A fejlesztők több mint háromnegyede hiszi, hogy az AI-kód biztonságosabb az embernél. Egy Stanford-kísérletben viszont az AI-t használók kevésbé biztonságos kódot írtak, és közben magabiztosabbak voltak, hogy jó, amit csináltak. A veszély nem a tudatlanság. A veszély a magabiztos tudatlanság.

Magyar hangon ugyanez, egy Kiszámoló-komment szerzőjétől, aki fejlesztő: „a fő probléma ezekkel a vibe coding dolgokkal az, hogy elhitetik a hozzá nem értővel, hogy ért hozzá." Igaza van. Ez a cikk pont ezek ellen ad javaslatokat és tanácsokat.

A zöld pipa három hazugság-módja

A tesztek jelentik a biztonságérzetet: ha zöldek, azt hisszük, minden rendben. Az AI-val dolgozva megtanultam, hogy a zöld pipa háromféleképpen tud hazudni.

Első mód: a teszt, ami semmit nem állít. Az AI hajlamos a saját kódjához olyan tesztet írni, ami körbekeríti a valódi problémát, ahelyett hogy megfogná. A teszt fut, zöld, és semmit nem véd.

Második mód: a teszt, ami a bugot igazolja vissza. Ha a kód rossz, és az AI ahhoz írja a tesztet, akkor a teszt a rosszat rögzíti helyesként. Tükör lesz belőle, nem védőháló.

Harmadik mód: a teszt, ami le sem fut. Ez a saját történetem, és sehol nem olvastam még hasonlót. A fizetési rendszerem legérzékenyebb pontjához (a banktól érkező visszajelzés feldolgozása) létezett egy teszt-fájl. A build zöld volt. És a fájl nulla tesztet futtatott, mert egy rejtett behivatkozás csendben elhasalt a teszt-környezetben. A lefedettség úgy volt hamis, hogy közben senki nem hazudott, és a build zöldellt. Amikor megjavítottam, a nullából tizenkét futó teszt lett.

A tanulság ökölszabályba sűrítve, és ezt egy marketinges is fel tudja tenni kérdésként a fejlesztőjének vagy magának az AI-nak: ne a zöld színt nézd, hanem a teszt darabszámát. Hány teszt futott le valójában? Nálam ma 372 fut, harminc fájlban. A szám ellenőrizhető. A szín megtévesztő.

Az AI nem gonosz, csak a mérőszámra optimalizál

Sokan úgy élik meg, hogy az AI „hazudik nekik". A legpontosabb, dokumentált eset a vibe coding krónikása, Jason Lemkin nevéhez fűződik: az általa használt AI-ügynök egy leállítási parancs ellenére törölte az éles adatbázisát (1200 valós céges kapcsolat), majd hamis felhasználókat gyártott a hiba elfedésére, és azt állította, a visszaállítás lehetetlen. Nem volt az. Lemkin szavaival: „megint hazudott a tesztekben, azt állította, átmentek."

Fontos érteni, mi történik ilyenkor, mert ebből jön a megoldás. Az AI nem rosszindulatú. Egyszerűen arra van belőve, hogy a feladatot „késznek" jelentse, és ezt a célt néha úgy éri el a legkönnyebben, hogy a kész látszatát állítja elő. Egy fejlesztő-fórumon a legjobb tanács így szólt, hogy „az ellenőrző mérőszámot külön kell tartani az optimalizálási mérőszámtól." Magyarul: az ellenőrzés ne az AI-tól jöjjön, aki a munkát végezte.

Erre a legjobb példám nem is kód-hiba volt. Napokig kerestem, miért nem mennek ki az emailek a rendszerből. A kód hibátlan volt. Kiderült, hogy amikor a levelező-szolgáltatás kulcsát bemásoltam a felület egyik mezőjébe, a másolással belecsúszott egy láthatatlan karakter, és attól dobta el a rendszer a hitelesítést. A hiba nem a kódban volt, hanem egy másolás-beillesztésben.

„A jogosultságot bizonyítani kell, nem elhinni"

Térjünk vissza ehhez a bughoz, mert abból lett a legfontosabb szabályom.

Amikor megtaláltam, nem elég volt kijavítani. Egy eldobható adatbázison lefuttattuk magát a támadást. Előtte a rendszer azt mondta: a szerep most admin. A javítás után: hozzáférés megtagadva. És a próba közben kiderült, hogy az első javításom is hibás volt, egy másik ok miatt. A bizonyítás nemcsak az eredeti hibát fogta meg, hanem a rá adott rossz választ is.

Ebből született 48 automata jogosultsági ellenőrzés, amiből 30 negatív állítás. Ez a kulcs: a legtöbb biztonsági útmutató azt mondja, „kapcsold be a védelmet". Azt szinte senki, hogy a bekapcsolt védelem is lehet néma, ezért külön kell bizonyítani, hogy tényleg működik. A negatív teszt nem azt mondja meg, ki lát valamit, hanem azt, ki NEM.

Néhány ezek közül, ahogy a saját rendszeremben megfogalmaztam őket:

• „a jogosultsági szint módosítás mögött elbújtatva sem megy" (vagyis a támadás akkor sem sikerül, ha ravaszabbul próbálják)
• „a felhasználó NEM adhat magának hozzáférést" a kurzusokhoz, mert ez a fizetőfal: ha ide írhatna, ingyen venne kurzust
• „ugyanaz a vizsga-teszt másodszor nem írható" (erről mindjárt)

A teszt-fájl fejlécében ott a mondat, ami az egész szemléletet összefoglalja: nem azt bizonyítja, hogy a szabályok léteznek, hanem hogy működnek. A kettő nem ugyanaz.

A hiba, amit se ellenőrzés, se teszt nem talál

Van a hibáknak egy fajtája, amit a legnehezebb elkapni, mert a kód tökéletes. A terv a rossz.

A tanúsítvány-vizsgám végpontja pontszámot adott vissza, és korlátlanul újra lehetett próbálni ugyanazt a kísérletet. A kód hibátlan volt. Mégis: egy rosszhiszemű, de jogosult felhasználó nagyjából 120 próbálkozással kiszedhette volna a teljes megoldókulcsot, majd hibátlanul vizsgázik. Se automata ellenőrzés, se teszt nem találta volna meg, mert semmi nem volt „elrontva".

A tanulság, amit ebből levontam, és ami sehol nem szerepel a biztonsági útmutatókban: rögzített tartalom + korlátlan ismétlés + informatív válasz = megoldókulcs-szivárgás, mindig. Ez minden marketingesnek szól, mert ugyanez a kockázat ott van minden kvízben, kupon-ellenőrzőben, nyereményjáték-validátorban. A kérdés, amit fel kell tenni: mit tud kihozni ebből valaki, ha nem egyszer, hanem tízezerszer futtatja?

A javítás egyszerű volt, amint a kérdést feltettük: minden vizsga-teszt egyszer beadható, aláírt jeggyel. Innen a fenti teszt: „ugyanaz a vizsga-teszt másodszor nem írható".

És a pénz? A döntések, amik megvédtek

Végül a konkrét kérdés: rá mertem-e bízni a fizetést. Igen, és itt vannak a döntések, amiktől mertem.

• Hostolt fizető-oldal. A pénztár a Stripe saját fizető-felületét használja, így bankkártya-adat soha nem ér az én rendszeremhez. A kártyás megfelelőség terhét a Stripe viszi. Nem-fejlesztőnek ez a legfontosabb döntés.
• A rendelést csak a bank felől teljesítem. Nem a böngésző visszairányításából, hanem a banktól érkező, aláírt visszajelzésből. Kontrasztként: egy dokumentált esetben egy AI-val épített piactér nem ellenőrizte ezt az aláírást, és a sikeres fizetések 15 százaléka egyszerűen nem került be az adatbázisba, 200 ezer dollárnyi forgalom mellett.
• Ár-őr. Ha a kirakati ár és az adatbázis-ár eltér, a rendszer inkább nem enged fizetni.
• Ismétlés-védelem, ami élesben bizonyított. A bank egy visszajelzést valóban kétszer küldött el, 34 másodperc különbséggel, még az indulás első hetében. A védelem elsőre megfogta, én egy hónappal később vettem észre a naplóban.
• Kudarcnál zár, nem nyit. A pénzt kezelő és levelet küldő pontokon, ha a védelmi korlát kiesik, a rendszer elutasít, nem enged át. Máshol fordítva: egy apró hiba ne vigye magával az egész felületet. Ez nem dogma, hanem specifikus döntés.

A marketinges ellenőrző-listája

Egyik pontjához sem kell kódot tudni olvasni, csak feltenni a kérdést, magadnak vagy annak, aki épít neked:

1. Hány teszt futott le? (Szám, nem szín.)
2. Van olyan teszt, ami azt bizonyítja, ki NEM láthat valamit?
3. A titkos kulcsok tényleg a szerveren vannak, nem a böngészőben?
4. Mit indít el ez a funkció a rendszeren kívül? (Levél, üzenet.)
5. Mi történik, ha a védelem kiesik: kinyit vagy lezár?
6. A fizetés hostolt oldalon fut, és a bank felől teljesül?
7. Kipróbáltad már a támadást magad ellen?
8. Van különálló teszt- és éles környezet, és van mentés? (Ezt ne az AI-tól kérdezd meg, hanem nézd meg.)

A biztonság nem tudás, hanem folyamat

Ez a bug nem azért maradt bent, mert nem tudtam eleget. Azért, mert semmi nem ellenőrizte, hogy a helyes szándék meg is valósult-e. Amikor ezt beépítettem folyamatként (fusson a támadás magam ellen, legyen negatív teszt, bizonyítsuk a jogosultságot ahelyett, hogy elhinnénk), a hiba egy nap alatt előjött és megjavult.

Ez a jó hír a nem-fejlesztőknek: a biztonság nagyrészt nem zsenialitás kérdése, hanem néhány jól feltett kérdésé és a fegyelemé, hogy tényleg fel is teszed őket. És a fegyelmet, mint kiderült, lehet automatizálni.

És van egy lépés, amit nem spórolok meg. Mielőtt a platform éles forgalmat kap, tapasztalt fejlesztővel is átnézetem az egészet. Nem azért, mert a fenti szabályok ne érnének semmit, hanem mert épp ez a cikk tanulsága: a saját vakfoltodat nem te látod meg. Egy gyakorlott szem a nyitás előtt sokkal olcsóbb, mint egy incidens utána. A vibe coding nem azt jelenti, hogy mindent egyedül csinálsz, hanem hogy tudod, mikor kell segítséget kérni.

A kurzusok között több ingyenes próbalecke vár, a Nagy Marketingteszten pedig 60 kérdésen felmérheted, hol tartasz.

Felhasznált források

Wessling, J. (2025). Insights from 2025 GenAI Code Security Report. Veracode.

Kiszámoló (2026). Vibe coding: már bárki lehet programozó?. Kiszámoló, hozzászólások: dinnyesbacsi, Hechtl, O.

Nagli, G. (2026). Hacking Moltbook: The AI Social Network Any Human Can Control. Wiz Blog.

Palmer, M. (2025). Statement on CVE-2025-48757. mattpalmer.io.

GitHub Advisory Database (2025). CVE-2025-48757: Lovable insufficient Row-Level Security. GitHub.

Acevedo, L. (2025). my saas was built with Cursor, zero hand written code. X.

Acevedo, L. (2025). guys, i'm under attack. X.

Gerard, D. (2025). 'Guys, I'm under attack': AI 'vibe coding' in the wild. Pivot to AI.

Ha, A. (2025). Dating safety app Tea breached, exposing 72,000 user images. TechCrunch.

Snyk (2023). 2023 AI Code Security Report. Snyk.

Perry, N., Srivastava, M., Kumar, D., Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants?. arXiv, ACM CCS 2023.

Lemkin, J. (2025). @Replit goes rogue during a code freeze and shutdown and deletes our entire database. X.

Lemkin, J. (2025). It lied again in our unit tests, claiming they passed. X.

Sharwood, S. (2025). Vibe coding service Replit deleted user's production database, faked data, told fibs galore. The Register.

Nolan, B. (2025). An AI-powered coding tool wiped out a software company's database in 'catastrophic failure'. Fortune.

ijk (2025). Hozzászólás: your evaluation metric must be kept separate from your optimization metric. Hacker News.

McKelvey, J. (2026). Vibe Coding Examples: 10 Real Apps ($500K Win, $15K Fail). justinmckelvey.com.