Source map exposure check

When your app is built for production, the readable code you wrote is compressed into something a browser can download quickly and a person can barely read. A source map is the file that reverses that. It maps the compressed bundle back to your original files, with your folder names, your function names, your comments and, often, whole files that were never meant to leave your machine.

Source maps exist for a good reason. They make a stack trace in production readable. The problem is that they are on by default while you are building, and turning them off for the published version is a build setting nobody thinks about. An agent optimising for a deploy that works has no reason to touch it, and nothing about your app looks different when the maps ship, which is why so many published AI-built apps are still handing them out.

What a reader gets from a published map is the shape of your product. The names of internal routes, the fields you send to your backend, the checks you run on the client, the feature you have not launched yet, and now and then a comment explaining exactly which part is fragile. None of that is a breach on its own. All of it shortens the distance between a curious stranger and a real attempt.

This tool fetches the scripts your published page loads, reads the last line of each bundle where the map reference lives, and requests the map only to confirm whether it answers. It reports the file it found, the address of the map and the date it was read. It never stores the contents of your code, and a clean result here is one check out of sixteen, not a verdict on the app.

This page is for running the check. The finding page explains the issue itself, and it is the page to read or link when you want the explanation rather than the test. Read the finding page.