An API ships v1. Features are added in v2, with better security controls. v3 launches with breaking changes. At any given time, v1 and v2 remain live to avoid breaking existing integrations. Security patches are applied to v3 and v2 — but v1 is “deprecated” and nobody gets around to decommissioning it. v1 becomes the attacker’s entry point to bypass everything v2 and v3 introduced.

Examples: /api/v1/, /api/v2/, /api/v3/ — plus /api/legacy/, /api/old/, /api/2019/

Development, staging, and QA environments are necessary — but they should not be reachable from the internet. When they are, attackers find environments with: relaxed authentication (“it’s just staging”), real or realistic data, debug mode enabled, and no monitoring. Staging environments are often identical to production except for the security controls that “aren’t needed there.”

Examples: staging-api.company.com, dev.api.company.com, test.api.company.com, api-qa.company.com

Internal-only endpoints, test utilities, administrative shortcuts, and debugging routes that were added during development and never documented. Never documented means never reviewed, never secured, and never decommissioned. When discovered by attackers (through path fuzzing, source code exposure, or JavaScript file analysis), they have none of the security controls applied to documented endpoints.

Examples: /api/admin/internal, /api/debug/users, /api/test/reset, /api/v2/undocumented/bulk-export