Znalazł otwarte drzwi w mojej własnej stronie. Oto poprawka

Wyceluj REA we własną aplikację, zanim ktoś inny ją rozbierze. My wycelowaliśmy go w naszą stronę na żywo z jednorazowego sandboxa w chmurze, naprawiliśmy to, co znalazł, i wysłaliśmy pull request.

REA to skill do inżynierii wstecznej, który cała fala filmów kierowała na cudze oprogramowanie. Na naszej stronie potrzebował niecałych trzynastu minut i ani jednego zapytania zapisu, żeby pokazać, że dowolna strona internetowa mogła zapełnić naszą listę mailingową. Znalazł też dzienny limit naszego bota od komentarzy, leżący w JavaScripcie, który pobiera się z naszej strony. Po poprawce zapytanie, które wcześniej przechodziło, jest odrzucane.

Wynikiem jest sześć zasad, by przeprowadzić taki sam audyt własnej aplikacji: jednorazowy sandbox, dokładny cel, sortowanie znalezisk, konfiguracja w Twoim bundle, hamulce na endpointach i dowód, że poprawka działa.

REA to skrót od Reverse Engineer Anything: zestaw narzędzi, który pozwala Claude Code rozebrać aplikację, którą publikujesz. Inżynieria wsteczna oznacza ustalanie, jak coś jest zbudowane, na podstawie gotowego produktu, jak mechanik czytający samochód bez fabrycznych rysunków.

Zamiast czytać Twój kod źródłowy, REA czyta bundle, czyli JavaScript, który Twoja strona naprawdę wysyła każdemu odwiedzającemu. Z tego bundle wypisuje trasy, endpointy wywoływane przez Twoje strony i wszystko, co zostawiłeś tam przez pomyłkę. Nie odda Ci kodu źródłowego, bo dostajesz tylko dowody, a jego własna dokumentacja mówi, że to też nie jest sandbox.

Aby go zainstalować:

1. Zainstaluj REA z oficjalnego pakietu i przypnij wersję, bo wydał sześć wersji w ciągu jednego tygodnia.
2. Uruchom jego setup dla Claude Code.
3. Włącz profil compact, bo ładuje do sesji dużo ponad sto narzędzi.
4. Instaluj tylko z oficjalnego repo, bo krążyły już fałszywe kopie ze złośliwym oprogramowaniem w środku.

Gdy wykonaliśmy instalację w naszym sandboksie, agent najpierw sprawdził, czy pakiet wskazuje na oficjalne repo, zanim cokolwiek ruszył. Setup zainstalował potem skill, ale żaden serwer narzędzi, więc Claude Code po prostu użył wersji wiersza poleceń tych samych narzędzi REA. Jeśli po setupie Twoje narzędzia się nie pojawią, nie musisz niczego restartować: wywołaj te same kroki z terminala.

Pierwsza zasada dotyczy tego, gdzie go uruchamiasz. Zaraz pozwolisz agentowi sterować przeglądarką i uruchamiać pobrane narzędzia przeciwko Twojej aplikacji produkcyjnej. Na Twoim laptopie ten agent siedzi obok Twoich kluczy, innych projektów i każdego konta, na które jesteś zalogowany. Własne uwagi REA o bezpieczeństwie mówią to wprost: to nie jest sandbox.

Sandbox to jednorazowa maszyna, więc cokolwiek pójdzie źle, zostaje w środku, a Ty ją usuwasz. Otwórz jednorazowy sandbox na swoim repo i przeprowadź tam cały audyt, nigdy na własnej maszynie.

Użyliśmy Kosuke, który uruchamia Claude Code na Twojej własnej subskrypcji wewnątrz jednorazowej maszyny w chmurze. Wybierasz repo, mówisz deploy agentowi, jak startuje Twoja aplikacja, a on daje Ci preview, czyli link, pod którym pojawia się działająca aplikacja. Każdy czat dostaje też własny branch, czyli własną kopię kodu, i kończy się pull requestem. Gdy zaimportowaliśmy naszą stronę, agent zainstalował menedżer pakietów i przeglądarkę headless, zmierzył pamięć i sam wybrał rozmiar maszyny. Kilka minut później nasza prawdziwa strona działała obok czatu, na branchu, którego nikt inny nie dotyka.

Jedna pułapka z wcześniejszego testu: świeża aplikacja Next.js pojawiła się w preview, ale nic na stronie nie reagowało. Rozwiązaniem jest jedna linijka w konfiguracji Next, która zezwala na adres preview, i strona ożywa.

Ograniczenie jest takie, że to ten sam Claude Code z pudełkiem dookoła, więc lokalna maszyna wirtualna albo kontener robią tę samą robotę. Liczy się pudełko, nie marka.

Ujawnienie: Kosuke dał nam darmowy dostęp do swojego najwyższego planu. Wpisz kod AIDIVE2026 w polu „Promo code” zaraz po rejestracji, a dostaniesz trzydzieści dolarów kredytów zamiast zwykłych dziesięciu.

Druga zasada to to, co faktycznie mówisz REA. Jeśli powiesz tylko "zrób audyt mojej aplikacji", skill REA zatrzymuje się i pyta, o którą aplikację chodzi.

REA nigdy też sam nie otwiera przeglądarki, więc uruchamiasz ją z portem debugowania, czyli drzwiami, które pozwalają narzędziu obserwować wszystko, co robi strona. Ustaw to w tej kolejności:

1. Trzymaj port debugowania na loopbacku, czyli adresie osiągalnym tylko z Twojej maszyny, i daj przeglądarce świeży profil.
2. Zablokuj każde zapytanie zapisu, zanim załaduje się jakakolwiek strona, żeby audyt mógł czytać Twoją stronę, ale nie mógł wysłać formularza ani nic zmienić.
3. Dopiero wtedy daj REA dokładne strony, które ma przeczytać.

W naszym prompcie wskazaliśmy dwie strony naszego darmowego klubu i zapisaliśmy jedną zasadę prostymi słowami: nigdy nie wysyłaj zapisu do działającej strony. To miało znaczenie, bo formularz na tych stronach zasila prawdziwą listę mailingową z prawdziwymi ludźmi. Agent potraktował zasadę poważnie i sam napisał małego strażnika, który przepuszczał odczyty i zatrzymywał całą resztę. Podczas audytu ten strażnik zatrzymał sześć prób ze skryptu analitycznego, a ani jedno zapytanie nie dotarło do naszego formularza zapisu.

REA zrobił potem swoją część: sprawdził każdą stronę, przeczytał każdy bundle, zrobił zrzuty ekranu i wyeksportował skrypty poza repo.

Ograniczenie jest takie, że REA widzi tylko to, co się ładuje, gdy jest podłączony, więc wszystko, co stało się wcześniej, zostaje w raporcie niewiadomą. Mimo to masz teraz raport o własnej działającej aplikacji, napisany bez dotykania ani jednej jej danej.

Trzecia zasada: sortuj, zanim naprawisz. Taki raport jest pełen niepokojących linii i będziesz chciał naprawić wszystkie naraz.

Skill REA chce, by każdy wniosek był oznaczony jako obserwacja, wnioskowanie albo niewiadoma, z identyfikatorem dowodu. To jest to, co zobaczył, co zgadł i czego nie mógł zobaczyć, a identyfikator dowodu to pokwitowanie, które możesz sprawdzić. Najpierw posortuj w ten sposób każde znalezisko, używając tylko widoku z zewnątrz, i zrób commit tej wersji, zanim otworzysz choć jeden plik źródłowy. Potem przeczytaj swój kod i oznacz każdą linię jako prawdziwy wyciek, zamierzone działanie albo fałszywy alarm.

Nasz raport miał piętnaście znalezisk:

Znalezisko	Co zobaczył REA	Nasz werdykt
Endpoint zapisu	Brak limitu i brak sprawdzania, która strona go wywołuje, więc dowolna strona mogła sprawić, że przeglądarka odwiedzającego zapisywała dowolny adres na naszą listę	Prawdziwy wyciek, najgorszy
Bramka mailowa na darmowych paczkach	Cała paczka jest już w ładowanej stronie; jedna linijka w konsoli przeglądarki usuwa bramkę, a tryb czytania pokazuje tekst	Zamierzone
Source mapy, klucze, ciasteczka	Brak w bundle, nigdzie żadnych ciasteczek	Dobra wiadomość

Bramka jest zamierzona, bo paczki są darmowe celowo, a nasz własny kod mówi, że zepsuty formularz nigdy nie może ukrywać darmowej strony.

Ograniczenie to kolumna niewiadomych. REA nie widzi, co robi Twój serwer, więc te linie rozstrzygasz, czytając kod serwera.

Czwarta zasada dotyczy tego, co niesie Twój bundle, bo jeden wspólny plik ustawień może trafić do każdego odwiedzającego bez Twojej wiedzy.

Dzieje się to tak. Importujesz konfigurację w jednym helperze, a dwa małe interaktywne komponenty używają tego helpera. Bundler, narzędzie pakujące Twój kod w pliki pobierane przez przeglądarkę, nie umie stwierdzić, których kluczy potrzebują, więc wysyła wszystkie.

Dokładnie to REA znalazł w naszym JavaScripcie. Cała konfiguracja naszej strony leżała w jednym pliku, razem z ID naszej listy mailingowej, naszymi folderami buildu i limitami bota odpowiadającego na komentarze pod naszymi filmami. Mówiła nawet, ile odpowiedzi dziennie wysyła ten bot, sto, i ile błędów uruchamia jego wyłącznik bezpieczeństwa. Dwa komponenty, które ją importowały, czytały tylko nazwę strony i listę języków.

Zasada: przeszukaj wysłany JavaScript pod kątem własnych kluczy konfiguracji i daj komponentom klienckim tylko pola, które czytają. W naszym sandboksie agent podzielił konfigurację na malutką wersję dla przeglądarki z samymi tymi polami, a reszta została na serwerze. Dodał też krok buildu, który kończy się błędem, jeśli klucz serwera kiedykolwiek znów pojawi się w wysłanym pliku, więc nie da się do tego wrócić.

Nic z tego nie było hasłem, ale wszystko w tym pliku jest publiczne, więc Twoje sekrety żyją wyłącznie w zmiennych serwera.

Piąta zasada naprawiła nasz prawdziwy wyciek i dotyczy każdej sytuacji, gdy masz publiczny formularz wywołujący płatną usługę: Twoją listę mailingową, Twój model AI albo bramkę SMS. Wywołujesz ją przez maleńką funkcję serwerową napisaną w jedno popołudnie. Nasza brała adres e-mail i przekazywała go prosto na listę mailingową, a dowolna inna strona mogła sprawić, że przeglądarka odwiedzającego wysyłała to zapytanie.

Lista kontrolna świata bezpieczeństwa mówi to wprost: Twoja kontrola dostępu działa tylko w kodzie, którego atakujący nie może zmienić, czyli na Twoim serwerze. Więc załóż hamulce na każdy taki endpoint:

• Sprawdzanie Origin. Nagłówek Origin to pieczątka, którą przeglądarka stawia na zapytaniu, by powiedzieć, która strona je wysłała, więc formularz z innej strony zostaje odrzucony.
• Rate limit. Limit tego, ile zapytań jeden odwiedzający może wysłać w krótkim oknie.
• Zgoda sprawdzana na serwerze. Zaznaczone pole faktycznie podróżuje wraz z zapytaniem.

W naszym sandboksie agent wpisał wszystkie trzy do naszego Workera, małej funkcji uruchamianej przed Twoimi stronami, gdy je odwiedzasz. Potem przetestował je na fałszywej usłudze mailingowej, nigdy na prawdziwej, a każde zapytanie zostało odrzucone dokładnie tam, gdzie trzeba. Wyślesz z niewłaściwej strony, zostaniesz odrzucony. Twoje szóste zapytanie w ciągu minuty też zostaje odrzucone, a bez zgody jesteś odesłany.

Ograniczenie jest takie, że skrypt może podrobić pieczątkę Origin, a rate limit liczy na lokalizację, więc prawdziwym lekarstwem jest podwójne potwierdzenie e-mailem.

Szósta i ostatnia zasada to udowodnić poprawkę, bo ściana zielonych ptaszków to dokładnie moment, w którym przestajesz patrzeć. Jeden deweloper, który testował REA na aplikacji desktopowej, napisał na HackerNoon, że ominął punkty wejścia, które aplikacja naprawdę miała.

Więc uruchom te same kroki REA jeszcze raz na poprawionym buildzie, sprawdź każdą poprawkę ręcznie z terminala i dopiero wtedy otwórz pull request.

Na poprawionym buildzie zapytanie, które wcześniej przechodziło przez nasz formularz zapisu, jest odrzucane. Nasze klucze serwera zniknęły ze wszystkich wysłanych plików, nagłówki bezpieczeństwa były na miejscu, a testy Workera przeszły z niezaliczonych do zaliczonych. Bramka na naszych darmowych paczkach nadal była otwarta, i tak zdecydowaliśmy, a raport mówi o tym przy każdej linii.

Agent otworzył potem pull request. Raporty w nim są tylko dlatego, że poprosiliśmy o nie w prompcie. Lista kontrolna testów, którą buduje Kosuke, została w sesji, bez niczego opublikowanego w samym pull requeście. Jeśli Twój recenzent czyta tylko GitHub, wstaw raporty przed i po do pull requesta sam.

Potem przenieśliśmy tę samą zmianę do naszego kodu i pójdzie na żywo przy następnym deployu naszej strony.

Cały przebieg to REA wycelowany w naszą stronę na żywo z jednorazowego sandboxa, każde znalezisko posortowane, prawdziwe wycieki naprawione, audyt powtórzony i wysłany jako pull request. Znalezisko, które to wszystko uzasadniło, było pierwsze: dowolna strona mogła wypełnić nasz formularz zapisu cudzym adresem.

Uruchom ten audyt, zanim wystartujesz cokolwiek z publicznym formularzem albo płatną usługą za nim, i znowu za każdym razem, gdy zmieniasz to, co jest wysyłane. Nie uruchamiaj go na oprogramowaniu, którego nie posiadasz, bo zastrzeżenie REA ogranicza go do oprogramowania, które posiadasz lub masz prawo badać. I nigdy nie zastępuje czytania kodu serwera, bo to właśnie tam leżą niewiadome.

Jeśli zachowasz jedną zasadę, zachowaj tę: uruchom go na sobie, w pudełku, i naprawiaj tylko to, co posortowałeś.

Dokładny prompt, tabela triage i poprawka Workera, którą wysłaliśmy, są w darmowym zestawie do tego filmu.