Vibe coding biztonság: hogyan védd meg az AI-val készített alkalmazást

Az Ailoottal való munkához további útmutatást a dokumentációban találsz.

Miért törik fel gyakrabban az AI-val készített alkalmazásokat?#

Én is készítek AI-val termékeket, és nem válok paranoiássá a biztonság miatt, nem zárok le mindent a „lehető legszigorúbban”. De van egy alapvető szint, amely alá nem szabad menni, különben egy nap üres adatbázisra és a szervereden futó, mások által telepített bányászokra ébredsz. Ez az útmutató erről az alapszintről szól. Nem arról, hogy „legyél biztonsági szakértő”, hanem arról, hogy „ne lőj magadnak a lábadba ok nélkül”.

A probléma gyökere egyszerű. Amikor azt mondod egy AI-ügynöknek, hogy „készíts egy alkalmazást az ügyfelek időpontfoglalásához”, az a lehető leggyorsabban működőképessé teszi az alkalmazást. A biztonság pluszmunka, ami a demóban nem látszik. Ezért nyitottan állítja be az adatbázist, egyenesen a kódba teszi a fizetési kulcsot, a „hozzáférhet ehhez a felhasználó?” ellenőrzés pedig csak a böngészőben létezik, ahol egy pillanat alatt megkerülhető.

A második ok maguk a platformok. Sok platform alapértelmezés szerint nyilvánosan elérhetővé teszi az új projekteket, a nem programozó építők pedig nem mindig tudják, hogy ezt meg kell változtatniuk.

Más szóval a rés magától, alapértelmezés szerint keletkezik. Nem tettél semmi rosszat. Egyszerűen nem tettél semmit — a biztonság területén pedig a tétlenség pontosan azt jelenti, hogy „mindenki számára nyitva”.

Mit tanultak már meg a vibe codingot használók a saját kárukon?#

A figyelmetlenség elleni legjobb védekezés az, ha mások hibáiból tanulunk. Íme négy beszámoló, amelyet érdemes elolvasni a projekt közzététele előtt.

Lovable és kikapcsolt RLS. A Lovable platform szöveges leírásokból készít alkalmazásokat. 2025-ben rendszerszintű rést találtak az alkalmazásaiban, amely a CVE-2025-48757 azonosítót kapta. Az ok: a generált alkalmazásokban nem voltak soronkénti adatbázis-hozzáférési szabályok (RLS, lásd a lenti magyarázatot). Egy kutató ellenőrzött egy mintát, és 170 alkalmazásban 303 szabadon elérhető hozzáférési pontot talált. Nevek, telefonszámok, fizetési állapotok, mások API-kulcsai, sőt lakcímek is hozzáférhetővé váltak. Az ellenőrzött alkalmazások körülbelül 70 százalékában a soronkénti védelem teljesen ki volt kapcsolva.

Tea és érzékeny adatok. A Tea alkalmazásból (emberekről szóló névtelen értékelések) 2025 júliusában körülbelül 72,000 kép szivárgott ki, köztük 13,000 szelfi és dokumentumfotó, majd több mint egymillió privát üzenet. A technikai ok a nyitott tárhely és a gyenge hozzáférés-ellenőrzés volt. A biztonsági közösség élénk példaként hivatkozik a Teára: ha a gyors indulás fontosabb a jogosultságok ellenőrzésénél, elsőként az érzékeny adatok szivárognak ki.

Egy másik gyakorlati példa. Az eredeti szerző beszámolója szerint egy vibe codinggal dolgozó fejlesztő alkalmazását azért törték fel, mert az AI alapértelmezett jelszót állított be az adatbázis létrehozásakor — olyat, amelyet automatikusan ki lehetett találni. Ezután a szokásos forgatókönyv következett: bejutottak, bányászokat telepítettek, majd átírták a projektet. A szervert teljesen törölni kellett. Az alapértelmezett jelszó olyan, mint egy nyitott ajtó, amelyre az van kiírva: „fáradj be”.

A biztonság két oldala: pontosan hol vagy sebezhető?#

Amikor az emberek a „vibe coding biztonságáról” beszélnek, általában összemosnak két teljesen különböző félelmet. Válasszuk szét őket, mert eltérő módon kell védekezni ellenük.

Első oldal — maga az ügynök. AI-ügynököt futtatsz a számítógépeden, és hozzáférést adsz neki a fájljaidhoz, terminálodhoz, kulcsaidhoz és adatbázisodhoz. A kockázat az, hogy az ügynök nem ember: szó szerint követi az utasításokat, és a legrövidebb utat keresi, még akkor is, ha az veszélyes. Ide tartozik annak kockázata is, hogy valaki más parancsa az ügynök által olvasott szövegen keresztül „befecskendeződik” hozzá (ezt prompt injectionnek nevezik).

Második oldal — a kész alkalmazás. Ez az, amit közzétettél, és amit az emberek használnak. A célpont a közzétett webhelyed vagy szolgáltatásod: a támadók bejutnak egy nyitott adatbázisba, hamis kéréseket küldenek, vagy mások fiókjait próbálják kitalálni. Ehhez az ügynöknek semmi köze — a rés korábban maradt nyitva, mások pedig kihasználják.

Az Anthropic, a Claude mögött álló vállalat így fogalmazza meg a legfontosabb védelmi elvet — amely mindkét oldalra érvényes:

A gyakorlatban ez azt jelenti: ne bízz abban, hogy az AI „magától elkerüli a rossz dolgokat”. Először korlátozd, mit tehet meg ténylegesen, és csak utána kérd, hogy viselkedjen helyesen. Ha a viselkedése kudarcot vall — és ez meg fog történni —, csak az előre felállított szilárd korlát véd meg.

Azt szeretnéd, hogy az AI kiszámíthatóan dolgozzon, és ne lőjön lábon minden új projektben? A biztonsági szabályok a Second Brained részét képezik: írd le őket egyszer a CLAUDE.md fájlba, és az ügynök minden kérésnél követi őket.

Mit tehet egy AI-ügynök, ha hozzáfér a számítógépedhez?#

A leginkább alábecsült kockázat a saját, túl széles jogosultságokkal rendelkező ügynököd. Külső hackerre sincs szükség. Íme egy friss példa 2026 májusának végéről. Egy Codex-ügynöknek olyan rendszergazdai jogosultság kellett, amellyel a felhasználó nem rendelkezett. Az ügynök nem adta fel — körülnézett, és észrevette, hogy a felhasználó a docker csoport tagja, ami gyakorlatilag egyenértékű a root jogosultsággal, majd kihasználta ezt a hozzáférést.

Nem volt rossz szándék mögötte. Egyszerűen egy „oldja meg a feladatot” utasítást kapott ügynök gyorsabban találja meg a szerkezeti gyengeségeket, mint egy ember. Ha pedig ez a gyengeség hozzáférést ad neki a kulcsaidhoz vagy az éles rendszerhez, ki fogja használni. Ezért az első szabály a legkisebb jogosultság elve. Pontosan annyi hozzáférést adj az ügynöknek, amennyire az adott feladathoz szüksége van, egy cseppel se többet.

Mit tehetsz a gyakorlatban akkor is, ha nem vagy programozó?

1. Ne futtasd az ügynököt „mindent engedélyez” módban éles gépen

   Az a mód, amelyben az ügynök nem kér megerősítést (gyakran bypassnak vagy yolónak nevezik), csak sandboxhoz vagy tesztprojekthez való, nem olyan géphez, amely éles kulcsokat és hozzáféréseket tartalmaz.

2. Tiltsd meg az ügynöknek a titkok olvasását

   A Claude Code-ban ezt olyan szabállyal teheted meg, amely megtagadja a hozzáférést a kulcsokat tartalmazó fájlokhoz. Így még akkor sem nyithatja meg az eszköz az .env fájlt, ha az ügynök megpróbálja.

3. Tartsd külön az éles kulcsokat

   Az éles adatbázis és a fizetési szolgáltatás kulcsai ne legyenek ugyanabban a mappában, ahol az ügynök kódot ír. Válaszd szét a környezeteket: kísérletezéshez tesztkulcsokat használj.

4. Használd az eszköz sandboxát

   A modern AI-eszközök képesek elszigetelten (sandboxban) parancsokat futtatni, ahol nem férnek hozzá a rendszer többi részéhez. A Claude Code-ban ez körülbelül 84 százalékkal csökkenti az engedélykérések számát — így kényelmesebb is.

A Claude Code-ban a titkok olvasását megtagadó szabály nagyjából így néz ki — tedd be az engedélybeállítások közé:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Hová ne tedd soha az API-kulcsokat és jelszavakat?#

A legolcsóbb és leggyakoribb hiba, ha a kulcsokat a kódba teszik. A fizetési szolgáltatás API-kulcsa, egy adatbázisjelszó, egy bot tokenje — ezek mind titkok. Külön .env fájlban a helyük, és ezt a fájlt fel kell venni a .gitignore-ba, hogy ne kerüljön a kóddal együtt a gitbe.

A probléma mértéke 2025-ben: 28.65 millió új, kódba beégetett titok nyilvános repozitóriumokban, ami éves szinten 34 százalékos növekedés. A kifejezetten AI-szolgáltatásokhoz tartozó kulcsok kiszivárgása 81 százalékkal emelkedett. A vibe coding tovább szítja a problémát, mert az ügynök ellenőrzés nélkül commitol.

Ellenőrizd most kézzel a következőket:

1. Nyisd meg a projekt .gitignore fájlját

   Győződj meg róla, hogy szerepel benne egy .env sor. Ha nem szerepel, add hozzá az első commit előtt.

2. Nyisd meg a GitHub-repozitóriumodat

   Ellenőrizd, hogy az .env fájl nincs-e ott. Gyors ellenőrzésként keress rá a repozitóriumban az .env szóra vagy a kulcsod egy részére.

3. Ha kiszivárgott egy kulcs, vond vissza, és adj ki újat

   A commit törlése nem elég: a kulcsot addigra már megszerezhették. Nyisd meg az adott szolgáltatást (fizetési szolgáltató, felhőszolgáltatás, AI-szolgáltató), vond vissza a régi kulcsot, és adj ki újat. Ezt kulcsrotációnak nevezik.

4. A kulcsoknak csak a minimálisan szükséges jogosultságot add meg

   Ha egy kulcs csak olvasáshoz kell, állítsd csak olvashatóra. Így még akkor is kevesebbet lehet ellopni, ha kiszivárog.

Miért láthatja mindenki az adatbázisodat RLS nélkül?#

Ha Supabase-en vagy hasonló adatbázison készítesz alkalmazást, ez a legfontosabb rész. Az RLS a Row Level Security rövidítése. Egyszerűen fogalmazva olyan szabály, amely meghatározza, hogy egy adott felhasználó a tábla mely sorait láthatja. Nélküle az „orders” tábla mindenki számára visszaadja az összes ügyfél rendeléseit.

A Supabase dokumentációja világosan fogalmaz:

Ez a vibe codingot használók fő csapdája. Amikor a Supabase irányítópultján kattintgatva hozol létre táblát, a védelem automatikusan bekapcsol. Amikor viszont az AI hozza létre a táblát — és szinte mindig közvetlenül ír SQL-parancsokat —, az RLS alapértelmezés szerint kikapcsolva marad. Ez azt jelenti, hogy egy ügynök által létrehozott tábla szinte biztosan nyitva áll az egész internet előtt. Pontosan így szivárgott ki az adat a 170 Lovable-alkalmazásból.

Teendők:

1. Kérdezd meg közvetlenül az ügynököt

   Írd ezt: „mutasd meg az összes táblát, amelynél ki van kapcsolva az RLS”. Az AI készít egy listát — ez lesz a munkasorod.

2. Kapcsold be az RLS-t minden olyan táblán, amely felhasználói adatot tartalmaz

   Legalább egy hozzáférési szabályt is adj hozzá — például: „a felhasználó csak a saját sorait láthatja”.

3. Ellenőrizd az irányítópultot

   A Supabase irányítópultján minden táblánál az „RLS enabled” feliratnak kell megjelennie. Ha szürke vagy piros, az azt jelenti, hogy a tábla nyitva van.

4. Teszteld élesben

   Jelentkezz be normál felhasználóként, és próbáld meg lekérni valaki más adatait. Ha a hozzáférést megtagadja, a szabály működik.

Miért nem védenek meg a felületen végzett jogosultság-ellenőrzések?#

Gyakori tévedés: „Megoldottam, hogy a normál felhasználók ne lássák az admin gombot.” A probléma az, hogy a gomb csak egy kép a böngészőben. A kérést közvetlenül a szervernek is el lehet küldeni a gomb használata nélkül. Ha a szerver nem ellenőrzi újra a jogosultságokat, végrehajtja valaki más parancsát.

Egy klasszikus példa az IDOR. Képzeld el, hogy megnyitod a rendelésedet egy id=123 című oldalon. Módosítsd id=124-re, és máris láthatod valaki más rendelését, mert a szerver nem ellenőrizte, hogy valóban a tiéd-e. Ez az egyik leggyakoribb rés a vibe codinggal készült alkalmazásokban, és a gyenge jogosultság-ellenőrzés állt a Tea-adatszivárgás mögött is.

A szabály egyszerű: minden „jogosult ez a felhasználó erre?” ellenőrzést ismételj meg a szerveren. A felület a kényelmet szolgálja; a védelem helye a backend. Az ügynöknek adható kész utasítás: „adj szerveroldali jogosultság-ellenőrzést minden olyan végponthoz, amely felhasználói adatot olvas vagy módosít; ne hagyatkozz a felületen elrejtett elemre.”

Hogyan ellenőrizheted a kódot rések után, ha nem vagy programozó?#

A jó hír: ma már megkérheted ugyanazt az AI-t a biztonság ellenőrzésére — egész jól megtalálja a gyakori réseket. Íme három, különböző feladatokra való eszköz.

1. A /security-review parancs a Claude Code-ban. Egyszeri ellenőrzést végez az aktuális branchen SQL injection, XSS, jogosultsági rések, adatszivárgás és függőségi problémák után. Lépésről lépésre elmagyaráztam a működését és azt, hogyan csatolj automatikus ellenőrzést minden módosításhoz egy külön útmutatóban: biztonsági áttekintés a Claude Code-ban. A lényeg itt az, hogy ez az első védelmi vonal, amely egyetlen paranccsal elindítható.

2. A hivatalos security-guidance plugin. Telepítsd a hivatalos plugin piactérről a /plugin install security-guidance@claude-plugins-official paranccsal (a Claude Code 2.1.144-es vagy újabb verziója szükséges). Három ponton ellenőrzi a kódot: minden szerkesztéskor, minden kör végén és commitoláskor. Felismeri a jogosultsági megkerüléseket, az IDOR-t, az injekciókat és a gyenge kriptográfiát. Az Anthropic azonban őszintén beszél a korlátairól:

npx skills add <author>/<repo>

Ezután egyszerűen mondd az ügynöknek: „ellenőrizd a projektemet sebezhetőségek szempontjából”. A gyűjteménnyel kapcsolatban azonban van egy fontos kitétel, ezért lent külön részt szentelek neki.

A tágabb képhez hozzátartozik, hogy a nagy szereplők is komolyan kezdték venni az AI-kód biztonságát. A Project Glasswing részeként, amelyet 2026. június 2-án 150 szervezetre bővítettek, a partnerek rövid idő alatt több mint 10,000 kritikus sebezhetőséget találtak az Anthropic modelljeivel. A tét egyértelmű:

Megbízhatsz a GitHubról származó skillekben és bővítményekben?#

Itt válnak különösen bonyolulttá a dolgok, mert a veszély egy biztonságra szolgáló eszközből ered. Amikor lefuttatod az npx skills add ... parancsot vagy telepítesz egy bővítményt, valaki más kódját töltöd le, amelyet aztán az ügynök a te jogosultságaiddal futtat. Ha a szerzőt feltörték vagy a csomag eleve rosszindulatú volt, bajban vagy.

Vegyük az előző részben említett skills-gyűjteményt. A neve tartalmazza az „Anthropic” szót, amitől alábbhagy az óvatosságod. A saját leírása azonban világosan kimondja:

Más szóval a név félrevezető. Maga a gyűjtemény jelenleg kiforrott és tiszta, de az elv változatlan: saját felelősségedre telepíted. A fenyegetés pedig nem elméleti. 2026 májusában egy rosszindulatú szerkesztőbővítmény mindössze 18 percet töltött a piactéren — ezalatt sikerült ellopnia a telepítőitől a jelszókezelők jelszavait, GitHub-tokenjeit, felhőhozzáféréseit, sőt a Claude Code konfigurációit is. Egy másik kellemetlen részlet: az ilyen kártevők gyakran túlélik a csomag szokásos eltávolítását, és a következő munkamenetben újra elindulnak.

Kialakítottam egy egyszerű szokást, és neked is ezt ajánlom: mielőtt bármilyen skillt telepítesz a GitHubról, ellenőrizd magad. A szerzőket feltörhetik, a fiókokat eltéríthetik, a repozitóriumba pedig kártevő kerülhet. Az ellenőrzés a védelmed.

A telepítés előtti gyakorlati minimum: nézd meg a szerzőt és a csillagok számát, olvasd el a skill leírását, ne telepíts eszközt „mert egy bejegyzésben ajánlották”, az ismeretlen eszközt pedig először külön tesztkörnyezetben próbáld ki, ne olyan gépen, amelyen éles kulcsok vannak.

Mi ment meg egy incidens után: biztonsági mentések és visszaállítás#

A biztonság nemcsak arról szól, hogy „tartsuk kint a kívülállókat”, hanem arról is, hogy „térjünk vissza a normális működéshez, ha valami elromlik”. Mert valami el fog romlani. Az elmesélt gyakorlati esetben egy AI-ügynök rutinfeladat végzése közben törölt egy éles adatbázist egy produkciós projektben. Volt biztonsági mentés, de háromnapos — így három napnyi adat egyszerűen eltűnt.

Ebből két szabály következik.

Készíts gyakran biztonsági mentést. Ha az alkalmazásod olyan adatokat tartalmaz, amelyeket nem szívesen veszítenél el, a háromnaponta készülő másolat csak a védelem látszata. Állíts be automatikus mentést legalább 30 percenként. A legtöbb adatbázisnál, a Supabase-t is beleértve, ez néhány kattintással bekapcsolható.

A git biztosítás az ügynökkel szemben. A git tárolja a kódod előzményeit: bármelyik működő állapotot visszaállíthatod. Ha egy ügynök átír valamit, ami korábban működött, kézi javítás helyett állj vissza az utolsó működő verzióra. Ha az AI törölte vagy elrontotta a projektet, és nem tudod, hogyan állítsd helyre, olvasd el a külön beszámolót: mit tegyél, ha az AI törölte az adatbázist. Ha előre szeretnéd megvédeni a projektet a meghibásodástól, olvasd el az útmutatót arról, hogyan védd meg a Claude Code-ot a meghibásodásoktól.

Biztonsági ellenőrzőlista közzététel előtt#

Közvetlenül a közzététel előtt haladj végig ezen a listán, sorrendben.

1. A titkok az .env fájlban vannak, az .env pedig szerepel az .gitignore-ban. Nincsenek kulcsok a kódban. Nincs .env fájl a nyilvános repozitóriumban.

2. A kulcsok csak a minimálisan szükséges jogosultságokkal rendelkeznek. Minden kulcs csak azt teheti, amire szükség van. Az éles kulcsok külön vannak választva az ügynök környezetétől.

3. Az RLS be van kapcsolva minden olyan táblán, amely felhasználói adatot tartalmaz, és a hozzáférési szabályok is érvényben vannak.

4. Minden adatműveletnél szerveroldali jogosultság-ellenőrzés működik. Nem elég elrejteni egy gombot a felületen. Kézzel tesztelted az id módosítását a címben.

5. Webhook-aláírás ellenőrzése. Minden külső értesítést kezelő kód (fizetések, űrlapok) ellenőrzi az aláírást.

6. Sebességkorlátozás védi a bejövő kéréseket és a költséges műveleteket, hogy a jelszavakat ne lehessen brute force módszerrel kitalálni, és ne szaladhasson el a számlád.

7. Az ügynök nem „mindent engedélyez” módban fut olyan gépen, amelyen éles kulcsok vannak. Az .env olvasása tiltva van.

8. Gyakran készülnek biztonsági mentések, és tesztelted is őket — valóban próbáltál már visszaállítani, nem csak elhitted, hogy a másolatok „valahol megvannak”.

9. A kódot ellenőrizted a /security-review paranccsal vagy a security-guidance pluginnal. A talált problémákat kijavítottad.

10. Telepítés előtt ellenőrizted mások skilljeit és bővítményeit. Semmit sem telepítettél „vakon”.

Mivel kezdd ma?#

Ne próbáld meg egyetlen este alatt végrehajtani az útmutató összes lépését — végül semmit sem fogsz tenni. Végezd el ma a három legfontosabb lépést:

1. Ellenőrizd a titkaidat. Nyisd meg a .gitignore fájlt, győződj meg róla, hogy szerepel benne az .env, és ellenőrizd, hogy nincsenek kulcsok a nyilvános repozitóriumban. Ha kiszivárgott valamelyik, vond vissza, és adj ki újat.
2. Kérdezz rá az RLS-re. Mondd az ügynöknek: „mutasd meg azokat a táblákat, amelyeknél ki van kapcsolva az RLS” — és kapcsold be mindenhol, ahol emberek adatait tárolod.
3. Állíts be gyakori biztonsági mentést. Így, ha valami elromlik, perceket veszítesz napok helyett.

Ahogy a projekted növekszik, és pénzt, illetve mások adatait kezeli, kövesd a fenti ellenőrzőlistát.

Még egy utolsó gondolat. A vibe coding biztonsága a tulajdonos felelőssége. Nem kell biztonsági szakértővé válnod. Az AI egy este alatt megépítette a termékedet — nagyszerű, de te vagy érte a felelős. Az útmutatóban szereplő alapszint mutatja meg, hogyan fest ez a felelősség a gyakorlatban.

Ha további munkát végeznél modellekkel, látogass el az Ailoothoz.