Er hat eine offene Tür in meiner eigenen Seite gefunden. Der Fix

Richte REA auf deine eigene App, bevor jemand anderes sie auseinandernimmt. Wir haben es aus einer Wegwerf-Cloud-Sandbox auf unsere eigene Live-Seite gerichtet, repariert, was es gefunden hat, und den Pull Request ausgeliefert.

REA ist die Reverse-Engineering-Skill, die eine ganze Welle von Videos auf fremde Software gerichtet hat. Auf unserer Seite brauchte es weniger als dreizehn Minuten und keine einzige Schreibanfrage, um zu zeigen, dass jede Website unsere Mailingliste füllen konnte. Außerdem fand es das Tageslimit unseres Kommentar-Bots mitten in dem JavaScript, das du von unserer Seite herunterlädst. Nach dem Fix wird die Anfrage, die vorher durchgerutscht ist, abgelehnt.

Das Ergebnis sind sechs Regeln, um dasselbe Audit auf deiner eigenen App laufen zu lassen: die Wegwerf-Sandbox, die genaue Ziel-URL, das Sortieren der Funde, die Config in deinem Bundle, die Bremsen für Endpoints und der Beweis, dass der Fix wirkt.

REA steht für Reverse Engineer Anything: ein Satz Werkzeuge, mit dem Claude Code die App auseinandernimmt, die du auslieferst. Reverse Engineering heißt, aus dem fertigen Produkt herauszufinden, wie es gebaut ist, wie ein Mechaniker, der ein Auto ohne die Werkspläne liest.

Statt deinen Quellcode zu lesen, liest REA das Bundle, also das JavaScript, das deine Seite tatsächlich an jeden Besucher schickt. Aus diesem Bundle listet es die Routen auf, die Endpoints, die deine Seiten aufrufen, und alles, was du aus Versehen dort gelassen hast. Den Quellcode kann es dir nicht zurückgeben, denn du bekommst nur Belege, und seine eigene Dokumentation sagt, dass es ebenfalls keine Sandbox ist.

So installierst du es:

1. Installiere REA aus dem offiziellen Paket und pinne die Version, denn es hat sechs Releases in einer Woche veröffentlicht.
2. Führe sein Setup für Claude Code aus.
3. Schalte das Compact-Profil ein, denn es lädt weit über hundert Tools in deine Session.
4. Installiere nur aus dem offiziellen Repo, denn gefälschte Kopien mit Malware sind schon im Umlauf.

Als wir die Installation in unserer Sandbox ausführten, prüfte der Agent zuerst, ob das Paket auf das offizielle Repo zeigt, bevor er irgendetwas anfasste. Das Setup installierte die Skill, aber keinen Tool-Server, also nutzte Claude Code die Kommandozeilenversionen derselben REA-Tools. Wenn deine Tools nach dem Setup nicht auftauchen, musst du nichts neu starten: Rufe dieselben Schritte im Terminal auf.

Die erste Regel betrifft den Ort, an dem du es ausführst. Du lässt gleich einen Agenten einen Browser steuern und heruntergeladene Tools gegen deine Produktions-App laufen. Auf deinem Laptop sitzt dieser Agent neben deinen Schlüsseln, deinen anderen Projekten und jedem Konto, in dem du angemeldet bist. Die Sicherheitshinweise von REA sagen es selbst deutlich: Das ist keine Sandbox.

Eine Sandbox ist ein Wegwerf-Rechner, sodass alles, was schiefgeht, in ihr bleibt und du sie löschst. Öffne eine Wegwerf-Sandbox auf deinem Repo und führe das ganze Audit dort aus, niemals auf deinem eigenen Rechner.

Wir haben Kosuke genutzt, das Claude Code mit deinem eigenen Abo in einem Wegwerf-Rechner in der Cloud laufen lässt. Du wählst dein Repo, sagst dem Deploy-Agenten, wie deine App startet, und bekommst eine Preview, einen Link, unter dem deine laufende App erscheint. Jeder Chat bekommt außerdem seinen eigenen Branch, also seine eigene Kopie des Codes, und endet mit einem Pull Request. Als wir unsere Seite importierten, installierte der Agent den Paketmanager und einen Headless-Browser, maß den Speicher und wählte die Maschinengröße selbst aus. Wenige Minuten später lief unsere echte Seite neben dem Chat, auf einem Branch, den niemand sonst anfasst.

Eine Falle aus einem früheren Test: Eine frische Next.js-App erschien in der Preview, aber nichts auf der Seite reagierte. Die Lösung ist eine Zeile in deiner Next-Config, die die Adresse der Preview erlaubt, und die Seite wacht auf.

Die Grenze: Das ist dasselbe Claude Code mit einer Kiste drumherum, also erledigt eine lokale virtuelle Maschine oder ein Container dieselbe Aufgabe. Es zählt die Kiste, nicht die Marke.

Offenlegung: Kosuke hat uns kostenlosen Zugang zu seinem Top-Tarif gegeben. Gib direkt nach der Anmeldung den Code AIDIVE2026 im Feld „Promo code“ ein, dann bekommst du dreißig Dollar Guthaben statt der üblichen zehn.

Die zweite Regel ist das, was du REA tatsächlich sagst. Wenn du nur "audite meine App" sagst, hält die Skill von REA an und fragt, welche App gemeint ist.

REA öffnet außerdem nie von selbst einen Browser, also startest du einen mit einem Debug-Port, einer Tür, durch die ein Tool alles beobachten kann, was die Seite tut. Richte es in dieser Reihenfolge ein:

1. Lass den Debug-Port auf dem Loopback, der Adresse, die nur dein eigener Rechner erreicht, und gib dem Browser ein frisches Profil.
2. Blockiere jede Schreibanfrage, bevor irgendeine Seite lädt, damit das Audit deine Seite lesen, aber kein Formular absenden und nichts ändern kann.
3. Erst dann gibst du REA die genauen Seiten, die es lesen soll.

In unserem Prompt nannten wir zwei Seiten unseres kostenlosen Clubs und schrieben eine Regel in einfachen Worten: nie eine Schreibanfrage an die Live-Seite senden. Das war wichtig, denn das Formular auf diesen Seiten füttert eine echte Mailingliste mit echten Menschen darin. Der Agent nahm die Regel ernst und schrieb seinen eigenen kleinen Wächter, der Lesezugriffe durchließ und alles andere stoppte. Während des Audits stoppte dieser Wächter sechs Versuche des Analytics-Skripts, und keine einzige Anfrage erreichte unser Anmeldeformular.

Danach machte REA seinen Teil: jede Seite untersuchen, jedes Bundle lesen, Screenshots machen und die Skripte außerhalb des Repos exportieren.

Die Grenze: REA sieht nur, was lädt, während es angehängt ist, also bleibt alles, was vorher passiert ist, im Bericht ein Unbekanntes. Trotzdem hast du jetzt einen Bericht über deine eigene Live-App, geschrieben, ohne ein einziges ihrer Daten anzufassen.

Die dritte Regel lautet: erst sortieren, dann reparieren. Ein solcher Bericht ist voller alarmierender Zeilen, und du willst alle auf einmal reparieren.

Die Skill von REA verlangt, dass jede Schlussfolgerung als Beobachtung, Schlussfolgerung oder Unbekanntes markiert wird, mit einer Evidence-ID. Das ist, was es gesehen hat, was es vermutet hat und was es nicht sehen konnte, und die Evidence-ID ist ein Beleg, den du prüfen kannst. Sortiere zuerst jeden Fund so, nur aus der Sicht von außen, und committe diese Version, bevor du eine einzige Quelldatei öffnest. Lies dann deinen Quellcode und markiere jede Zeile als echte Lücke, als gewollt oder als Fehlalarm.

Unser Bericht hatte fünfzehn Funde:

Fund	Was REA gesehen hat	Unser Urteil
Anmelde-Endpoint	Kein Limit und keine Prüfung, welche Seite aufruft, sodass jede Website den Browser eines Besuchers dazu bringen konnte, jede Adresse in unsere Liste einzutragen	Echte Lücke, die schlimmste
E-Mail-Gate bei den Gratis-Packs	Das ganze Pack steckt schon in der Seite, die du lädst; eine Zeile in der Browser-Konsole entfernt das Gate, oder der Lesemodus zeigt den Text	Gewollt
Source Maps, Schlüssel, Cookies	Keine in den Bundles, nirgends Cookies	Gute Nachricht

Das Gate ist gewollt, weil die Packs absichtlich gratis sind, und unser eigener Code sagt, dass ein kaputtes Formular nie eine kostenlose Seite verstecken darf.

Die Grenze ist die Spalte mit dem Unbekannten. REA kann nicht sehen, was dein Server tut, also klärst du diese Zeilen, indem du deinen Servercode liest.

Die vierte Regel betrifft das, was dein Bundle trägt, denn eine gemeinsame Einstellungsdatei kann zu jedem Besucher reisen, ohne dass du es merkst.

So passiert das. Du importierst deine Config in einem Helper, und zwei kleine interaktive Komponenten nutzen diesen Helper. Der Bundler, das Werkzeug, das deinen Code in die Dateien packt, die der Browser herunterlädt, kann nicht erkennen, welche Schlüssel sie brauchen, und liefert deshalb alle aus.

Genau das hat REA in unserem JavaScript gefunden. Unsere gesamte Site-Config lag in einer Datei, mit der ID unserer Mailingliste, unseren Build-Ordnern und den Limits des Bots, der Kommentare unter unseren Videos beantwortet. Sie verriet sogar, wie viele Antworten der Bot pro Tag sendet, hundert, und wie viele Fehler seinen Sicherheitsschalter auslösen. Die zwei Komponenten, die sie eingebunden hatten, lasen nur den Namen der Seite und die Liste der Sprachen.

Die Regel: Durchsuche dein ausgeliefertes JavaScript nach deinen eigenen Config-Schlüsseln und gib Client-Komponenten nur die Felder, die sie lesen. In unserer Sandbox teilte der Agent die Config in eine winzige Browser-Version mit genau diesen Feldern auf, und der Rest blieb auf dem Server. Er fügte außerdem einen Build-Schritt hinzu, der fehlschlägt, wenn je wieder ein Server-Schlüssel in einer ausgelieferten Datei auftaucht, sodass du nicht zurückrutschen kannst.

Nichts davon war ein Passwort, aber alles in dieser Datei ist öffentlich, deshalb leben deine Secrets nur in Server-Variablen.

Die fünfte Regel hat unsere echte Lücke geschlossen, und sie gilt immer, wenn du ein öffentliches Formular hast, das einen bezahlten Dienst aufruft: deine E-Mail-Liste, dein KI-Modell oder dein SMS-Gateway. Du rufst ihn über eine winzige Serverfunktion auf, die du an einem Nachmittag geschrieben hast. Unsere nahm eine E-Mail entgegen und reichte sie direkt an die Mailingliste weiter, und jede andere Website konnte den Browser eines Besuchers dazu bringen, sie zu senden.

Die Checkliste der Sicherheitswelt sagt es deutlich: Deine Zugriffskontrolle wirkt nur in Code, den der Angreifer nicht ändern kann, also auf deinem Server. Bau deshalb Bremsen in jeden solchen Endpoint ein:

• Origin-Prüfung. Der Origin-Header ist der Stempel, den ein Browser auf eine Anfrage setzt, um zu sagen, welche Seite sie geschickt hat, sodass ein Formular auf einer fremden Website abgelehnt wird.
• Rate Limit. Eine Obergrenze dafür, wie viele Anfragen ein Besucher in einem kurzen Zeitfenster senden darf.
• Einwilligung auf dem Server geprüft. Das Kästchen, das du anhakst, reist tatsächlich mit der Anfrage.

In unserer Sandbox schrieb der Agent all das in unseren Worker, die kleine Funktion, die vor deinen Seiten läuft, wenn du sie besuchst. Er testete sie dann gegen einen falschen Mailingdienst, nie den echten, und jede Anfrage wurde genau dort abgelehnt, wo sie sollte. Wer von der falschen Seite sendet, wird abgelehnt. Deine sechste Anfrage in einer Minute wird ebenfalls abgelehnt, und ohne Einwilligung wirst du zurückgewiesen.

Die Grenze: Ein Skript kann den Origin-Stempel fälschen, und das Rate Limit zählt pro Standort, also ist die echte Lösung dafür die doppelte Bestätigung per E-Mail.

Die sechste und letzte Regel ist, den Fix zu beweisen, denn eine Wand grüner Häkchen ist genau der Moment, in dem du aufhörst hinzusehen. Ein Entwickler, der REA an einer Desktop-App getestet hat, schrieb auf HackerNoon, dass es Einstiegspunkte übersehen hat, die die App tatsächlich hatte.

Lass also dieselben REA-Schritte auf dem reparierten Build noch einmal laufen, prüfe jeden Fix von Hand im Terminal und öffne erst dann den Pull Request.

Auf dem reparierten Build wird die Anfrage, die früher durch unser Anmeldeformular rutschte, abgelehnt. Unsere Server-Schlüssel waren aus jeder ausgelieferten Datei verschwunden, die Sicherheits-Header waren da, und die Worker-Tests gingen von fehlschlagend auf bestanden. Das Gate bei unseren Gratis-Packs war weiter offen, so wie wir es entschieden haben, und der Bericht sagt das neben jeder Zeile.

Danach öffnete der Agent den Pull Request. Die Berichte stehen nur darin, weil wir sie im Prompt verlangt haben. Die Testcheckliste, die Kosuke erstellt, blieb in der Session, ohne dass etwas auf dem Pull Request selbst gepostet wurde. Wenn dein Reviewer nur GitHub liest, lege die Berichte von vorher und nachher selbst in den Pull Request.

Danach haben wir dieselbe Änderung in unseren eigenen Code übernommen, und sie geht mit dem nächsten Deploy unserer Seite live.

Der ganze Lauf war REA, gerichtet auf unsere eigene Live-Seite aus einer Wegwerf-Sandbox, jeder Fund sortiert, die echten Lücken repariert, erneut auditiert und als Pull Request ausgeliefert. Der Fund, der alles rechtfertigte, war der erste: Jede Website konnte unser Anmeldeformular mit der Adresse von irgendjemandem füllen.

Führe dieses Audit aus, bevor du etwas mit einem öffentlichen Formular oder einem bezahlten Dienst dahinter startest, und erneut, wenn du änderst, was ausgeliefert wird. Führe es nicht auf Software aus, die dir nicht gehört, denn der eigene Disclaimer von REA beschränkt es auf Software, die du besitzt oder untersuchen darfst. Und es ersetzt nie das Lesen deines Servercodes, denn genau dort liegen die Unbekannten.

Wenn du dir nur eine Regel merkst, dann diese: Führe es auf dir selbst aus, in einer Kiste, und repariere nur, was du sortiert hast.

Der genaue Prompt, die Triage-Tabelle und der Worker-Fix, den wir ausgeliefert haben, stehen im Gratis-Kit zu diesem Video.