Secure the decisions behind every API call—not just the endpoint.

Threat-model the business capability, data, and trust boundaries before selecting controls.

Start with an inventory of what the API lets a caller do. Document the caller types, identities, tenant boundaries, objects, sensitive properties, state-changing actions, external dependencies, privileged administration paths, asynchronous jobs, webhooks, and machine-to-machine flows. Then identify which operations would be damaging if a valid user invoked them against the wrong object, too many times, in the wrong sequence, or with data the caller should never be able to set.

This design view prevents a common failure: treating authentication as if it answers authorization. A perfectly validated token proves something about the caller, but it does not prove that the caller may read object 4812, update another tenant’s billing address, approve its own transaction, enumerate restricted fields, or execute an administrative function. Build a decision model that can answer those questions consistently and can be tested independently from route wiring.

Record security assumptions in the API contract and architecture decision records. Include required scopes or claims, ownership rules, property-level restrictions, idempotency expectations, rate or cost controls, allowed content types, maximum request sizes, trust rules for callback destinations, and the behavior of deprecated versions. These are testable requirements, not implementation trivia.

Treat data from callers and other APIs as untrusted across every trust boundary.

Validate input against an explicit schema before business processing. Enforce expected content types, types, ranges, lengths, formats, enumeration values, and structural limits. Reject unknown or forbidden fields when the contract permits. Parameterized data access and context-appropriate output encoding remain necessary, but API security also depends on validating semantic rules such as allowed identifiers, ownership transitions, file types, and business constraints.

Server-Side Request Forgery deserves architectural controls when callers can influence URLs, webhooks, import locations, image fetches, proxy destinations, or cloud-resource references. Prefer allowlisted destinations or service identities over generic URL fetch capability. Resolve and validate destinations carefully, restrict egress at the network layer, block access to instance metadata and internal administration ranges, control redirects, and re-check the effective destination after resolution rather than trusting a string prefix.

Unsafe consumption of APIs means upstream responses need the same skepticism as direct user input. Set timeouts and size limits, validate schemas, verify TLS and expected identity, constrain redirects, sanitize data before it reaches interpreters or templates, and avoid automatically trusting an upstream service merely because it belongs to a known vendor. Record which external APIs can influence authorization, pricing, identity, or other high-consequence decisions and define fallback behavior when their responses are missing, stale, malformed, or compromised.

NIST SSDF 1.1 provides the stable secure-development baseline for integrating security practices across the software lifecycle. Apply it to API code, infrastructure definitions, gateway policies, schemas, generated clients, migration logic, and deployment automation—not just the primary application repository. The release record should connect requirements and threat decisions to source revision, review, tests, dependency state, build identity, artifact digest, approval, and deployment result.

SLSA 1.2 provides current supply-chain language for improving guarantees in the Build and Source tracks. Use provenance to answer where an artifact came from and which build process produced it; use source-control protections and review evidence to strengthen confidence in the inputs. Select an appropriate SLSA level based on risk rather than marketing a generic “SLSA compliant” label that does not state the track, level, scope, or evidence.

Produce dependency and component evidence in formats your organization can actually retain and query. An SBOM can support investigation and vulnerability response, but it does not prove an artifact is secure and it should not replace source review, build provenance, vulnerability handling, or deployment verification. Preserve exact artifact identifiers so a later incident can determine which services were built from an affected component and which production deployments actually contain it.

Release gates should fail closed for high-consequence control failures and use explicit, expiring exceptions for anything intentionally waived. Every exception should identify scope, rationale, compensating control, risk owner, approver, expiry, and closure condition. Repeated exceptions are signal: they may indicate a control that is badly placed, a dependency that needs replacement, or a delivery architecture that cannot meet the intended security requirement.

Instrument enough context to detect abuse and reconstruct consequential API activity.

Log authentication outcomes, authorization denials, privileged actions, object-access patterns, administrative changes, throttling, validation failures, dependency errors, and security-policy decisions at a level appropriate to the service. Include stable request or trace identifiers, actor and client identity where lawful, target object or resource context, result, and trustworthy time. Avoid logging bearer tokens, secrets, raw credentials, or sensitive payload fields simply because they are convenient for debugging.

Build alerts around behavior and consequence rather than raw status-code volume. Useful signals include sudden cross-tenant authorization denials, enumeration patterns, bursts against sensitive business flows, repeated token replay indicators, unusual export volume, spikes in expensive operations, requests to prohibited egress destinations, use of deprecated API versions, and administrative actions from unusual identities or networks. Tie each alert to an owner and an investigation path.

Prepare API-specific incident actions before an event: revoke a client, rotate credentials and signing keys, block an abused route, reduce quota, disable a feature, isolate a dependency, invalidate sessions, restore a previous release, or retire a compromised integration. Exercise those actions in a non-production environment and confirm that responders can identify affected API versions and deployed artifacts from retained evidence.

A 30-day API security reset

1. Week 1

   Reconcile the production API inventory against gateways, DNS, service discovery, cloud endpoints, and observed traffic. Identify unknown versions, owners, and exposures first.

2. Week 2

   Select the highest-consequence APIs and test object, property, function, and workflow authorization using negative cases across roles and tenants. Fix systemic policy gaps rather than only individual routes.

3. Week 3

   Add resource-consumption, sensitive-business-flow, SSRF, upstream-response, and dependency-failure tests. Confirm rate, size, timeout, retry, egress, and idempotency controls behave under stress.

4. Week 4

   Reconstruct one real production release from source through artifact and deployment. Close evidence gaps, verify runtime telemetry, and assign retirement dates to unsupported API versions.

Primary sources

• OWASP Application Security Verification Standard — stable ASVS 5.0.0
• OWASP API Security Top 10 — 2023 edition
• NIST SP 800-218 — Secure Software Development Framework Version 1.1
• SLSA specification Version 1.2
• RFC 9700 — Best Current Practice for OAuth 2.0 Security
• OWASP REST Security Cheat Sheet
• CISA Secure by Design
• IETF OAuth 2.1 working-group Internet-Draft — work in progress
• NIST SP 800-218 Rev. 1 / SSDF 1.2 — initial public draft

The guide is an implementation aid, not a claim that any specific API or organization conforms to a standard or legal requirement. Apply contractual, regulatory, sector, and risk requirements to the actual system scope.