Forgotten API routes: the endpoints your app still serves

Ask an agent to change how user profiles load and it may write /api/v2/profile alongside the old /api/profile rather than edit it in place. Ask it to add seed data for testing and it may add /api/debug/seed. Each step works, the interface moves on, and nothing removes what it left behind.

Over a few weeks of iteration, the set of routes the server answers drifts away from the set the interface calls. OWASP calls this improper inventory management: you cannot secure endpoints you do not know you have.

• They miss later fixes. When you add an ownership check to the new route, the old one keeps returning everything.
• They were often written for convenience: test helpers, admin shortcuts, and seed endpoints with no authentication.
• Nobody looks at them. They do not appear in the interface, in recent diffs, or in manual testing.

1. Record every request the interface makes while you click through each screen. That is your known inventory.
2. List the routes your server actually defines, from the framework's route table or file tree.
3. Anything in the second list but not the first is a candidate. Decide whether to delete it or protect it.
4. Probe the production host for common leftovers such as /debug, /admin, /.env, /actuator, /swagger.json, and /graphql.

curl -s -o /dev/null -w "%{http_code}  /debug\n" https://your-app.example/debug
curl -s -o /dev/null -w "%{http_code}  /.env\n"  https://your-app.example/.env

Routelint's API catalog is the traffic-based inventory from step one. Its sensitive paths suite runs the probe from step four. Every captured route is then replayed with no session and as a peer, so an old route that skipped the new auth check shows up as a finding.