8 checks in this theme
Web hardening before you launch
Wide-open CORS, live debug endpoints, exposed .git, stack-trace leaks, HTTPS and HSTS — 8 checks to run before an AI-built app goes live.
The public surface is the attack surface
Once an app is deployed, strangers can probe it directly: a wildcard CORS policy, a debug endpoint that survived from development, a served /.git directory, stack traces with internal paths in 500 responses, no HTTPS redirect and no HSTS, cron and queue endpoints that answer to anyone, and paid API endpoints that never check entitlement.
Why AI tools generate it
Configuration files get filled with permissive defaults because permissive works on the first try. Debug routes shipped because they were useful at 2am. Security headers appear on no feature list. None of it is a bug in the generated feature code — it is the envelope around the code, and the envelope is what the live surface exposes.
How the scan detects it
A mix of repo checks (workflow files, config, route definitions) and read-only live probes: GET, HEAD, and OPTIONS only, capped at 25 requests per host, honestly identified, with no payloads and no authentication attempts. Anything that cannot be probed safely is checked from the repo side or skipped — never faked.
The 8 checks
FAQ
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
Check your app — free
10 Critical checks, no signup, results in about two minutes. Every finding is masked and carries a paste-ready fix prompt.
Run the free scan