A city's public APIs must validate caller tokens, throttle abusive clients, and avoid error messages that reveal internal stack traces. Which set of practices does this describe?
Select an answer to reveal the explanation.
Short Explanation
Treat the API like a busy city counter: check badges (tokens), do not let one person hog the line (rate limits), and do not announce the filing-cabinet combination when something breaks. That trio is basic API security hygiene. Dumping stack traces and connection strings is how internals leak.
Full Explanation
API security practices for public municipal APIs include validating caller tokens, rate limiting or throttling abusive clients, and returning non-verbose errors that do not leak internal stack traces. Those controls collectively protect a city’s public APIs against unauthorized use, abuse, and information disclosure while keeping citizen integrations usable.
Publishing unrestricted anonymous write APIs with detailed exception dumps maximizes risk. Disabling authentication so load tests never receive 401s abandons access control. Returning full database connection strings in every HTTP 500 body is a severe disclosure anti-pattern.
Exam caveat: API gateways often centralize authn/z, throttling, and error shaping; app code must still avoid verbose errors. Token validation implies signature/issuer/audience/expiry checks at a conceptual level.
Operational check: enforce auth on write/sensitive reads, configure rate limits with alerts, standardize error responses without stack traces, and run abuse tests in non-prod. Review gateway logs weekly for anomalous clients targeting civic APIs.
Publish a short API error standard for city developers (stable error codes, no stack traces, correlation IDs) and verify gateways strip verbose upstream exceptions before responses reach the Internet.