Vibe coding: co to jest i jak zabezpieczyć taką aplikację

Vibe coding: co to jest (po polsku)?

Vibe coding to sposób tworzenia aplikacji, w którym opisujesz AI zwykłym językiem, czego chcesz, akceptujesz zmiany bez czytania kodu i naprawiasz błędy kolejnymi poleceniami. Termin wymyślił Andrej Karpathy w lutym 2025. Po polsku najbliżej mu do „programowania na wyczucie”.

Simon Willison proponuje prostą granicę: vibe coding to budowanie oprogramowania z modelem bez przeglądania kodu, który ten model napisał. Jeśli czytasz, testujesz i rozumiesz kod, to jest programowanie ze wsparciem AI, nie vibe coding. Willison uważa vibe coding za w porządku przy projektach o niskiej stawce i ostrzega przed nim tam, gdzie są sekrety, cudze dane i rachunki za API.

Problem zaczyna się, gdy prototyp robiony na wyczucie dostaje prawdziwych użytkowników i ich dane. Aplikacja wygląda na działającą, bo interfejs pokazuje każdemu tylko jego rzeczy. To, co widać z pominięciem interfejsu, to inna sprawa.

Błąd 1: klucze API w przeglądarce

Wszystko, co trafia do kodu ładowanego przez przeglądarkę, może przeczytać każdy odwiedzający. Dokumentacja Gemini API mówi wprost: nie wpisuj kluczy na sztywno w aplikacje webowe i mobilne, bo da się je z nich wyciągnąć, i wywołuj API przez własny serwer. Wyciek klucza AI to zwykle rachunek za cudze zapytania.

W Supabase są dwa rodzaje kluczy. Klucz publikowalny może być w przeglądarce, bo sięga tylko tam, gdzie pozwalają reguły RLS. Klucz sekretny (dawniej service_role) według dokumentacji Supabase omija wszystkie reguły i nigdy nie może trafić do przeglądarki ani do klientów.

Typowa droga wycieku w projektach na Vite: zmienna z przedrostkiem VITE_ trafia do paczki dla przeglądarki w czasie budowania. Klucz sekretny nazwany w ten sposób jest publiczny. Jeśli nie wiesz, co to za klucz albo token, rozpoznasz go w przeglądarce, bez wysyłania go nigdzie.

Błąd 2: tabele w Supabase bez RLS

RLS (Row Level Security) to reguły w bazie, które decydują, które wiersze widzi i zmienia dany użytkownik. Dokumentacja Supabase ostrzega, że tabela w udostępnionym schemacie bez RLS jest do odczytu i zapisu dla każdej roli, która ma do niej uprawnienia. Zalecenie: włącz RLS na każdej takiej tabeli i testuj reguły, zamiast zakładać, że działają.

Jak to wygląda w praktyce, pokazuje CVE-2025-48757. Według oświadczenia autorów zgłoszenia z 29 maja 2025 przeanalizowali oni 1645 projektów zbudowanych w Lovable i w 170 z nich (około 10%) znaleźli niewystarczające reguły RLS, przez które dało się czytać dane użytkowników, w tym adresy e-mail i klucze API. Lovable kwestionuje to zgłoszenie, wskazując, że za ochronę danych aplikacji odpowiada jej twórca, a w bazie NVD wpis jest oznaczony jako sporny (disputed) i ma status „Deferred”, czyli NVD odłożyło jego analizę. Niezależnie od tego, kto ma rację w sporze, mechanizm jest ten sam: brak reguły to otwarta tabela.

Dwie pułapki, o których łatwo zapomnieć. Reguła na odczyt nie mówi nic o zapisie: SELECT, INSERT, UPDATE i DELETE sprawdzasz osobno. Widoki w Postgresie domyślnie omijają RLS, bo działają z uprawnieniami twórcy, więc widok nad chronioną tabelą potrafi oddać wszystkie wiersze.

Błąd 3: publiczne magazyny plików

Pliki w Supabase leżą w bucketach. Bucket publiczny znaczy, że każdy, kto zna adres pliku, pobierze go bez logowania. Reguły dostępu nadal pilnują wgrywania, usuwania i przenoszenia, ale nie odczytu.

Do zdjęć produktów to w porządku. Do faktur, umów, skanów dowodów i CV nie. Jeśli w dodatku nazwy plików są przewidywalne, na przykład kolejne numery, zgadywanie adresów przestaje być zgadywaniem. Ten i cztery inne powtarzalne błędy opisujemy w artykule pięć rzeczy, które wychodzą w aplikacjach zbudowanych szybko.

Jak Lovable zapewnia bezpieczeństwo klucza API (także Google Gemini)

Według dokumentacji Lovable AI wbudowane funkcje AI nie wymagają Twojego klucza Gemini. Lovable sam tworzy dla projektu klucz LOVABLE_API_KEY, a wywołania modeli idą przez funkcję serwerową, więc klucz i treść zapytań zostają po stronie serwera. Wyjątkiem są rozmowy głosowe na żywo, w których przeglądarka przesyła dźwięk bezpośrednio do modelu, a połączenie zaczyna i klucz trzyma serwer aplikacji.

Jeśli używasz własnego klucza, na przykład z Google AI Studio, Lovable zaleca zapisanie go w Secrets i wywoływanie API z funkcji brzegowej. Secrets są według dokumentacji szyfrowane, wstrzykiwane do funkcji serwerowych i nie trafiają do przeglądarki. Zmienne z przedrostkiem VITE_ to coś innego: są publiczne z założenia i Lovable nie pozwala zapisać ich w Secrets.

Lovable sam wykrywa klucze wklejone do czatu i podpowiada przeniesienie ich do Secrets. Przed publikacją automatycznie uruchamia szybki skan reguł dostępu do bazy, zależności i serwerów MCP, a na żądanie głębszy przegląd kodu. To, czy da się opublikować aplikację z otwartymi znaleziskami, zależy od ustawień przestrzeni roboczej. Dokumentacja zastrzega, że te narzędzia nie gwarantują pełnego bezpieczeństwa.

Co narzędzia robią same, a czego nie

Robią coraz więcej: trzymają klucze po stronie serwera, przypominają o RLS, skanują znane podatności w zależnościach. To realna pomoc.

Nie wiedzą natomiast, co w Twojej aplikacji jest czyje. Skaner sprawdzi, że reguła istnieje. Nie sprawdzi, czy kierowniczka zespołu powinna widzieć wypłaty innych zespołów, czy klient może zmienić status zamówienia na opłacone, ani czy stary endpoint testowy powinien jeszcze działać. Tę logikę zna tylko osoba, która wie, jak ma działać firma.

Dlatego zielony wynik skanu znaczy „nie znaleziono znanych problemów”, a nie „bezpieczne”. To samo dotyczy każdego sprawdzenia, także naszego.

Checklista przed publikacją aplikacji z vibe codingu

1. Przeszukaj kod ładowany przez przeglądarkę (narzędzia deweloperskie, zakładka ze źródłami) pod kątem kluczy. W przeglądarce może być tylko klucz publikowalny. 2. Wypisz wszystkie tabele i przy każdej sprawdź, czy ma włączone RLS i osobne reguły na cztery operacje. 3. Zaloguj się jako użytkownik A i spróbuj odczytać i zmienić dane użytkownika B, bezpośrednio przez API, z pominięciem interfejsu. 4. Sprawdź, które buckety są publiczne i co w nich leży. 5. Sprawdź widoki i funkcje w udostępnionym schemacie. 6. Wypisz trasy, które działają bez logowania, i uzasadnij każdą. 7. Uruchom skan narzędzia i przeczytaj każde znalezisko, nie tylko krytyczne. 8. Ustaw limity wydatków na kluczach AI.

Pamiętaj, że sprawdzenie publicznej strony z zewnątrz (szyfrowanie, nagłówki, komu strona przekazuje dane) nie testuje reguł w bazie. To dwie różne rzeczy. Jeśli budujesz aplikacje dla klientów i chcesz to robić systematycznie, zajrzyj na stronę dla builderów. Jak przygotować aplikację do oceny przez kupującego, opisujemy też w tekście jak sprawdzić, czy aplikacja jest bezpieczna.