The city publishes a public API for street-closure data used by third-party apps. Which controls are essential?
Select an answer to reveal the explanation.
Short Explanation
A public street-closure API is still a door into city systems—lock it, check IDs, and don't let bots knock a million times a minute. Authn/z, rate limits, and input checks are the basics. Open data is not the same as open season.
Full Explanation
A public API for street-closure data used by third-party apps still needs authentication and authorization appropriate to sensitivity, rate limiting to curb abuse and denial-of-wallet/availability attacks, and input validation to stop injection and malformed payloads. Even read-oriented civic APIs can expose operational patterns, enable scraping that harms availability, or become a pivot if write or admin functions are accidentally exposed. Essential API controls protect the municipality while still serving legitimate mobility and mapping consumers.
Leaving the API fully anonymous with unlimited request rates invites scraping floods, credential-stuffing against related endpoints, and resource exhaustion without accountability.
Embedding database admin credentials in client-side JavaScript hands production privileges to every mobile user and attacker who inspects the app—catastrophic for any API backend.
Disabling TLS so mobile apps can inspect plaintext exposes street-closure feeds and tokens to interception and tampering; demos should use controlled debugging proxies, not plaintext production paths.
Exam caveat: public APIs require standard application security controls—authN/Z, rate limits, validation, and TLS—not openness without guardrails. Operational check: issue API keys or OAuth clients per integrator, enforce quotas, validate parameters, centralize authZ for any non-public methods, mandate TLS, and monitor anomalous traffic against the street-closure endpoints.