A company exposes a public REST API from its cloud platform. A review finds that the API applies no request throttling and passes caller-supplied parameters directly to back-end services without any checks. Which set of controls best addresses these findings?

Securing an API combines several controls applied to every request. Authentication establishes who the caller is, authorization decides what that caller may do, rate limiting and quotas cap how many requests a client can make in a period to prevent abuse, brute force and resource exhaustion, and input validation checks parameters against an expected schema for type, length, format and range before anything is passed to back-end services. These address both findings directly: unlimited request volume and unchecked input. They are commonly enforced at an API gateway and repeated in the service itself. TLS and certificate pinning protect traffic confidentiality and integrity and make interception harder, but an attacker sending malicious or high-volume requests over a perfectly valid TLS session is unaffected. Moving the API into a private subnet contradicts its purpose as a public API, and limiting documentation is security through obscurity; attackers discover endpoints by observing clients. Logging to a SIEM with weekly review provides detection after the fact, which is useful, but it neither prevents the abuse nor validates input, and a week is far too slow for an attack in progress. Exam caveat: the OWASP API Security Top 10 includes unrestricted resource consumption, so throttling is a security control, not only a performance setting. Operational check: send oversized, malformed and high-rate requests in testing and confirm the API rejects them with appropriate errors.