Frontend miał być tylko widokiem.
W __NEXT_DATA__ znaleźliśmy za dużo prawdy.
Next.js przyspiesza development, ale łatwo przenieść do klienta dane, które powinny zostać po stronie serwera. W testach aplikacji SSR/SSG zawsze sprawdzamy, co faktycznie trafia do HTML-a, propsów, sourcemap i publicznych artefaktów buildu.
Dlaczego Next.js jest ciekawy w pentestach
Framework miesza świat backendu i frontendu. Developer może przypadkowo przekazać do klienta dane z getServerSideProps, konfigurację środowiskową albo obiekty potrzebne tylko serwerowi. W przeglądarce lądują wtedy rzeczy, których użytkownik nie powinien widzieć.
Co sprawdzamy w pierwszej kolejności
Analizujemy HTML, skrypt __NEXT_DATA__, chunk JS, sourcemapy, publiczne pliki konfiguracyjne, nazwy endpointów i zmienne NEXT_PUBLIC_*. Szukamy tokenów, hostów wewnętrznych, identyfikatorów, e-maili, flag funkcji i zbyt szerokich obiektów użytkownika.
Jak to naprawiać
Trzeba minimalizować propsy, oddzielić dane serwerowe od klientowych, trzymać tokeny w HttpOnly cookies, usunąć sourcemapy z produkcji i wdrożyć kontrolę buildów, która blokuje sekrety w artefaktach.
Jak wygląda praktyczna weryfikacja
Jeśli w __NEXT_DATA__ widzisz pełny obiekt użytkownika, listę uprawnień, wewnętrzne URL-e albo tokeny — to nie jest „tylko frontend”. To ekspozycja danych przez warstwę renderowania.
Na co zwracamy uwagę w raporcie
__NEXT_DATA__
Propsy i dane hydratacji potrafią ujawnić więcej niż widok strony.
Source maps
Mapy źródeł pomagają odtworzyć logikę, endpointy i komentarze developerskie.
Zmienne publiczne
NEXT_PUBLIC_* są jawne z definicji. Sekret w tej przestrzeni przestaje być sekretem.
Masz aplikację w Next.js do sprawdzenia?
Robimy pentesty aplikacji webowych SSR/SPA: Next.js, React, API, autoryzacja, IDOR, XSS, wycieki danych i błędy konfiguracji.
Zapytaj o wycenę →