LaunchPreflight runs entirely on your own machine. The web app is a static page with no backend, no account and no telemetry, and everything it stores lives in your browser's local storage.

The part worth reading carefully is the optional verifier.

npm run verify:serve starts a small local daemon that the app drives. It makes outbound HTTP requests to the site you point it at, resolves DNS, and opens a TLS connection to read the certificate. It writes nothing anywhere and never sends your data to a third party.

Four independent checks keep it from becoming a tool for probing your own network:

• It binds to 127.0.0.1 only, so nothing on the network can reach it.
• It answers only requests addressed to a loopback hostname. Without this, DNS rebinding would defeat everything else: an attacker points their own domain at 127.0.0.1, their page becomes same-origin with the daemon, and no CORS check ever runs.
• It answers only browser origins on its allowlist — on the preflight and on the request itself — so another site's JavaScript gets a 403 before any work happens.
• It refuses to probe loopback, link-local and RFC 1918 addresses, cloud metadata endpoints included, and domains reserved for documentation. --allow-private lifts the address restriction if you are testing staging on a LAN.

--token <value> additionally requires a bearer token on every request. It is off by default, because those four checks are what actually keep other pages out.

One probe, exposed-files, requests a short list of paths that should never survive a deploy — /.env, /.git/HEAD, /.git/config, /composer.lock, /package.json, /.DS_Store — and reports whether they are publicly readable. This is exactly what the sec-secrets checklist item asks you to confirm by hand, and it is the reason that check can be verified at all.

It only ever issues GET requests, reads at most the first two kilobytes, and never writes anything. It is not an exploit. But in someone else's server logs it looks like scanning, and depending on where you are, running it against infrastructure you do not own or have permission to test may be unlawful.

Use it on sites you are launching or maintaining. That is what the tool is for.

Please do not open a public issue for a security problem.

Use GitHub's private vulnerability reporting, which is enabled on this repository: Report a vulnerability. The report stays private between you and the maintainer until a fix is published.

Please include what you found, how to reproduce it, and what an attacker could achieve. You can expect an acknowledgement within a few days.

This project is at 1.0.0. Fixes land on the default branch; there are no maintained release branches yet.