An API is a defined software interface that lets applications or services expose data and functionality to other software. APIs power web and mobile applications, IoT integrations, automation, and service-to-service communication. Each API opens a controlled door into a system: useful when protected, dangerous when access is poorly designed or implemented. section 1.0
Because APIs provide access to data and operations, attackers can exploit weak authentication, authorization, rate limiting, or monitoring. Consequences include data theft, privacy violations, unwanted operations, service disruption, content scraping, business-model abuse, and regulatory sanctions. Treating API security as a design and operational concern reduces both technical and business risk. section 1.0 section 1.3
Secure API design and operation should make exposure deliberate and observable:
- Treat internal APIs as public APIs, especially when they handle sensitive data or receive weaker protection. section 9.2
- Place public APIs behind an API gateway or reverse proxy so access controls, visibility, and other protections apply at the entry point. section 9.2
- Keep services in private subnets and expose endpoints through explicit gateway declarations; use a hardened bastion server for necessary internal access. section 9.2
- Review authorization, rate limiting, monitoring, endpoint exposure, and compliance requirements before placing an API in production. section 1.3 section 9.2
Public and private API exposure
A public API can accept internet traffic through a DMZ and reverse proxy, forwarding approved requests to services on an internal network. A private API can remain in a private subnet, reachable externally only through a hardened bastion server. Declaring public endpoints through the gateway keeps the internet-facing attack surface visible while retaining internal endpoints for testing or back-office use. section 9.2
Figure 9.12 Using a combination of API gateway and bastion server, we make sure that our APIs expose only well-documented, tested, secure endpoints to the internet while keeping internal endpoints or endpoints in development accessible only by internal users and developers.
Use the topology figure to compare documented, tested public endpoints with internal or development endpoints restricted to internal users and developers. section 9.2
