Securitatea unei aplicații vibe coded: ce verifici la lansare

Securitatea unei aplicații vibe coded nu se vede în preview: interfața arată bine, autentificarea merge, plata de test trece, iar baza de date poate fi, în același timp, deschisă oricui îi cunoaște adresa. Ghidul este pentru cine a construit cu Lovable, Bolt, Replit sau v0, nu are un programator în echipă și urmează să primească utilizatori și plăți reale. Fiecare verificare are aceeași formă: ce faci, ce ar trebui să vezi și ce înseamnă dacă vezi altceva.

De ce „merge” nu înseamnă „e sigură”

Tot ce rulează în browserul vizitatorului este public: codul paginii, adresele la care trimite cereri și cheile cu care se prezintă. Oricine le poate citi și poate trimite cereri direct către baza ta de date, ocolind butoanele și formularele. Contează doar ce acceptă să răspundă serverul.

Două cazuri publice arată unde duce confuzia. Primul este cel povestit în ghidul de vibe coding: înregistrarea CVE-2025-48757 din baza NVD descrie o politică Row Level Security insuficientă în Lovable (până la 15 aprilie 2025), care permite unor atacatori neautentificați să citească sau să scrie în tabelele site-urilor generate. Aceeași înregistrare notează că furnizorul contestă încadrarea, fiindcă fiecare client își asumă protejarea datelor aplicației sale. Oricine ar avea dreptate, răspunderea ajunge la tine.

Al doilea e din februarie 2026: Wiz Research a analizat Moltbook, o rețea socială pentru agenți AI al cărei fondator spusese public că nu a scris nicio linie de cod pentru ea. Cheia din browser era una publicabilă, deci nimic greșit până aici; baza de date nu avea însă RLS, așa că aceeași cheie citea și scria în toate tabelele. Au fost expuse 1,5 milioane de tokenuri de autentificare și 35.000 de adrese de email.

Mecanismul din spate (autentificare față de autorizare, de ce cheia din browser e publică prin construcție) este explicat în modulele de integrări și de securitate din cursul Vibe Coding: de la prompt la aplicație; aici rămânem la execuție. Alegerea uneltei e tratată în comparația Lovable, Bolt și Replit Agent, iar măsurătorile pe cod generat în articolul pentru echipe despre codul generat de AI înainte de producție.

Exemplele folosesc denumirile din Supabase: Lovable își descrie backendul integrat ca fiind construit pe fundația open-source Supabase, iar Bolt și v0 se pot conecta la el. Testele se rulează numai pe aplicația ta.

Harta verificărilor

Duratele sunt orientative, pentru o aplicație cu 5–10 tabele și un singur tip de utilizator.

1. Row Level Security: cine vede ce rânduri

Row Level Security (RLS) este mecanismul PostgreSQL prin care regulile de acces stau pe tabel, nu în aplicație: un filtru adăugat automat la fiecare cerere, de tipul „întoarce doar rândurile celui care întreabă”. Documentația Supabase despre RLS e directă: un tabel dintr-o schemă expusă, fără RLS, poate fi citit și scris de orice rol care are drepturi pe el.

Cum vezi dacă RLS e activ pe fiecare tabel

Ce faci. Deschizi Security Advisor din panoul Supabase (în Lovable, vederea Security a proiectului; în Bolt, fila Security din setările bazei de date). Sau rulezi în SQL Editor:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Prima linie cere numele fiecărui tabel și starea RLS, a doua numește catalogul în care PostgreSQL ține evidența tabelelor, a treia păstrează doar schema la care ajunge aplicația.

Ce ar trebui să vezi. true în dreptul fiecărui tabel.

Dacă vezi altceva. Un false înseamnă că oricine are adresa proiectului poate citi, modifica și șterge tot tabelul; Security Advisor numește situația „Table publicly accessible”. Tabelele create din editorul vizual al Supabase au RLS activ din start; cele create prin SQL, cum lucrează un agent, trebuie activate explicit. După activare, până apar politici, aplicația pare goală.

Politici care par corecte, dar lasă totul deschis

RLS activ nu spune nimic despre calitatea regulilor. Le citești înlocuind în interogarea de mai sus prima linie cu select tablename, policyname, roles, cmd, qual, with_check și catalogul cu pg_policies: cmd arată operația, roles cui i se aplică regula, qual condiția pentru rândurile existente, with_check condiția pentru cele noi sau modificate. O politică sănătoasă, în forma din documentație:

create policy "Users can view their own profile."
on profiles for select
to authenticated
using ( (select auth.uid()) = user_id );

A doua linie spune că regula privește citirea din profiles, a treia o limitează la utilizatorii conectați, a patra lasă să treacă doar rândurile în care user_id este identitatea celui care întreabă.

Patru tipare care trec de o privire grăbită:

• using (true) pe date private. RLS figurează ca activ, dar condiția e mereu adevărată.
• to anon pe date care nu sunt publice. Rolul anon înseamnă vizitator neconectat.
• UPDATE fără with_check. A doua condiție împiedică un utilizator să-și treacă un rând pe numele altcuiva.
• Rolul sau planul în același rând cu profilul. RLS lucrează pe rânduri întregi: cine își poate modifica profilul își poate modifica și is_admin sau plan, dacă stau acolo. La fel, user_metadata poate fi schimbat chiar de utilizator.

Testul cu al doilea cont

Citirea politicilor îți spune ce ai vrut să obții. Testul îți spune ce ai obținut.

1. Creează două conturi: A în browserul obișnuit, B într-o fereastră privată.
2. Cu A, adaugă câte un element din fiecare tip și notează adresa paginii fiecăruia.
3. Cu B, verifică listele: nu trebuie să apară nimic din ce a creat A.
4. Tot cu B, lipește în bara de adrese pagina unui element al lui A. Trebuie să primești „nu există” sau „fără acces”.
5. Deschide instrumentele de dezvoltare (DevTools, F12), fila Network, reîncarcă pagina și citește răspunsurile cererilor către baza de date (în Supabase, cele cu /rest/v1/ în adresă). Trebuie să conțină doar rândurile lui B: interfața poate ascunde date pe care serverul le-a trimis.
6. Încearcă o modificare și o ștergere pe elementul lui A, apoi verifică din contul A că a rămas neschimbat. O modificare oprită de politică nu produce eroare, pur și simplu nu atinge niciun rând.

Pentru pasul 6, panoul Supabase are o funcție de impersonare (beta public la data consultării), cu care lucrezi în Table Editor „ca” utilizatorul B; altfel, în panou ești administrator și vezi tot.

Dacă vezi altceva. Un rând al lui A la B: politică lipsă sau prea largă pe citire. Date în Network care nu apar pe ecran: filtrare făcută doar în interfață. O modificare reușită: politică de UPDATE lipsă sau greșită. În niciunul dintre cazuri nu lansezi.

Vizitatorul anonim

Un tabel Supabase se poate interoga, potrivit documentației, direct din bara de adrese:

https://<PROJECT_REF>.supabase.co/rest/v1/<tabel>?apikey=<CHEIA_PUBLICABILĂ>

Adresa proiectului și cheia le găsești în fila Network. Deschide linkul într-o fereastră privată, pentru fiecare tabel cu date de utilizator. Ce ar trebui să vezi: [], adică o listă goală, sau un mesaj de permisiune refuzată. Dacă vezi rânduri, tabelul e public; e în regulă doar pentru date gândite așa, cum ar fi un catalog de produse.

2. Chei API: ce are voie să stea în browser

Întrebarea nu este „se vede vreo cheie?”, ci „care cheie se vede?”.

• Au voie în browser: cheia publicabilă Supabase (sb_publishable_…) și cheia publicabilă Stripe (pk_test_…, pk_live_…).
• Doar pe server: cheia secretă Supabase (sb_secret_…), cheile Stripe secrete și restricționate (sk_…, rk_…), secretul de semnare a webhook-ului (whsec_…) și cheile oricărui alt serviciu (email, modele AI).
• Sistemul vechi Supabase: anon (publică) și service_role (secretă) sunt amândouă șiruri lungi care încep cu eyJ, deci nu le deosebești după formă.

Potrivit documentației Supabase despre cheile API, cheile anon și service_role sunt retrase până la sfârșitul lui 2026; un tutorial sau un asistent care îți cere o cheie începând cu eyJ a fost scris pentru sistemul vechi. Cheia secretă ocolește toate politicile RLS.

Variabilele al căror nume începe cu VITE_ (în proiectele Lovable) sau cu NEXT_PUBLIC_ (în proiectele v0) ajung în codul trimis în browser. Un secret pus sub un asemenea nume devine public.

Cum cauți chei secrete în codul trimis în browser

Ce faci. Deschide aplicația publicată, treci prin paginile principale, apoi deschide în DevTools panoul Search (Command+Option+F pe Mac, Control+Shift+F pe Windows și Linux), care caută în toate resursele încărcate. Caută: sb_secret_, sk_live_, sk_test_, rk_live_, whsec_. Pentru cheile vechi, caută eyJ și compară fiecare valoare cu cea afișată la service_role în Settings > API Keys.

Ce ar trebui să vezi. Niciun rezultat pentru prefixele secrete. Dacă găsești unul, tratezi cheia ca fiind deja compromisă și treci la rotire.

Cum cauți în istoricul repo-ului

Un fișier șters rămâne în istoricul Git. Dacă repo-ul e public pe GitHub, scanarea de secrete rulează automat, fără cost, pe tot istoricul și pe toate ramurile, iar alertele apar în fila „Security and quality”. Dacă ai repo-ul pe calculator, comanda git log --all --oneline -S "sk_live_" listează, din toate ramurile, doar modificările care au adăugat sau au scos șirul căutat.

O nuanță pentru proiectele Lovable: documentația cere ca fișierul .env să rămână în repo, pentru că acolo stau doar valorile publice cu prefix VITE_, iar secretele se păstrează separat, în Secrets.

Ai găsit una: rotești, nu doar ștergi

Ștergerea din cod nu anulează nimic: cheia rămâne în istoric, în copii și în fork-uri. Documentația GitHub spune că primul pas este revocarea sau rotirea secretului. La Supabase creezi o cheie secretă nouă, o înlocuiești peste tot, confirmi că aplicația merge, apoi o ștergi pe cea compromisă. La Stripe alegi Rotate key din pagina API keys; cu expirarea pe „Now”, cheia veche este ștearsă imediat. Apoi cauți în jurnalele serviciului activitate pe care nu o recunoști.

3. Autentificare: patru lucruri de încercat

Confirmarea emailului. Creează un cont cu o adresă la care nu ai acces și încearcă să te conectezi fără confirmare. Ar trebui să fii oprit; pe proiectele Supabase găzduite, confirmarea este activă implicit. Dacă intri direct, oricine își poate face cont cu adresa altcuiva. Atenție: serviciul de email inclus în Supabase este limitat la două mesaje pe oră, deci ai nevoie de un SMTP propriu.

Resetarea parolei. Cere o resetare pentru contul tău: emailul sosește, linkul duce pe domeniul tău (nu pe localhost), parola nouă funcționează, cea veche nu. Cere apoi una pentru o adresă inexistentă: mesajul afișat trebuie să fie același, altfel aplicația confirmă oricui ce adrese au cont.

Adresele de redirecționare. În configurarea de URL a autentificării, Site URL trebuie să fie domeniul de producție; valoarea de pornire este http://localhost:3000. Lista Redirect URLs conține adresele exacte ale aplicației; documentația recomandă ca tiparele cu ** să rămână pentru dezvoltare și preview.

Paginile „protejate” doar în interfață. Deconectat, lipește în browser adresa unei pagini din contul tău; apoi, ca utilizator obișnuit, adresa paginii de administrare. E normal să fii trimis la login; important e ca în fila Network să nu fi sosit date. OWASP descrie tiparul în categoria Broken Access Control: ocolirea verificărilor prin modificarea adresei. Dacă datele vin, pagina e ascunsă, nu protejată.

4. Plăți: prețul și accesul nu vin din browser

Prețul. Întreabă agentul: „Arată-mi codul care creează sesiunea de plată. De unde vine suma?” Răspunsul bun: de pe server, dintr-o listă fixă de prețuri definite în Stripe; documentația Stripe cere ca prețul să fie ținut pe server, tocmai ca să nu poată fi modificat din client. Răspunsul prost: suma sau planul sosesc din pagină și sunt folosite ca atare.

Dreptul de acces. Află în ce tabel e notat că un utilizator a plătit și caută-l în lista de politici de la secțiunea 1. Nu trebuie să existe pe el nicio politică de INSERT sau UPDATE pentru utilizatori; acolo scrie doar serverul. În relatarea despre CVE-2025-48757, cercetătorul descrie cum a inserat direct un rând cu starea plății „paid”, ocolind integrarea Stripe.

Pagina de succes. Cu un cont care nu a plătit, deschide direct adresa paginii de confirmare. Dacă primești acces, aplicația se bazează pe redirecționare. Stripe spune explicit că onorarea comenzii nu se poate sprijini doar pe pagina de după plată; calea de încredere este webhook-ul, trimis direct serverului tău.

Semnătura webhook-ului. Fără verificare, scrie documentația Stripe despre webhook-uri, un atacator poate trimite evenimente false ca să obțină livrarea unei comenzi sau acces la un cont. Testul:

curl -X POST https://aplicatia-ta.ro/adresa-webhook \
  -H "Content-Type: application/json" \
  -d '{"type":"checkout.session.completed"}'

Comanda trimite un „eveniment” inventat, fără antetul Stripe-Signature. Ce ar trebui să vezi: un răspuns de eroare (în exemplele Stripe, codul 400) și niciun cont modificat. Dacă primești 200 și cineva capătă acces, oricine își poate acorda singur abonamentul. Bolt precizează că integrarea lui cu Stripe verifică semnătura automat; testul rămâne util.

Test și real. Cheile de test conțin _test_, cele reale _live_. La trecerea pe real, secretul whsec_ trebuie să fie cel al modului live, fiindcă diferă între moduri. Nu „încerci” plata reală cu propriul card: Stripe interzice testarea în modul live cu date reale de plată.

5. Fișiere încărcate și date personale reale

Bucket public sau privat

Într-un „bucket” privat, fiecare descărcare trece prin politici; într-unul public, potrivit documentației Supabase, oricine are adresa fișierului îl poate deschide. Bucket-urile Supabase sunt private implicit, iar Lovable blochează din start crearea celor publice.

Ce faci. Încarcă un document cu contul A, copiază adresa fișierului și deschide-o într-o fereastră privată. Ce ar trebui să vezi: un refuz sau o adresă semnată, valabilă un timp limitat. Dacă se deschide, bucket-ul e public: acceptabil pentru poze de profil și imagini de produs, inacceptabil pentru facturi, contracte sau acte de identitate.

Ce se schimbă când datele sunt ale unor oameni reali

De la primul utilizator real, firma ta este operator în sensul Regulamentului (UE) 2016/679: cea care stabilește scopurile și mijloacele prelucrării. Platforma cu care ai construit nu preia acest rol. Patru articole te privesc direct:

• Art. 32, securitatea prelucrării. Cere măsuri tehnice și organizatorice adecvate riscului, între care un proces de testare periodică a eficacității lor. Verificările de aici, repetate după fiecare schimbare importantă și notate cu dată, sunt un asemenea proces.
• Art. 33, notificarea autorității. O încălcare a securității datelor se notifică autorității de supraveghere fără întârzieri nejustificate și, dacă este posibil, în cel mult 72 de ore de la data la care ai luat cunoștință de ea, cu excepția cazului în care este puțin probabil să genereze un risc pentru persoane. În România, aceasta este ANSPDCP, care are o pagină dedicată notificării, cu formularul aprobat prin Decizia nr. 128/2018.
• Art. 34, informarea persoanelor. Dacă încălcarea e susceptibilă să genereze un risc ridicat, îi anunți și pe cei afectați.
• Art. 28, contractul cu furnizorii. Cine prelucrează date în numele tău (baza de date, găzduirea, emailul) o face în baza unui contract cu conținutul cerut de alin. (3). Furnizorii mari publică un acord de prelucrare a datelor; verifică pentru fiecare că l-ai acceptat.

Un tabel lăsat deschis, din care cineva a citit date, intră în definiția încălcării: acces neautorizat.

Paginile legale ale site-ului (politica de confidențialitate, cookie-urile, datele de identificare) sunt descrise în ghidul pentru site-ul de prezentare. Acordul de prelucrare și registrul prelucrărilor sunt tratate în modulul de conformitate din cursul AI pentru Antreprenori și Startup-uri. Dacă regenerezi des aplicația, lucrează pe date de test sintetice, nu pe copia bazei reale.

6. Scanările incluse în platforme: ce fac și ce nu fac

Toate apar în documentația oficială la 5 octombrie 2026; denumirile și planurile se schimbă des.

Rulează-le pe cele disponibile, apoi ține minte ce nu poate ști niciuna: regulile afacerii tale. Un scaner vede că o politică există și că nu e true; nu știe cine ar trebui să vadă ofertele tale. Cercetătorul care a raportat CVE-2025-48757 nota tocmai asta despre scanerul de atunci: verifica existența unei politici, nu corectitudinea ei. De aceea testul cu al doilea cont rămâne obligatoriu, chiar cu toate bifele verzi.

7. Când chemi un programator

Criteriile țin de risc, nu de buget. Dacă unul se aplică, revizuirea făcută de un om care citește cod devine parte din lansare:

1. Testul cu al doilea cont a picat și, după reparația făcută de agent, nu poți explica de ce trece acum.
2. Aplicația are mai multe roluri sau organizații: echipe, administratori, clienți ai clienților tăi.
3. Păstrezi date a căror expunere face rău direct: date despre sănătate, acte de identitate, date ale minorilor, documente încărcate de clienți.
4. Banii au logică în aplicație: credite, sold, comisioane, schimbări de plan, plăți între utilizatori.
5. Ai cod de server care folosește cheia secretă. Acel cod ocolește RLS, deci fiecare funcție trebuie să verifice singură cine o apelează.
6. Ai găsit o cheie secretă expusă. Rotirea o faci tu; cineva trebuie să stabilească din jurnale ce s-a întâmplat între timp.

Lista de control înainte de lansare

1. Fiecare tabel are RLS activ; nicio politică nu are using (true) pe date private.
2. Rolul, planul și starea plății stau în tabele în care utilizatorul nu poate scrie.
3. Testul cu al doilea cont a trecut pe citire, modificare și ștergere.
4. Vizitatorul anonim primește listă goală sau refuz pe tabelele private.
5. Browserul și istoricul repo-ului nu conțin prefixe secrete; cheile găsite au fost rotite.
6. Confirmarea emailului e activă; emailurile pleacă printr-un SMTP propriu.
7. Site URL și Redirect URLs conțin doar domeniul de producție.
8. Paginile de cont și de administrare nu primesc date fără autentificare.
9. Prețul vine de pe server; accesul se acordă doar din webhook-ul semnat, cu chei live.
10. Documentele încărcate stau într-un bucket privat.
11. Am acceptat acordurile de prelucrare și știu cum notific o încălcare.
12. Am rulat scanările platformei și am tratat fiecare constatare.

Întrebări frecvente

Cum verific dacă RLS este activ pe toate tabelele? Rulezi în SQL Editor select tablename, rowsecurity from pg_tables where schemaname = 'public'; și cauți true în dreptul fiecărui tabel. RLS activ nu este suficient: o politică using (true) lasă tabelul la fel de deschis, deci faci și testul cu al doilea cont.

Este o problemă că o cheie API se vede în browser? Nu, dacă este o cheie publicabilă (sb_publishable_…, vechea anon, pk_…): sunt făcute să fie publice. O cheie secretă expusă (sb_secret_…, vechea service_role, sk_…) o consideri compromisă și o rotești, nu doar o ștergi din cod, fiindcă rămâne în istoricul Git.

Este suficientă scanarea de securitate din Lovable, Bolt sau Replit? Nu, și platformele o spun singure: Lovable scrie că scanările nu înlocuiesc o revizuire amănunțită, iar Replit că nicio scanare nu garantează că aplicația e sigură. Ele prind tipare cunoscute, nu regulile afacerii tale.

Ce obligații am dacă datele utilizatorilor au fost expuse? Ca operator, notifici ANSPDCP fără întârzieri nejustificate și, dacă este posibil, în cel mult 72 de ore de la data la care ai aflat, cu excepția cazului în care un risc pentru persoane este puțin probabil (art. 33 din Regulamentul (UE) 2016/679). La risc ridicat, îi informezi și pe cei afectați (art. 34).

Concluzie

O aplicație construită din prompturi se verifică din afară, nu din preview. Întrebarea de control este mereu aceeași: ce primește cineva care ocolește interfața și vorbește direct cu serverul? RLS și politicile citite rând cu rând răspund pentru date, căutarea prefixelor secrete pentru chei, webhook-ul semnat pentru bani, bucket-ul privat pentru documente.

Testul cu al doilea cont nu se poate delega unui scaner. Unde apar roluri multiple, bani cu logică proprie sau date a căror expunere face rău direct, lista nu mai ajunge și e nevoie de un om care citește cod.

Surse

• NVD, CVE-2025-48757: https://nvd.nist.gov/vuln/detail/CVE-2025-48757
• Matt Palmer, relatarea cercetătorului: https://mattpalmer.io/posts/statement-on-CVE-2025-48757/
• Wiz Research, Moltbook: https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
• Supabase, RLS: https://supabase.com/docs/guides/database/postgres/row-level-security
• Supabase, chei API: https://supabase.com/docs/guides/api/api-keys
• Supabase, Advisors: https://supabase.com/docs/guides/database/database-advisors
• Supabase, REST: https://supabase.com/docs/guides/api/quickstart
• Supabase, Redirect URLs: https://supabase.com/docs/guides/auth/redirect-urls
• Supabase, parole: https://supabase.com/docs/guides/auth/passwords
• Supabase, bucket-uri: https://supabase.com/docs/guides/storage/buckets/fundamentals
• Supabase, impersonare: https://supabase.com/features/user-impersonation
• PostgreSQL, pg_policies: https://www.postgresql.org/docs/current/view-pg-policies.html
• Stripe, webhook-uri: https://docs.stripe.com/webhooks
• Stripe, chei API: https://docs.stripe.com/keys
• Stripe, onorarea comenzilor: https://docs.stripe.com/checkout/fulfillment
• Stripe, prețuri pe server: https://docs.stripe.com/billing/quickstart
• Stripe, testare: https://docs.stripe.com/testing
• Lovable, securitate: https://docs.lovable.dev/features/security
• Lovable, Secrets: https://docs.lovable.dev/features/secrets
• Lovable, Storage: https://docs.lovable.dev/features/storage
• Lovable, Cloud: https://docs.lovable.dev/features/cloud
• Bolt, securitate: https://support.bolt.new/building/security
• Bolt, Stripe: https://support.bolt.new/integrations/stripe
• Replit, niveluri de scanare: https://docs.replit.com/features/security/security-scan-levels
• v0, securitate: https://v0.app/docs/security
• GitHub, scanarea de secrete: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
• GitHub, date sensibile în repo: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
• OWASP Top 10:2025, A01: https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
• Regulamentul (UE) 2016/679: https://eur-lex.europa.eu/legal-content/RO/TXT/?uri=CELEX:32016R0679
• ANSPDCP, notificarea încălcărilor: https://www.dataprotection.ro/?page=pagina_formular_679

Articol informativ. Sursele au fost consultate la 5 octombrie 2026; denumirile funcțiilor și planurile platformelor se schimbă, deci verifică documentația furnizorului la data la care lucrezi. Nu înlocuiește un audit de securitate și nu constituie consultanță juridică.