Poradniki

Zbudowałeś stronę z AI? Pięć rzeczy, które prawie na pewno są nie tak

8 października, 2026 Możliwość komentowania Zbudowałeś stronę z AI? Pięć rzeczy, które prawie na pewno są nie tak została wyłączona
Laptop z kodem aplikacji na ekranie

Wpisujesz kilka zdań, czekasz pół godziny i masz działający sklep, system rezerwacji albo panel klienta. Narzędzia takie jak Lovable, Bolt, v0 czy Cursor zmieniły to, kto może zbudować aplikację. Nazywa się to vibe coding: opisujesz, czego chcesz, a kod pisze model AI.

To naprawdę działa. Problem w tym, że „działa” i „jest bezpieczne” to dwie różne rzeczy, a AI optymalizuje tylko pierwszą.

Dlaczego AI pisze kod, który działa, ale nie jest bezpieczny

Model robi to, o co prosisz. Prosisz o formularz logowania, dostajesz formularz logowania. Nie prosiłeś o ochronę przed wyciekiem danych, więc jej nie ma. A jeśli nie jesteś programistą, nie wiesz nawet, o co trzeba poprosić.

Firma Veracode od dwóch lat testuje to na liczbach. Daje ponad stu modelom AI te same zadania programistyczne i sprawdza, czy wynik jest bezpieczny:

  • W 2025 roku 45% odpowiedzi zawierało lukę z listy OWASP Top 10, czyli z kanonu najczęstszych błędów bezpieczeństwa w aplikacjach internetowych.
  • W raporcie z lipca 2026 wynik to 44%. Modele przez rok wyraźnie zmądrzały w pisaniu kodu, a w bezpieczeństwie stoją w miejscu. Veracode podsumowuje to zdaniem: składnia jest rozwiązana, bezpieczeństwo nie.
  • Najgorzej wypada ochrona przed atakiem XSS, czyli wstrzyknięciem obcego skryptu na stronę. Modele zabezpieczają się przed nim poprawnie tylko w 15% przypadków.

To testy w laboratorium. A jak wygląda to w prawdziwych, działających aplikacjach?

Co znaleziono w 5600 aplikacjach zbudowanych z AI

W październiku 2025 firma Escape przeskanowała 5600 publicznie dostępnych aplikacji zbudowanych na platformach do vibe codingu, z czego ponad 4000 powstało w Lovable. Wynik:

  • ponad 2000 luk bezpieczeństwa,
  • ponad 400 wyciekających sekretów, czyli kluczy i tokenów dostępu,
  • 175 przypadków ujawnienia danych osobowych, w tym dokumentacji medycznej, numerów kont bankowych, telefonów i adresów e-mail.

Badacze zaznaczają, że skanowali wyłącznie pasywnie, bez prób włamania, więc to dolna granica. Większość problemów była dostępna bez żadnego logowania.

Kilka miesięcy wcześniej inżynier Matt Palmer sprawdził aplikacje z Lovable pod jednym konkretnym kątem. Znalazł 303 niezabezpieczone punkty dostępu w 170 projektach. Wyciekały z nich adresy e-mail, telefony, statusy płatności, adresy domowe, kwoty zadłużenia i klucze do płatnych usług. Błąd dostał oficjalny numer w międzynarodowym rejestrze luk: CVE-2025-48757.

Wszystkie te aplikacje łączy jedno: działały poprawnie i ich właściciele byli z nich zadowoleni.

Pięć rzeczy, które prawie na pewno są nie tak

1. Klucze i hasła widać w kodzie strony

To najczęstsza i najdroższa wpadka. Aplikacja łączy się z płatnościami, mapami albo modelem AI i potrzebuje do tego klucza API. AI wkleja go tam, gdzie jest najprościej, czyli do kodu, który trafia do przeglądarki odwiedzającego. Każdy może go przeczytać.

Skutek: ktoś używa Twojego klucza do OpenAI i dostajesz rachunek na kilka tysięcy dolarów. Albo przejmuje klucz do Stripe i widzi dane Twoich klientów.

Jak sprawdzić: otwórz stronę, naciśnij F12, przejdź do zakładki Sources i wyszukaj (Ctrl+Shift+F) frazy sk-, api_key, secret, token. Jeśli coś znajdziesz, natychmiast unieważnij ten klucz u dostawcy i wygeneruj nowy. Usunięcie go z kodu nie wystarczy, bo już mógł zostać skopiowany.

2. Baza danych jest otwarta dla każdego

To dokładnie błąd z CVE-2025-48757. Większość platform do vibe codingu podłącza bazę Supabase albo Firebase. Aplikacja rozmawia z bazą prosto z przeglądarki, publicznym kluczem. To jest w porządku pod jednym warunkiem: baza ma włączone reguły, które mówią, kto może czytać które wiersze. W Supabase nazywa się to Row Level Security, w skrócie RLS.

Domyślnie te reguły są wyłączone. AI tworzy tabele i ich nie włącza, bo aplikacja działa bez nich.

Skutek: każdy, kto zna adres bazy (a jest w kodzie strony), może pobrać całą tabelę użytkowników jednym zapytaniem.

Jak sprawdzić: zaloguj się do panelu Supabase, otwórz Table Editor i zobacz, czy przy każdej tabeli jest oznaczenie „RLS enabled”. Samo włączenie nie wystarczy, potrzebne są jeszcze reguły, na przykład „użytkownik widzi tylko swoje wiersze”. Narzędzie Lovable sprawdza, czy reguła istnieje, ale nie sprawdza, czy naprawdę chroni.

3. Zabezpieczenia są tylko po stronie przeglądarki

AI chętnie ukrywa przycisk „Panel administratora” przed zwykłym użytkownikiem i uznaje sprawę za załatwioną. Tymczasem sam adres panelu i jego zapytania do serwera nadal działają dla każdego, kto je zna.

To samo dotyczy cen, rabatów i limitów. Jeśli cenę oblicza przeglądarka, a serwer ją tylko przyjmuje, klient może kupić za złotówkę.

Zasada: wszystko, co dzieje się w przeglądarce, użytkownik może zmienić. Uprawnienia, ceny i limity musi sprawdzać serwer albo reguły bazy.

Jak sprawdzić: zaloguj się jako zwykły użytkownik i wpisz ręcznie adres panelu administratora albo cudzego zamówienia, zmieniając numer w adresie. Jeśli coś zobaczysz, masz problem.

4. Google i asystenci AI widzą pustą stronę

Aplikacje z tych narzędzi to zwykle tak zwane SPA, czyli strony, które buduje JavaScript dopiero w przeglądarce. W surowym kodzie, który dostaje robot, jest jeden pusty element i lista skryptów.

Google radzi sobie z tym średnio i z opóźnieniem. Boty, którymi ChatGPT, Claude czy Perplexity czytają strony na żywo, zwykle skryptów nie uruchamiają wcale. Dla nich Twojej oferty nie ma.

Jak sprawdzić: kliknij na stronie prawym przyciskiem, wybierz „Wyświetl źródło strony” i poszukaj tam fragmentu swojego tekstu. Jeśli go nie ma, roboty też go nie widzą. Rozwiązaniem jest renderowanie po stronie serwera albo wygenerowanie statycznych wersji podstron.

5. Brakuje wszystkiego, o co nie poprosiłeś

AI nie dodaje rzeczy nudnych, ale wymaganych:

  • polityki prywatności i banera zgód na cookies, choć dodało Google Analytics,
  • tytułów i opisów podstron, mapy strony, pliku robots.txt,
  • ograniczenia liczby prób logowania i wysyłek formularza, więc boty mogą zgadywać hasła i zalewać Cię spamem,
  • kopii zapasowej bazy,
  • wyłączenia tak zwanych source maps, czyli plików, które pozwalają każdemu odtworzyć cały kod źródłowy Twojej aplikacji.

W Unii Europejskiej pierwsze dwa punkty to nie kosmetyka, tylko obowiązek wynikający z RODO.

Czy to znaczy, że nie warto budować z AI?

Nie. To znaczy, że AI zastąpiło programistę, ale nie zastąpiło przeglądu bezpieczeństwa. W firmach programistycznych kod przed publikacją czyta druga osoba, a przed większym wdrożeniem robi się audyt. Przy vibe codingu ten etap po prostu znika, bo nikt nie wie, że powinien istnieć.

Dobra wiadomość: większość opisanych problemów naprawia się w kilka godzin. Trzeba tylko wiedzieć, że są.

Możesz też zacząć od samego AI. Wklej mu ten artykuł i poproś: „sprawdź mój projekt pod kątem tych pięciu punktów i pokaż, co trzeba poprawić”. Modele zabezpieczają kod dużo lepiej, gdy się je o to wprost poprosi. Tyle że wynik nadal warto zweryfikować, z powodów opisanych wyżej.

Co zrobić teraz

1. Poświęć 15 minut na pięć testów z tego artykułu. Zacznij od kluczy w kodzie i reguł bazy danych. To dwa błędy, które kosztują najwięcej.

2. Sprawdź, co Twoja strona pokazuje światu. Darmowy skaner na eyesite.pl/skaner w kilkanaście sekund pokaże, czy maile ze strony dochodzą, czy Google i asystenci AI mogą ją przeczytać, czy certyfikat i domena są w porządku. Działa dla każdej strony, nie tylko na WordPressie.

3. Jeśli aplikacja obsługuje dane klientów albo płatności, zamów przegląd. Zaznacz w skanerze „Chcę darmowy audyt”. Przejdziemy razem przez te pięć punktów na Twoim projekcie i powiemy wprost, co jest pilne, a co może poczekać. Odpowiadamy w jeden dzień roboczy.

Aplikację zbudowałeś w weekend. Nie pozwól, żeby ktoś równie szybko ją rozebrał.

Źródła

Zdjęcie: Mohammad Rahmani / Unsplash