Leftover test, seed, and debug API routes in production
Debug endpoints are API routes built for local development or testing, like seeding the database or sending a test email, that get committed and deployed alongside the real app without anyone deciding they should be public.
#What goes wrong
While building a feature, it's normal to ask your AI editor for a quick /api/seed or /api/test-email route to check that something works. It does its job locally and then stays in the repo, unprotected, because nobody circles back to remove it before shipping.
#Why it matters
Anyone who discovers one of these routes, often by guessing common names or finding them in a client-side bundle, can trigger whatever the route does. A seed route can wipe or overwrite real data. A test-email route can be used to spam or to burn through your email provider's quota.
#How Heimdall checks for this
Heimdall looks through your API routes for names that suggest a development or testing purpose, like seed, test, debug, or dev, and checks whether they're gated behind authentication or an environment check.
#How to fix it
Delete debug routes before shipping to production. If you need to keep one for staging, gate it behind both an admin-only check and a check that process.env.NODE_ENV isn't 'production' so it can't run in the live environment.
Frequently asked questions
Should I keep these routes for a staging environment?
What if the route name isn't obviously a debug route?
Is a route safe if I never documented it?
Run this check on your own repo
Heimdall scans your GitHub repo for this and 29 other issues in under a minute.