A city’s public snowplow-location API accidentally shares the same exposure path as internal fleet-admin services. What access-control boundary should be applied?
Select an answer to reveal the explanation.
Short Explanation
Public plow dots on a map are a postcard; fleet-admin tools are the keys to the garage. Keep the public API read-only for location data and tuck admin services behind stronger auth and network walls. Hidden paths, shared CDN admin edges, and anonymous write admin access blur that line on purpose—and lose.
Full Explanation
Application and API access control must separate public, low-privilege citizen interfaces from privileged administrative functions. A public snowplow-location API should expose only read-only plow data needed for maps and traveler information, while fleet-admin services stay isolated behind stronger authentication, finer authorization, and network controls. That boundary keeps a postcard-style public feed from becoming a control plane for municipal fleet operations.
Exposing admin endpoints on the same public URL with a “hidden” path name is security through obscurity and still places privileged operations on an Internet-reachable surface. Binding admin APIs to the public CDN edge so plow maps and admin tools share one certificate co-locates high-privilege management with anonymous content delivery. Granting anonymous write access to admin services so updates “never need credentials” removes authorization entirely and invites unauthorized fleet or service manipulation.
Exam caveat: least privilege and service segmentation apply to APIs as much as to GUIs—public read ≠ admin write. Operational check: publish only scoped read-only plow APIs externally, place admin APIs on private or strongly authenticated paths with network isolation, remove obscure-but-public admin URLs, and verify anonymous clients cannot invoke management operations.