Czy aplikacja zrobiona z AI jest bezpieczna? Lista kontrolna i RODO w pigułce

AI napisało Ci działającą aplikację, ale nie masz pewności, czy ktoś obcy nie zobaczy w niej cudzych danych. Aplikacja zrobiona z AI może być bezpieczna, ale nie jest taka automatycznie. AI generuje kod, który działa, a to nie to samo, co kod, który jest zabezpieczony. Domyślnie nikt nie pilnuje za Ciebie, czy użytkownik A nie zobaczy danych użytkownika B, czy klucze do usług nie leżą w kodzie i czy formularz nie zostanie zalany przez boty. Te rzeczy musisz sprawdzić sam, a poniżej masz listę, jak to zrobić.

Zastrzeżenie: to tekst informacyjny, nie porada prawna ani audyt bezpieczeństwa. Przy aplikacjach z danymi zdrowotnymi, finansowymi albo dużą liczbą użytkowników potrzebujesz specjalisty.

Co naprawdę może pójść źle

W prostej aplikacji z logowaniem i bazą danych ryzyka sprowadzają się zwykle do kilku rzeczy:

• ktoś niepowołany czyta albo zmienia cudze dane,
• klucz lub hasło wyciekają razem z kodem,
• ktoś zalewa formularz fałszywymi zgłoszeniami,
• dane znikają, bo nie było kopii,
• gromadzisz dane osobowe bez informowania ludzi, po co i na jak długo.

Pierwsza pozycja jest najpoważniejsza. Projekt OWASP, który prowadzi znaną listę najczęstszych zagrożeń aplikacji webowych, opisuje kontrolę dostępu tak: ma zapewnić, że użytkownicy nie mogą działać poza przyznanymi im uprawnieniami. Zaleca przy tym zasadę, by poza zasobami publicznymi domyślnie odmawiać dostępu (OWASP Top 10, A01:2021 Broken Access Control). Brzmi technicznie, ale po ludzku znaczy: nic nie jest widoczne, dopóki nie zdecydujesz, kto może to zobaczyć.

Lista kontrolna

1. Klucze i hasła poza kodem

Kod aplikacji webowej da się podejrzeć w przeglądarce, więc klucz wpisany w kod widzi każdy, kto wie, gdzie patrzeć. Klucze do usług (wysyłka maili, płatności, AI) trzymaj w ustawieniach projektu przeznaczonych na sekrety, zwykle nazywanych "environment variables" lub "secrets".

Rozróżnij dwa rodzaje kluczy. Część usług ma klucz używany w przeglądarce (w Supabase to rola anon), przy którym ochronę danych zapewniają reguły dostępu w bazie, oraz klucz tajny (service role), który te reguły omija, więc nigdy nie wolno umieszczać go w przeglądarce ani pokazywać użytkownikom. Dokumentacja Supabase mówi o tym wprost: tajnego klucza nie używa się w przeglądarce, tylko do zadań administracyjnych po stronie serwera (Supabase: Row Level Security).

Jeśli klucz kiedykolwiek znalazł się w kodzie albo na czacie z AI, który trafił do publicznego repozytorium, wygeneruj nowy w usłudze, a stary unieważnij. Przenoszenie kluczy do ustawień to typowy moment, w którym coś przestaje działać, i właśnie takie błędy rozwiązujemy w programie na żywo.

2. Szyfrowane połączenie (https)

Adres aplikacji powinien zaczynać się od https, a nie http. Większość platform do publikacji włącza to automatycznie, ale sprawdź to po podpięciu własnej domeny. Wejdź na stronę w oknie prywatnym i upewnij się, że przeglądarka nie ostrzega o niezabezpieczonym połączeniu.

3. Logowanie i uprawnienia: czy A widzi dane B

To najważniejszy punkt całej listy i jednocześnie ten, który AI najczęściej zostawia niedokończony.

Najprostszy test, który możesz wykonać sam:

1. Załóż dwa konta testowe, A i B.
2. Na koncie A dodaj jakiś wpis (rezerwację, zlecenie, dokument).
3. Zaloguj się na konto B w oknie prywatnym przeglądarki.
4. Sprawdź, czy widzisz wpis konta A. Jeśli tak, masz poważny problem.
5. Spróbuj też otworzyć adres szczegółów wpisu A będąc zalogowanym jako B.

Na spotkaniach na żywo w programie Własna Apka przechodzimy ten test na Twoim projekcie i rozwiązujemy błędy, które wychodzą.

Jeśli używasz bazy Supabase (to częsty wybór w generatorach aplikacji), mechanizm, który to chroni, nazywa się Row Level Security (RLS). Dokumentacja opisuje go jako reguły autoryzacji działające wewnątrz bazy danych, które filtrują wiersze zgodnie z zasadami. Ostrzega też, że tabela wystawiona na zewnątrz bez RLS jest czytelna i zapisywalna dla każdej roli, która ma do niej uprawnienia. W praktyce: sprawdź, czy RLS jest włączony dla każdej tabeli i czy istnieją reguły mówiące, kto co może (Supabase: Row Level Security, Supabase: Securing your API).

Jeśli używasz innej bazy, zasada jest ta sama: reguły dostępu muszą istnieć po stronie bazy lub serwera, nie tylko w wyglądzie aplikacji. Ukrycie przycisku "Usuń" przed zwykłym użytkownikiem niczego nie zabezpiecza, jeśli bezpośrednie zapytanie do bazy nadal przejdzie.

4. Walidacja danych po stronie serwera

Sprawdzanie formularza w przeglądarce (czy e-mail ma małpę, czy pole nie jest puste) poprawia wygodę, ale nie jest zabezpieczeniem, bo ktoś może wysłać dane z pominięciem Twojej strony. Prawdziwa kontrola musi odbywać się tam, gdzie dane trafiają do bazy: po stronie serwera albo w regułach bazy.

Co sprawdzać: typ i długość pól, dozwolone wartości, to, czy użytkownik ma prawo zmieniać dany wpis. Przy zapytaniach do bazy używaj gotowych mechanizmów z parametrami, a nie sklejania tekstu zapytania z danymi od użytkownika. OWASP wskazuje bezpieczne interfejsy z parametrami jako preferowaną ochronę przed atakami typu injection, a walidację po stronie serwera jako uzupełnienie, nie pełną obronę (OWASP Top 10, A03:2021 Injection). Generatory aplikacji zwykle robią to dobrze, ale poproś AI o potwierdzenie.

5. Limity i ochrona formularzy przed botami

Publiczny formularz (kontakt, zapis, rejestracja) prędzej czy później dostanie spam. Co możesz zrobić:

• dodać mechanizm weryfikacji, że formularz wypełnia człowiek. Przykładem jest Cloudflare Turnstile: nie pokazuje łamigłówek, tylko sprawdza odwiedzającego w tle, i ma darmowy plan (Cloudflare Turnstile, plany),
• ustawić limit liczby zgłoszeń z jednego adresu w danym czasie,
• dodać ukryte pole pułapkę, które człowiek zostawia puste, a prosty bot wypełnia,
• ograniczyć rozmiar i typ plików, jeśli aplikacja przyjmuje załączniki.

6. Kopie zapasowe

Zapytaj siebie: co się stanie, jeśli jutro dane znikną, bo coś źle skasowałeś albo AI zmieniło strukturę bazy? Sprawdź w dokumentacji swojej usługi, czy robi kopie i jak je odtworzyć. Przykład z Supabase: według dokumentacji automatyczne codzienne kopie obejmują plany Pro, Team i Enterprise, a projekty w planie darmowym ich nie mają i powinny same regularnie eksportować dane (Supabase: Backups). Plany i zasady zmieniają się, więc sprawdź aktualne warunki u swojego dostawcy.

Kopia, której nie próbowałeś odtworzyć, to tylko nadzieja. Przynajmniej raz sprawdź, czy da się z niej wrócić do danych.

7. Aktualizacje

Aplikacja używa bibliotek i usług, w których z czasem znajdują się błędy. Co jakiś czas poproś AI albo narzędzie do publikacji o sprawdzenie, czy używane biblioteki mają dostępne aktualizacje bezpieczeństwa. Po każdej aktualizacji przetestuj logowanie i podstawowy scenariusz. Nie aktualizuj wszystkiego naraz tuż przed pokazem dla klienta.

8. Logi bez danych osobowych

Logi i komunikaty o błędach pomagają szukać usterek, ale łatwo zapisać w nich więcej, niż trzeba: adres e-mail, treść zgłoszenia, a czasem hasło. Poproś AI o sprawdzenie, co aplikacja zapisuje w logach, i usunięcie z nich danych osobowych, haseł i kluczy. Użytkownikowi pokazuj ogólny komunikat błędu, a szczegóły zapisuj tam, gdzie widzisz je tylko Ty.

RODO: minimum, gdy zbierasz dane osobowe

Jeśli aplikacja zbiera dane, choćby imię i e-mail, do ich przetwarzania stosuje się RODO, czyli rozporządzenie (UE) 2016/679. Poniżej najważniejsze obowiązki w ujęciu ogólnym. To nie jest porada prawna: jeśli aplikacja ma przetwarzać dane wrażliwe albo zajmować się sprawami klientów firmy, skonsultuj się z prawnikiem lub inspektorem ochrony danych. Pełny tekst rozporządzenia znajdziesz na EUR-Lex.

Obowiązek informacyjny i polityka prywatności. Gdy zbierasz dane bezpośrednio od osoby, artykuł 13 wymaga poinformowania jej m.in. kto jest administratorem, w jakim celu i na jakiej podstawie przetwarzasz dane, komu je przekazujesz, jak długo je przechowujesz oraz jakie ma prawa, łącznie z prawem wniesienia skargi do organu nadzorczego. W praktyce: polityka prywatności dostępna z aplikacji i krótka informacja przy formularzu.

Umowy z dostawcami. Jeśli korzystasz z usług, które przetwarzają dane w Twoim imieniu (hosting, baza danych, wysyłka maili), potrzebna jest umowa powierzenia. Artykuł 28 ust. 3 opisuje, co powinna zawierać: m.in. przetwarzanie wyłącznie na Twoje polecenie, zachowanie poufności, zapewnienie bezpieczeństwa, pomoc w realizacji praw osób, usunięcie lub zwrot danych po zakończeniu usługi i możliwość audytu. Duzi dostawcy zwykle udostępniają gotowy dodatek do umowy (DPA), który akceptujesz w panelu. Sprawdź, czy go masz i gdzie jest zapisany.

Przechowywanie ograniczone w czasie. Zgodnie z art. 5 ust. 1 lit. e dane powinny być przechowywane nie dłużej, niż jest to niezbędne do celu, w którym je zebrano. Ustal, jak długo trzymasz dane (np. nieaktywnych klientów) i jak je usuwasz. Poproś AI o dodanie funkcji usuwania konta i danych, a następnie sprawdź ją sam.

Prawa użytkowników. Osoba, której dane zbierasz, może m.in. żądać dostępu do danych (art. 15), ich sprostowania (art. 16) i usunięcia, gdy nie są już potrzebne albo cofnęła zgodę (art. 17, z wyjątkami), oraz otrzymać je w formacie nadającym się do odczytu maszynowego, jeśli przetwarzanie opiera się na zgodzie lub umowie (art. 20). Zastanów się, jak odpowiesz na taką prośbę: czy umiesz znaleźć wszystkie dane jednej osoby i je usunąć.

Środki bezpieczeństwa i naruszenia. Artykuł 32 wymaga odpowiednich środków technicznych i organizacyjnych dostosowanych do ryzyka. Całą listę kontrolną z tego tekstu można traktować jako praktyczną wersję tej zasady. Przy naruszeniu ochrony danych administrator co do zasady zgłasza je organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia, chyba że naruszenie raczej nie skutkuje ryzykiem dla praw osób (art. 33). W Polsce organem jest Prezes Urzędu Ochrony Danych Osobowych (uodo.gov.pl).

Czy jesteś administratorem, czy podmiotem przetwarzającym, zależy od tego, kto decyduje o celach i sposobach przetwarzania. Jeśli budujesz aplikację dla cudzej firmy i to ona decyduje, jakie dane zbiera, role wyglądają inaczej niż wtedy, gdy zbierasz je dla siebie. Warto to ustalić na piśmie, zanim pierwszy użytkownik się zarejestruje.

Jak poprosić AI o przegląd bezpieczeństwa

AI przydaje się jako pierwsza para oczu, o ile zada się jej konkretne pytania. Kilka poleceń do wklejenia:

• "Przejrzyj kod i znajdź wszystkie miejsca, w których klucze, hasła lub tokeny są wpisane na stałe. Pokaż je i zaproponuj przeniesienie do zmiennych środowiskowych."
• "Wypisz wszystkie tabele w bazie i dla każdej powiedz, czy ma włączone reguły dostępu na poziomie wiersza oraz kto może ją czytać, dodawać, zmieniać i usuwać."
• "Czy zalogowany użytkownik może odczytać lub zmienić dane innego użytkownika, znając jego identyfikator? Pokaż konkretne miejsca w kodzie, które to umożliwiają."
• "Pokaż, które dane z formularzy są sprawdzane tylko w przeglądarce, a które także po stronie serwera lub w bazie."
• "Sprawdź, co aplikacja zapisuje w logach i czy trafiają tam dane osobowe, hasła lub klucze."
• "Zaproponuj ograniczenie liczby zgłoszeń z jednego adresu dla formularza kontaktowego."

Dobry nawyk: poproś o listę problemów posortowaną według wagi, a potem naprawiaj jeden po drugim, sprawdzając aplikację po każdej poprawce.

Dlaczego i tak musisz sprawdzić to sam

AI może się pomylić i bywa przekonujące nawet wtedy. Zdarza się, że napisze "zabezpieczone", a reguły dostępu w bazie wcale nie istnieją. Przegląd zrobiony przez to samo narzędzie, które napisało kod, ma też podobne ślepe punkty. O tym, że AI opisuje zamiar, a nie zawsze skutek, pisałem w tekście aplikacja z AI nie działa: najczęstsze problemy.

Dlatego każdy punkt tej listy zamień w test, który widzisz na własne oczy: drugie konto, okno prywatne, próba odtworzenia kopii, zajrzenie do kodu w przeglądarce. Jeśli czegoś nie umiesz sprawdzić, to dobry znak, że w tym miejscu potrzebujesz kogoś do pomocy.

Gdzie samodzielne sprawdzanie zwykle się sypie

Da się to zrobić samemu, a lista powyżej jest po to, żebyś mógł. Trudności są jednak powtarzalne. Test dwóch kont pokazuje błąd, ale nie mówi, gdzie go naprawić. Poprawka jednego miejsca psuje inne. AI zapewnia, że wszystko jest zabezpieczone, a Ty nie masz jak ocenić, czy to prawda. Do tego dochodzi zwykła samotność z pytaniem: czy to już wystarczy, żeby pokazać aplikację pierwszym ludziom.

Prowadzenie 1:1 zmienia to, że ktoś jest obok, gdy test wychodzi źle. W programie Własna Apka na spotkaniach na żywo przechodzimy przez te punkty na Twoim projekcie i rozwiązujemy błędy, na których zwykle wszystko staje. Budujesz z AI na gotowym szkielecie, a po każdym etapie sprawdzamy, co udało się zrobić. Na start nie musisz znać ani linijki kodu. Zaznaczam wyraźnie: to nie jest audyt bezpieczeństwa ani potwierdzenie zgodności z RODO. To praca nad Twoją aplikacją, żebyś rozumiał, co sprawdzasz i dlaczego.

Kiedy nie robić tego samemu

Wróć do pytania, czy to dobry pierwszy projekt. Aplikacje, które przechowują dane zdrowotne lub finansowe, mają wymogi wykraczające poza tę listę, a pomyłka kosztuje tam więcej. Gdy rozważasz taki projekt, zacznij od wersji bez wrażliwych danych albo skonsultuj się ze specjalistą. Więcej o tym, kiedy samodzielna budowa ma sens, a kiedy nie, w przewodniku jak stworzyć aplikację bez programowania. Pomysły, które mają niskie ryzyko danych, wymieniłem w tekście o pomysłach na aplikację dla małej firmy.

Na koniec

Bezpieczeństwo nie jest etapem na końcu pracy, tylko zbiorem drobnych decyzji podejmowanych po drodze. Dobrze działa to wtedy, gdy ktoś z Tobą przechodzi te punkty na konkretnej aplikacji, a nie na ogólnej liście. Możesz to zrobić sam, z listą z tego tekstu. Program Własna Apka jest dla osób, które wolą zrobić to z kimś obok.

W programie dostajesz: około 15 godzin pracy na żywo, prowadzenie 1:1, w trzech etapach: potrzeba (sprawdzasz pomysł z ludźmi), budowa (budujesz z AI na gotowym szkielecie, nie zaczynasz od pustego ekranu) i wdrożenie (własny adres, pierwsi użytkownicy, oferta). Między spotkaniami dostajesz materiały i zadania do własnego projektu, a potem sprawdzamy każdy etap. Punkty z tej listy przechodzimy na żywo na Twoim projekcie.

Program jest dla osoby, która zbudowała pierwszą wersję z AI albo utknęła na błędach i chce dojść do aplikacji, którą może pokazać ludziom. Nie jest dla osób, które chcą, żeby ktoś zbudował aplikację za nie, ani dla tych, którzy szukają gwarancji klientów lub przychodu: nie budujemy aplikacji za uczestnika i niczego takiego nie gwarantujemy. Nie zastępuje też audytu bezpieczeństwa ani porady prawnej. Wynik zależy od potrzeby rynkowej, jakości rozwiązania i Twojej pracy.

Cena brutto to 4 900 zł na start (albo 3 raty po ok. 1 633 zł) i 7 100 zł dopłaty, ale tylko wtedy, gdy Twoja aplikacja osiągnie 40 000 zł przychodu w 18 miesięcy. To warunek dopłaty, nie prognoza zarobków. Jest też wariant 8 700 zł jednorazowo, bez dopłaty.

Pierwszy krok to zgłoszenie na stronie (8 krótkich pytań), a potem bezpłatna rozmowa. Zgłoszenie nie jest zakupem. Przyjmujemy maksymalnie 5 nowych osób miesięcznie, to nasza zasada pracy.