Ten artykuł powstał częściowo z pomocą sztucznej inteligencji.
W skrócie: OWASP Top 10 to lista najpoważniejszych kategorii ryzyka w aplikacjach webowych, publikowana przez fundację OWASP i używana jako punkt odniesienia przez zespoły bezpieczeństwa i audytorów. Aplikacje zbudowane z pomocą AI, na przykład w Lovable z bazą Supabase, najczęściej zawodzą w tych samych miejscach, co opisuje OWASP Top 10, przede wszystkim w kontroli dostępu. Poniżej 12 punktów, które warto sprawdzić, zanim aplikacja zacznie przetwarzać dane klientów albo zanim zapyta o nią audytor w firmie objętej ustawą o KSC.
Lista jest częścią naszego przeglądu wymagań NIS2 i CRA wobec oprogramowania.
Najważniejsze fakty:
OWASP Top 10 to dokument fundacji OWASP, organizacji non-profit zajmującej się bezpieczeństwem aplikacji. Opisuje dziesięć kategorii ryzyka, które najczęściej prowadzą do incydentów w aplikacjach webowych: od błędnej kontroli dostępu, przez błędną konfigurację i podatne komponenty, po wstrzykiwanie kodu i braki w logowaniu zdarzeń.
Aplikacje zbudowane metodą vibe coding nie mają nowych rodzajów błędów. Mają te same, tylko częściej, bo model AI pisze kod, który działa, a o bezpieczeństwo trzeba go poprosić. Dlatego OWASP Top 10 jest dobrym szkieletem listy kontrolnej. Skąd biorą się takie aplikacje w firmach i dlaczego podlegają ustawie o KSC, opisujemy w tekście vibe coding w firmie i obowiązki z ustawy o KSC.
Lovable i podobne narzędzia często łączą aplikację z bazą Supabase. To wygodne, ale niesie konkretne ryzyko: klucz publiczny bazy jest widoczny w kodzie przeglądarki z założenia, więc całe bezpieczeństwo danych opiera się na regułach Row Level Security. Jeśli reguł nie ma albo są zbyt szerokie, każdy, kto zna adres aplikacji, może odczytać tabele. Dokumentacja Supabase opisuje, jak skonfigurować Row Level Security. Warto sprawdzić to w pierwszej kolejności, bo to najczęstsze źródło wycieków w aplikacjach budowanych z AI.
Jeśli aplikacja sama korzysta z modelu językowego, na przykład odpowiada klientom albo streszcza dokumenty, dochodzą ryzyka opisane w liście OWASP Top 10 dla aplikacji LLM: wstrzykiwanie poleceń (prompt injection), ujawnianie danych w odpowiedziach modelu i nadmierne uprawnienia narzędzi, z których model korzysta. Według Google Trends zainteresowanie tą listą szybko rośnie. Minimum to oddzielenie danych od poleceń, ograniczenie uprawnień i niewysyłanie do modelu danych, których nie musi znać.
Lista kontrolna wyłapuje najczęstsze błędy, ale nie zastąpi przeglądu kodu ani testów penetracyjnych, w których specjalista próbuje włamać się do aplikacji tak, jak zrobiłby to atakujący. Dla aplikacji, które przetwarzają dane klientów albo łączą się z systemami firmy, warto zaplanować oba kroki. W firmie objętej ustawą o KSC wynik przeglądu jest też dowodem dla audytora. Jeśli aplikację zbudował zewnętrzny wykonawca, tę samą listę warto wykorzystać przy ocenie dostawcy; piszemy o tym w tekście SZBI i ocena dostawców oprogramowania.
Przegląd małej aplikacji zbudowanej z AI można przeprowadzić w ciągu jednego dnia roboczego, jeśli przygotuje się go z wyprzedzeniem. Potrzebne są: dostęp do kodu lub projektu w narzędziu, w którym aplikację zbudowano, dostęp do panelu bazy danych i hostingu oraz godzina rozmowy z osobą, która aplikację stworzyła.
W aplikacjach budowanych z AI powtarza się kilka problemów. Tabele bez Row Level Security naprawia się, włączając RLS i dodając polityki, które pozwalają użytkownikowi czytać tylko własne rekordy. Klucz z uprawnieniami administratora w kodzie przeglądarki trzeba natychmiast zmienić, a operacje wymagające tych uprawnień przenieść na serwer. Punkty API, które przyjmują identyfikator rekordu i zwracają dane bez sprawdzenia, czy należą one do zalogowanego użytkownika, to klasyczny przykład błędnej kontroli dostępu z pierwszego miejsca OWASP Top 10; poprawka polega na dodaniu weryfikacji po stronie serwera. Brak limitów zapytań rozwiązuje się na poziomie platformy hostingowej albo bramki API.
Większość tych poprawek zajmuje godziny, nie tygodnie. Trudniejsze bywają decyzje organizacyjne: czy narzędzie, które zaczęło się jako eksperyment, a dziś obsługuje setki klientów, nie powinno zostać przepisane i przejęte przez zespół IT. Taka decyzja powinna zapaść świadomie, z udziałem właściciela biznesowego, a nie dopiero po pierwszym incydencie.
Testy penetracyjne warto zlecić, gdy aplikacja przetwarza dane osobowe wielu klientów, obsługuje płatności, łączy się z systemami produkcyjnymi albo jest dostępna publicznie dla każdego. W takich przypadkach lista kontrolna jest punktem wyjścia, a nie końcem pracy. Tester bezpieczeństwa łączy kilka drobnych słabości w realny scenariusz ataku, czego lista kontrolna nie zrobi. Najlepiej najpierw usunąć problemy z listy, a dopiero potem zamówić testy, bo wtedy raport skupia się na trudniejszych błędach, a nie na brakach, które można było znaleźć samodzielnie. W firmach objętych ustawą o KSC wynik testów i lista poprawek to też mocny dowód dla audytora.
Przy wyborze wykonawcy testów warto zapytać o zakres (aplikacja webowa, API, infrastruktura), metodykę, przykładowy raport i to, czy po poprawkach przewidziany jest ponowny test. Testy powinny odbywać się na środowisku, które odpowiada produkcji, ale z danymi testowymi zamiast danych klientów. Po testach warto zaktualizować listę kontrolną o znalezione problemy, żeby kolejne aplikacje budowane z AI od początku ich unikały.
Sanddev sprawdza aplikacje zbudowane z AI według OWASP Top 10, naprawia znalezione problemy i przygotowuje raport dla zarządu. Opisujemy to na stronie o tym, jak wygląda pełny przegląd gotowości aplikacji do produkcji.
OWASP Top 10 to lista dziesięciu najpoważniejszych kategorii ryzyka w aplikacjach webowych, publikowana przez fundację OWASP. Zespoły bezpieczeństwa, programiści i audytorzy używają jej jako punktu odniesienia; na pierwszym miejscu jest błędna kontrola dostępu.
Mogą być, jeśli ktoś sprawdzi ich konfigurację. Aplikacje z Lovable często korzystają z Supabase, a bezpieczeństwo danych zależy wtedy od reguł Row Level Security. Bez nich dane z tabel może odczytać każdy, kto zna adres aplikacji.
Trzeba sprawdzić, czy każda tabela z danymi ma włączone Row Level Security i polityki ograniczające odczyt i zapis, oraz czy klucz service_role nie trafił do kodu przeglądarki ani repozytorium. Opis konfiguracji jest w dokumentacji Supabase.
Nie. Lista kontrolna oparta na OWASP Top 10 wyłapuje najczęstsze błędy, ale testy penetracyjne sprawdzają aplikację tak, jak zrobiłby to atakujący, i znajdują problemy, których lista nie obejmuje.
OWASP Top 10 opisuje ryzyka w aplikacjach webowych, a OWASP Top 10 dla aplikacji LLM dotyczy aplikacji korzystających z modeli językowych, na przykład wstrzykiwania poleceń i ujawniania danych w odpowiedziach modelu.
SZBI, czyli system zarządzania bezpieczeństwem informacji, to główny obowiązek podmiotów kluczowych i ważnych według znowelizowanej ustawy o KSC; trzeba go wdrożyć do 3 kwietnia 2027 r.
SBOM (software bill of materials) to wykaz komponentów oprogramowania, czyli lista bibliotek, modułów i ich wersji, z których zbudowano produkt. Od 11 grudnia 2027 r. Cyber Resilience Act wymaga od producentów produktów z elementami cyfrowymi sporządzenia SBOM w powszechnie używanym formacie odczytywalnym maszynowo, obejmującym co najmniej zależności najwyższego poziomu.
Cyber Resilience Act (CRA, po polsku akt o cyberodporności) od 11 września 2026 r. nakłada na producentów produktów z elementami cyfrowymi obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów.
