It Found An Open Door In My Own Site. Here's The Fix

Point REA at your own app before somebody else takes it apart. We aimed it at our own live site from a throwaway cloud sandbox, fixed what it found, and shipped the pull request.

REA is the reverse engineering skill a whole wave of videos pointed at somebody else's software. On our site, it needed under thirteen minutes and not one write request to show that any website could fill our mailing list. It also found our comment bot's daily cap sitting inside the JavaScript you download from our site. After the fix, the request that used to slip through gets refused.

The result is six rules to run the same audit on your own app: the throwaway sandbox, the exact target, sorting the findings, the config in your bundle, the endpoint brakes, and proving the fix.

REA stands for Reverse Engineer Anything: a set of tools that lets Claude Code take apart the app you ship. Reverse engineering means working out how something is built from the finished thing, like a mechanic reading a car without the factory drawings.

Instead of reading your source code, REA reads the bundle, which is the JavaScript your site actually sends to every visitor. From that bundle it lists the routes, the endpoints your pages call, and anything you left in there by mistake. It cannot hand you the source back, because you only get evidence, and its own docs say it is not a sandbox either.

To install it:

1. Install REA from its official package and pin the version, because it shipped six releases in one week.
2. Run its setup for Claude Code.
3. Turn on the compact profile, since it loads well over a hundred tools into your session.
4. Install only from the official repo, because fake copies with malware inside have already been passed around.

When we ran the install in our sandbox, the agent first checked that the package pointed at the official repo before touching anything. The setup then installed the skill but no tool server, so Claude Code simply used REA's command line versions of the same tools. If your tools do not show up after setup, you do not need to restart anything: call the same steps from the terminal.

The first rule is about where you run it. You are about to let an agent drive a browser and run downloaded tools against your production app. On your laptop, that agent sits next to your keys, your other projects and every account you are signed into. REA's own security notes say it plainly: this is not a sandbox.

A sandbox is a throwaway machine, so whatever goes wrong stays inside it and you delete it. Open a throwaway sandbox on your repo and run the whole audit there, never on your own machine.

We used Kosuke, which runs Claude Code on your own subscription inside a disposable cloud machine. You pick your repo, tell the deploy agent how your app starts, and it gives you a preview, a link where your running app shows up. Every chat also gets its own branch, meaning its own copy of the code, and it ends with a pull request. When we imported our site, the agent installed the package manager and a headless browser, measured the memory, and picked the machine size on its own. A few minutes later our real site was running beside the chat, on a branch nobody else touches.

One trap from an earlier test: a fresh Next.js app showed up in the preview, but nothing on the page responded. The fix is one line in your Next config that allows the preview's address, and the page comes alive.

The limit is that this is the same Claude Code with a box around it, so a local virtual machine or a container does the same job. What matters is the box, not the brand.

Disclosure: Kosuke gave us free access to their top plan. Enter the promo code AIDIVE2026 in the Promo code field right after sign-up and you get thirty dollars of credits instead of the usual ten.

The second rule is what you actually tell REA. If you just say "audit my app", REA's skill stops and asks which app.

REA also never opens a browser by itself, so you start one with a debug port, a door that lets a tool watch everything the page does. Set it up in this order:

1. Keep the debug port on the loopback, the address only your own machine can reach, and give the browser a fresh profile.
2. Block every write request before any page loads, so the audit can read your site but cannot submit a form or change anything.
3. Only then give REA the exact pages you want it to read.

In our prompt we named two pages of our free club and wrote one rule in plain words: never send a write to the live site. That mattered, because the form on those pages feeds a real mailing list with real people on it. The agent took the rule seriously and wrote its own small guard that let reads through and stopped everything else. During the audit, that guard stopped six attempts from the analytics script, and not a single request ever reached our signup form.

REA then did its part: inspecting each page, reading each bundle, taking screenshots and exporting the scripts outside the repo.

The limit is that REA only watches what loads while it is attached, so anything that happened before stays an unknown in the report. Even so, you now have a report on your own live app, written without touching a single piece of its data.

The third rule is to sort before you fix. A report like this is full of alarming lines and you will want to fix them all at once.

REA's own skill wants every conclusion marked as an observation, an inference or an unknown, with an evidence ID. That is what it saw, what it guessed, and what it could not see, and the evidence ID is a receipt you can check. Sort every finding that way first, using only the outsider's view, and commit that version before you open a single source file. Then read your source and mark each line as a real leak, as by design, or as a false positive.

Our report had fifteen findings:

Finding	What REA saw	Our verdict
Signup endpoint	No limit and no check of which site was calling, so any website could make a visitor's browser subscribe any address to our list	Real leak, worst one
Email gate on free packs	The whole pack already sits in the page you load; one line in the browser console removes the gate, or reader mode shows the text	By design
Source maps, keys, cookies	None in the bundles, no cookies anywhere	Good news

The gate is by design because the packs are free on purpose, and our own code says a broken form must never hide a free page.

The limit is the unknown column. REA cannot see what your server does, so you settle those lines by reading your server code.

The fourth rule is about what your bundle carries, because one shared settings file can travel to every visitor without you noticing.

Here is how it happens. You import your config in one helper, and two small interactive components use that helper. The bundler, the tool that packs your code into the files the browser downloads, cannot tell which keys they need, so it ships them all.

That is exactly what REA found in our JavaScript. Our whole site config was sitting in one file, with our mailing list ID, our build folders, and the limits of the bot that answers comments on our videos. It even said how many replies that bot sends a day, a hundred, and how many errors trip its safety switch. The two components that pulled it in only ever read the site name and the list of languages.

The rule: search your shipped JavaScript for your own config keys, and give client components only the fields they read. In our sandbox, the agent split the config into a tiny browser version with just those fields, and the rest stayed on the server. It also added a build step that fails if a server key ever shows up in a shipped file again, so you cannot slip back.

None of this was a password, but anything in that file is public, so your secrets only ever live in server variables.

The fifth rule fixed our real leak, and it applies whenever you have a public form that calls a paid service: your email list, your AI model, or your text message gateway. You call it through a tiny server function you wrote in an afternoon. Ours took an email and passed it straight to the mailing list, and any other website could make a visitor's browser send it one.

The security world's own checklist says it plainly: your access control only works in code the attacker cannot change, which means your server. So put brakes on every endpoint like that:

• Origin check. The Origin header is the stamp a browser puts on a request to say which site sent it, so a form on another website gets refused.
• Rate limit. A cap on how many requests one visitor can send in a short window.
• Consent checked on the server. The box you tick actually travels with the request.

In our sandbox, the agent wrote all of them into our Worker, the small function that runs in front of your pages when you visit. It then tested them against a fake mailing service, never the real one, and every request was refused exactly where it should be. Send from the wrong site and you are refused. Your sixth request in a minute is refused too, and without consent you are rejected.

The limit is that a script can fake the Origin stamp, and the rate limit counts per location, so the real fix for that is double confirmation by email.

The sixth and last rule is to prove the fix, because a wall of green checkmarks is exactly when you stop looking. One developer who tested REA on a desktop app wrote on HackerNoon that it missed entry points the app really had.

So run the same REA steps again on the fixed build, check each fix by hand from the terminal, and only then open the pull request.

On the fixed build, the request that used to slip through our signup form gets refused. Our server keys were gone from every shipped file, the security headers were there, and the Worker tests went from failing to passing. The gate on our free packs was still open, which is what we decided, and the report says so next to every line.

The agent then opened the pull request. The reports are in it only because we asked for them in the prompt. The testing checklist Kosuke builds stayed inside the session, with nothing posted on the pull request itself. If your reviewer only reads GitHub, put the before and after reports in the pull request yourself.

We then brought the same change into our own code, and it goes live with the next deploy of our site.

The whole run was REA aimed at our own live site from a throwaway sandbox, every finding sorted, the real leaks fixed, audited again, and shipped as a pull request. The finding that justified it all was the first one: any website could fill our signup form with anyone's address.

Run this audit before you launch anything with a public form or a paid service behind it, and again whenever you change what ships. Do not run it on software you do not own, because REA's own disclaimer limits it to software you own or are authorized to examine. And it never replaces reading your server code, because that is exactly where the unknowns live.

If you keep one rule, keep this one: run it on yourself, in a box, and fix only what you have sorted.

The exact prompt, the triage table and the Worker fix we shipped are in the free kit for this video.