A city API exposes predictable paths such as /v1/user/{id}. Beyond listing HTML pages, what should discovery planning emphasize?
Select an answer to reveal the explanation.
Short Explanation
Pretty HTML sitemaps will not show you every /v1/user/42 style door. APIs hide a lot of the real surface in parameters and path IDs. If you only hunt pages, you miss the IDOR neighborhood entirely.
Full Explanation
API endpoint and parameter discovery matters as much as classic HTML page discovery for IDOR-focused testing. When a city API exposes predictable paths such as /v1/user/{id}, planning must include finding endpoints and parameters that control object access—because authorization bugs often live in JSON APIs that never appear as pretty HTML pages for residents.
APIs absolutely can contain authorization bugs in JSON. REST path parameters are not merely cosmetic versus SOAP. Predictable IDs do not prove security by design; they often motivate IDOR testing.
Exam caveat: modern municipal apps are API-heavy—map OpenAPI/Swagger, mobile traffic, and JS-driven calls as first-class discovery. CPTS web judgment pairs discovery with access-control testing.
Operational check: inventory in-scope API routes and identifiers, test horizontal/vertical access on {id}-style resources with two civic roles, and document least-privilege failures without mass-exfiltrating citizen records. Automate IDOR regression tests on {id} routes in the city CI pipeline so object-level authorization does not regress after API refactors. Horizontal and vertical IDOR checks both belong on city case and user APIs with predictable identifiers.