An API, or application programming interface, is a defined set of rules that lets one system request data or actions from another system. It establishes how clients format requests, what endpoints they can call, and what responses they receive. APIs are the standard pattern for controlled, programmatic access between applications.
Expanded Definition
An API is more than a technical shortcut between applications. It is a contract that defines what a client may request, how the request must be shaped, and what the service will return. In practice, that contract often includes authentication, authorization, throttling, validation, versioning, and error handling, even when the definition itself is framed as simple request and response rules.
The boundary that matters is control. A well-designed API exposes only the functions and data that another system genuinely needs, while keeping internal implementation details hidden. That makes APIs distinct from raw database access, ad hoc scripting, or direct administrative access. They are also distinct from SDKs, which are developer convenience layers built on top of an API rather than the interface itself.
API usage is still uneven across organisations. Some teams treat APIs as product surfaces with lifecycle ownership, while others treat them as incidental plumbing. That difference matters because security, reliability, and governance expectations change as soon as an API becomes a business interface rather than a local integration detail. The OWASP API Security Top 10 is a useful authority for understanding the security issues that appear when API design and access control are weak, especially for exposed endpoints.
Examples and Use Cases
APIs show up wherever software needs to exchange data or invoke actions in a controlled way. Common examples include internal services, third-party integrations, mobile backends, payment gateways, and automation hooks.
- A mobile app calls an account API to fetch profile data and submit updates without exposing backend systems directly.
- An e-commerce platform exposes inventory and order APIs so checkout, fulfillment, and analytics systems can share state.
- A SaaS product provides a partner API so customers can automate provisioning, reporting, or ticket creation.
- A cloud service uses an administrative API for policy changes, but that interface must be tightly restricted because it can alter high-value resources.
- An internal engineering platform publishes deployment APIs so CI/CD workflows can trigger builds, releases, and rollback actions.
One common trade-off is convenience versus exposure. The more an API is designed for broad automation or external integration, the more important it becomes to define narrow scopes, strict input validation, and clear ownership. The OWASP Web Security Testing Guide is a useful companion when teams need a structured way to examine API endpoints alongside the web application surface that exposes them.
Security Implications
APIs become security-sensitive because they are direct execution paths, not just read-only data feeds. If an API is poorly designed, the result is often broken authorisation, overexposed data, excessive functional reach, or unintended automation of sensitive actions. In a mature environment, the API boundary is where policy is enforced, not where trust is assumed.
Mismanagement usually shows up as weak object-level access control, excessive endpoint discovery, undocumented functions, inconsistent authentication, or hidden administrative methods left reachable in production. These failures can turn a single token, session, or integration key into broad application access. They can also create operational symptoms such as unexplained traffic spikes, repeated rejected calls, or data returned outside the intended tenant or user context.
Failure mechanism: the service trusts the caller too much, validates too little, or exposes more functionality than the client should receive. That can allow unauthorized reads, writes, or state changes even when the API itself appears stable and functional.
Impact: data leakage, account takeover paths, service abuse, integrity loss, and hard-to-detect lateral movement across connected systems. Where APIs control privileged operations, the blast radius can extend well beyond the interface itself.
Security, Operational and Governance Implications
API governance is about deciding who may publish, discover, consume, change, and retire interfaces. Without that discipline, organisations accumulate shadow APIs, orphaned endpoints, inconsistent authentication patterns, and brittle integrations that are hard to inventory or secure. The security problem is not only access control, it is lifecycle control.
Operationally, API reliability and security are linked. Rate limits, schema validation, versioning, logging, and deprecation policies all affect whether consumers can use the interface safely over time. If those controls are weak, teams often respond by hard-coding exceptions, which increases coupling and makes later remediation harder.
For teams that already manage secrets, service accounts, or machine-to-machine credentials, the API surface is where those controls become visible. If you can’t answer which applications are calling which endpoints and under what authority, you do not really know what the API is doing in production. A practical governance model therefore treats API ownership, access review, and change control as part of the same control plane, not separate tasks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | APIs depend on enforced access decisions for callers, scopes, and privileged actions. |
| Recommendation — Apply access control to each API operation and limit caller privileges to the minimum needed. | ||
| CIS Controls v8 | 6 — Access Control Management | API access must be governed through account, entitlement, and privilege management. |
| Recommendation — Review and revoke API access regularly, and remove stale or excessive permissions. | ||
