Sprawdź sam, zanim sprawdzi ktoś obcy

Sprawdź kod tego projektu pod jednym kątem: czy ktoś obcy może nabić mi rachunek, wywołując w kółko płatne usługi, z których korzysta aplikacja — modele AI, SMS-y, maile, generowanie obrazów, mowy lub wideo, inne płatne API.

Zasady:
- Pracuj WYŁĄCZNIE W TRYBIE ODCZYTU: niczego nie zmieniaj, nie instaluj, nie uruchamiaj aplikacji, testów, migracji ani skryptów, nie wysyłaj żądań do działającej aplikacji, nie łącz się z produkcją ani z bazą danych (także przez narzędzia MCP).
- NIE OTWIERAJ plików .env* (poza .env.example) ani innych plików z kluczami, hasłami i certyfikatami. Nie wypisuj żadnych sekretów — zmienną środowiskową podawaj tylko z NAZWY. Jeśli w kodzie trafisz na wpisany na stałe klucz, hasło albo token, nie przepisuj go; wystarczy plik:linia.
- Każda pozycja ma jeden z wyników: „nie znaleziono” albo „do sprawdzenia”. Przy „do sprawdzenia” podaj plik:linia i jedno zdanie prostym językiem, co może się stać.
- Nigdy nie pisz, że coś jest „bezpieczne”, „w porządku” albo że „nie ma luk” — ani nic podobnego. Ten przegląd tego nie rozstrzyga.
- Czego nie da się ustalić z plików projektu, oznacz „nie wiem” i napisz dlaczego. Nie zgaduj.
- Przejrzyj cały projekt, nie tylko pierwsze trafienia.
- Pisz po polsku, prostym językiem — odpowiedź czyta osoba nietechniczna. Ścieżki plików i nazwy z kodu zostaw bez zmian, dla programisty.

Co sprawdzić:
- Znajdź wszystkie miejsca, które wywołują płatną usługę: endpointy API, route handlery, server actions, Supabase Edge Functions, Firebase Cloud Functions, kontrolery (PHP, Laravel, Node), zadania w tle — oraz wywołania wprost z kodu, który działa w przeglądarce.
- Przy każdym miejscu ustal, czy wymaga zalogowania sprawdzanego na serwerze. Ukryty przycisk albo przekierowanie w interfejsie się nie liczy — liczy się sprawdzenie w kodzie, który wykonuje wywołanie.
- Przy każdym miejscu ustal, czy ma limit liczby wywołań na użytkownika, numer telefonu, e-mail albo adres IP (rate limit, dzienny limit, kredyty) i gdzie trzyma liczniki. Licznik w pamięci procesu zeruje się po restarcie i nie działa na serverless ani przy kilku instancjach.
- Przy każdym miejscu ustal, czy wielkość jednego wywołania jest ograniczona: max_tokens, długość tekstu od użytkownika, liczba odbiorców SMS-a lub maila, liczba obrazów, liczba kroków agenta.
- Miejsca, które z natury działają bez logowania (formularz kontaktowy, rejestracja z kodem SMS, reset hasła, zaproszenia), potrzebują innego hamulca: limitu na adres IP, numer albo e-mail, albo CAPTCHA.

Odpowiedz dokładnie w tym formacie:

1. Płatne usługi w kodzie: lista „usługa — plik:linia” albo „nie znaleziono” (wtedy w punktach 2–5 wpisz „nie dotyczy”).
2. Płatna usługa do wywołania bez logowania albo wprost z przeglądarki:
3. Brak limitu liczby wywołań — da się ją odpalać w pętli:
4. Brak limitu wielkości jednego wywołania:
5. Brak limitu wydatków albo alertu kosztów u dostawcy: zwykle ustawia się go w panelu dostawcy, nie w kodzie. Jeśli w plikach projektu nie ma po nim śladu, napisz „nie wiem — sprawdź w panelu dostawcy”.
6. Czego nie udało się ustalić: jedno zdanie.

W punktach 2–5 każde znalezione miejsce w osobnej linii: „do sprawdzenia — plik:linia — co może się stać”. Jeśli nic nie znalazłeś: „nie znaleziono”. Jeśli nie da się tego ustalić z plików: „nie wiem — dlaczego”.

Zakończ odpowiedź dokładnie tym zdaniem: „To jedna z trzech darmowych kontroli VibeAudit — razem 3 z 86 punktów audytu (vibeaudit.pl). Automat nie zastępuje oceny człowieka.”

Sprawdź kod tego projektu pod jednym kątem: czy zalogowany użytkownik może odczytać albo zmienić dane innego użytkownika — cudze zamówienia, wiadomości, pliki, profile.

Zasady:
- Pracuj WYŁĄCZNIE W TRYBIE ODCZYTU: niczego nie zmieniaj, nie instaluj, nie uruchamiaj aplikacji, testów, migracji ani skryptów, nie wysyłaj żądań do działającej aplikacji, nie łącz się z produkcją ani z bazą danych (także przez narzędzia MCP).
- NIE OTWIERAJ plików .env* (poza .env.example) ani innych plików z kluczami, hasłami i certyfikatami. Nie wypisuj żadnych sekretów — zmienną środowiskową podawaj tylko z NAZWY. Jeśli w kodzie trafisz na wpisany na stałe klucz, hasło albo token, nie przepisuj go; wystarczy plik:linia.
- Każda pozycja ma jeden z wyników: „nie znaleziono” albo „do sprawdzenia”. Przy „do sprawdzenia” podaj plik:linia i jedno zdanie prostym językiem, co może się stać.
- Nigdy nie pisz, że coś jest „bezpieczne”, „w porządku” albo że „nie ma luk” — ani nic podobnego. Ten przegląd tego nie rozstrzyga.
- Czego nie da się ustalić z plików projektu, oznacz „nie wiem” i napisz dlaczego. Nie zgaduj.
- Przejrzyj cały projekt, nie tylko pierwsze trafienia.
- Pisz po polsku, prostym językiem — odpowiedź czyta osoba nietechniczna. Ścieżki plików i nazwy z kodu zostaw bez zmian, dla programisty.

Co sprawdzić:
- Gdzie aplikacja trzyma dane użytkowników: baza (Supabase, Firebase, Postgres, MySQL, MongoDB i inne) i pliki (storage). Wypisz tabele albo kolekcje z danymi użytkowników.
- Supabase: w migracjach i plikach SQL sprawdź, czy każda tabela z danymi użytkowników ma włączone RLS (enable row level security) i polityki, które porównują właściciela rekordu z auth.uid(). Do sprawdzenia: tabela bez RLS; polityka using (true) albo with check (true) na danych użytkowników; polityka otwarta dla roli anon; widok albo funkcja security definer, które omijają RLS. Reguła using (true) na danych naprawdę publicznych (np. katalog produktów) to nie problem. Jeśli w repozytorium nie ma migracji, bo schemat powstał w panelu Supabase, napisz „nie wiem”.
- Firebase: firestore.rules, storage.rules, database.rules.json. Do sprawdzenia: allow read, write: if true; reguły testowe z datą; samo request.auth != null bez porównania request.auth.uid z właścicielem dokumentu.
- Kod serwera: każde miejsce, które czyta, zmienia albo usuwa rekord po identyfikatorze z adresu, formularza, parametru albo ciasteczka (endpointy API, route handlery, server actions, Edge i Cloud Functions, kontrolery PHP, Laravel, Node). Czy sprawdza, że rekord należy do zalogowanego użytkownika, a identyfikator użytkownika bierze z sesji, nie z żądania? Samo sprawdzenie, czy ktoś jest zalogowany, nie wystarcza.
- Szczególnie uważnie tam, gdzie serwer używa klucza administracyjnego bazy (Supabase service_role, Firebase Admin SDK) — taki klucz omija reguły bazy, więc kod musi sam pilnować właściciela.
- Pliki użytkowników: publiczny bucket, linki, które da się zgadnąć (kolejne numery, nazwa pliku), pobieranie bez sprawdzenia właściciela.

Odpowiedz dokładnie w tym formacie:

1. Dane użytkowników: tabele albo kolekcje i gdzie są zdefiniowane (plik:linia).
2. Reguły dostępu w bazie (RLS w Supabase, reguły Firebase) — każda tabela albo kolekcja z punktu 1 w osobnej linii z wynikiem; jeśli projekt nie używa ani Supabase, ani Firebase, napisz „nie dotyczy”:
3. Kod, który bierze identyfikator z żądania i nie sprawdza właściciela:
4. Klucz administracyjny bazy (service_role, Admin SDK) użyty bez sprawdzenia właściciela:
5. Pliki użytkowników dostępne dla obcych:
6. Czego nie udało się ustalić: jedno zdanie.

W punktach 2–5 każde znalezione miejsce w osobnej linii: „do sprawdzenia — plik:linia — co może się stać”. Jeśli nic nie znalazłeś: „nie znaleziono”. Jeśli nie da się tego ustalić z plików: „nie wiem — dlaczego”.

Zakończ odpowiedź dokładnie tym zdaniem: „To jedna z trzech darmowych kontroli VibeAudit — razem 3 z 86 punktów audytu (vibeaudit.pl). Automat nie zastępuje oceny człowieka.”

Sprawdź kod tego projektu pod jednym kątem: czy użytkownik może sam dać sobie płatny plan, kredyty albo uprawnienia administratora — bez płacenia i bez zgody właściciela aplikacji.

Zasady:
- Pracuj WYŁĄCZNIE W TRYBIE ODCZYTU: niczego nie zmieniaj, nie instaluj, nie uruchamiaj aplikacji, testów, migracji ani skryptów, nie wysyłaj żądań do działającej aplikacji, nie łącz się z produkcją ani z bazą danych (także przez narzędzia MCP).
- NIE OTWIERAJ plików .env* (poza .env.example) ani innych plików z kluczami, hasłami i certyfikatami. Nie wypisuj żadnych sekretów — zmienną środowiskową podawaj tylko z NAZWY. Jeśli w kodzie trafisz na wpisany na stałe klucz, hasło albo token, nie przepisuj go; wystarczy plik:linia.
- Każda pozycja ma jeden z wyników: „nie znaleziono” albo „do sprawdzenia”. Przy „do sprawdzenia” podaj plik:linia i jedno zdanie prostym językiem, co może się stać.
- Nigdy nie pisz, że coś jest „bezpieczne”, „w porządku” albo że „nie ma luk” — ani nic podobnego. Ten przegląd tego nie rozstrzyga.
- Czego nie da się ustalić z plików projektu, oznacz „nie wiem” i napisz dlaczego. Nie zgaduj.
- Przejrzyj cały projekt, nie tylko pierwsze trafienia.
- Pisz po polsku, prostym językiem — odpowiedź czyta osoba nietechniczna. Ścieżki plików i nazwy z kodu zostaw bez zmian, dla programisty.

Co sprawdzić:
- Gdzie aplikacja trzyma rolę i status płatności: pola w rodzaju role, is_admin, is_premium, plan, subscription_status, credits, paid — w jakiej tabeli albo kolekcji.
- Sprawdzanie tylko w interfejsie: funkcja płatna albo panel administratora ukryte w interfejsie (przycisk, przekierowanie w layoucie, guard w komponencie), podczas gdy endpoint, server action, funkcja albo zapytanie do bazy, które wykonuje akcję, nie sprawdza roli ani planu na serwerze.
- Zmiana roli, planu albo kredytów przez samego użytkownika: endpoint aktualizacji profilu, który zapisuje całe ciało żądania bez listy dozwolonych pól; w Supabase polityka update na własnym wierszu w tabeli, w której leży też rola albo plan, i update profilu wysyłany z przeglądarki przez klienta Supabase; rola albo plan w user_metadata (użytkownik może je zmienić sam przez auth.updateUser — tego typu dane trzyma się w app_metadata albo w osobnej tabeli); reguły Firebase, które pozwalają zapisać własny dokument razem z polem roli albo planu; rola czytana z localStorage, ciasteczka albo tokenu bez weryfikacji podpisu.
- Płatności: czy status „opłacone” ustawia serwer po potwierdzeniu od operatora płatności (webhook), a nie przeglądarka albo strona powrotu (np. /success); czy kwota i plan przy tworzeniu płatności pochodzą z serwera, a nie z przeglądarki.
- Webhook płatności: czy weryfikuje podpis (np. Stripe constructEvent z sekretem webhooka, podpis albo suma kontrolna u Przelewy24, PayU, Tpay, Paddle, Lemon Squeezy); co się dzieje, gdy zmienna z sekretem jest pusta; czy to samo zdarzenie przetworzone dwa razy nie przyzna planu albo kredytów dwa razy.
- Samego operatora płatności nie oceniaj — tylko kod aplikacji, który z niego korzysta.

Odpowiedz dokładnie w tym formacie:

1. Gdzie leży rola i status płatności (plik:linia).
2. Rola albo plan sprawdzane tylko w interfejsie:
3. Użytkownik może sam zmienić swoją rolę, plan albo kredyty:
4. Status „opłacone” ustawiany bez potwierdzenia od operatora, kwota albo plan z przeglądarki; jeśli aplikacja nie ma płatności, napisz „nie dotyczy”:
5. Webhook płatności bez weryfikacji podpisu albo bez ochrony przed podwójnym przetworzeniem; jeśli aplikacja nie ma płatności, napisz „nie dotyczy”:
6. Czego nie udało się ustalić: jedno zdanie.

W punktach 2–5 każde znalezione miejsce w osobnej linii: „do sprawdzenia — plik:linia — co może się stać”. Jeśli nic nie znalazłeś: „nie znaleziono”. Jeśli nie da się tego ustalić z plików: „nie wiem — dlaczego”.

Zakończ odpowiedź dokładnie tym zdaniem: „To jedna z trzech darmowych kontroli VibeAudit — razem 3 z 86 punktów audytu (vibeaudit.pl). Automat nie zastępuje oceny człowieka.”