Czy Państwa użytkownicy widzą cudze dane? Proszę sprawdzić prototyp samodzielnie

Dla vibe coderów i założycieli, których prototyp z Lovable, Bolt, Cursora lub Claude Code ma już pierwszych użytkowników. Proszę otworzyć repozytorium w narzędziu, wkleić prompt i pozwolić agentowi pracować. Zajmuje to około 10 minut.

AI pisze dziś cały nasz kod, a za wynik odpowiada senior. Te sześć obszarów sprawdzamy jako pierwsze w każdym prototypie, który przejmujemy.

1. Prompt

Prompt zabrania agentowi cokolwiek zmieniać i wypisywać pełne sekrety.

Jesteś recenzentem bezpieczeństwa. Przejdź przez to repozytorium i niczego w nim nie zmieniaj. Nie uruchamiaj poleceń, które coś zapisują, wdrażają lub łączą się z produkcją. Gdy znajdziesz sekret (klucz, hasło, token), nie wypisuj go w całości: podaj tylko plik, linię i pierwsze 4 znaki.

Sprawdź te 6 obszarów. Przy każdym napisz STAN (OK / PROBLEM / NIE WIEM), DOWÓD (plik i linia albo czego brakuje) i CO ZROBIĆ (jedno zdanie).

1. Dostęp do danych (RLS): jeśli aplikacja używa Supabase, Firebase lub podobnej bazy wywoływanej bezpośrednio z przeglądarki, czy każda tabela ma włączone Row Level Security lub security rules, które dopuszczają użytkownika tylko do jego własnych wierszy? Wypisz tabele bez reguł i reguły, które przepuszczają wszystkich.
2. Klucze w kodzie: czy w repozytorium lub w historii git są klucze, hasła albo tokeny? Czy .env jest w .gitignore? Czy w kodzie, który działa w przeglądarce, jest klucz, który nie powinien się tam znaleźć (klucz service role, tajny klucz API, klucz do płatności)?
3. Logowanie i uprawnienia: czy serwer przy każdej ścieżce API sprawdza, kto jest zalogowany i czy ma prawo do tych danych? Wypisz ścieżki, które zwracają lub zmieniają dane bez sprawdzenia. Czy rola (na przykład admin) jest sprawdzana na serwerze, czy tylko przez ukrycie przycisku w interfejsie?
4. Gdzie to działa: czy hosting, baza danych i domena są na koncie firmowym, czy na prywatnym koncie jednej osoby? Szukaj śladów w konfiguracji (nazwy projektów, e-maile, URL). Jeśli nie da się tego ustalić z kodu, napisz NIE WIEM i o co mam zapytać.
5. Kopie zapasowe: czy jest ustawione regularne tworzenie kopii bazy danych i czy gdzieś opisano, jak kopię przywrócić?
6. Monitoring: czy dowiemy się o błędzie na produkcji wcześniej niż użytkownik? Szukaj przechwytywania błędów, logów i alertów.

Na końcu podaj tabelę: obszar, stan, waga (KRYTYCZNE / WYSOKIE / ŚREDNIE) i najważniejszy krok. KRYTYCZNE jest wszystko, przez co obca osoba dostanie się do cudzych danych lub sekretów. Posortuj tabelę od największego ryzyka i pod nią napisz liczbę ustaleń według wagi. Niczego nie wymyślaj: czego nie widzisz w kodzie, oznacz NIE WIEM.

2. Jak czytać odpowiedź

• PROBLEM w obszarach 1 do 3 proszę rozwiązać przed kolejnymi użytkownikami. Tam obca osoba najczęściej dostaje się do cudzych danych.
• NIE WIEM to nie OK. Oznacza, że odpowiedzi nie ma w kodzie. Proszę zapytać osobę, która ma dostęp do hostingu i bazy danych.
• Proszę samodzielnie sprawdzić co najmniej jedno ustalenie. Otworzyć plik i linię wskazaną przez agenta. Jeśli nic tam nie ma, agent zmyśla i pozostałe ustalenia trzeba traktować ostrożnie.
• Klucz, który był kiedyś w repozytorium, proszę wymienić. Usunięcie go z kodu nie wystarczy, zostaje w historii.
• OK we wszystkich sześciu obszarach nie oznacza, że prototyp jest bezpieczny. Prompt znajduje część problemów, nie wszystkie. Oznacza tylko, że podstawy są na miejscu.
• Wzmocnić czy przepisać? Gdy wiedzą Państwo, co naprawić, test prototypu powie, czy poprawki wystarczą.

3. Co znalazła kontrola

Proszę zaznaczyć obszary, w których agent napisał PROBLEM lub NIE WIEM.