A production-ready API security checklist covering inventory, object- and function-level authorization, OAuth, input and output controls, rate limits, SSRF, third-party APIs, observability, testing, release evidence, and incident readiness.
A production-ready API security checklist covering inventory, object- and function-level authorization, OAuth, input and output controls, rate limits, SSRF, third-party APIs, observability, testing, release evidence, and incident readiness.
By Rusaka Research · Published 2026-07-27 · Updated 2026-10-07 · 3737 words
Use this API security checklist before releasing a new API, materially changing an existing endpoint, onboarding a partner, or exposing a previously internal service. It is designed to produce reviewable evidence, not a ceremonial yes-or-no form. Each check needs an owner, an evidence link, the tested environment and version, a result, any exception, and an expiry or review date. A control that exists only in a policy or gateway configuration is not complete until the team has verified its behaviour at the protected endpoint.
The checklist follows the risk themes in the OWASP API Security Top 10 2023 and current primary standards. It distinguishes authentication from authorization, checks access at object, property, and function level, treats resource consumption and sensitive business flows as abuse cases, and covers server-side request forgery, configuration, inventory, and unsafe third-party API consumption. OAuth deployments should be reviewed against RFC 9700 rather than relying on older defaults. OpenAPI descriptions, automated tests, gateway controls, application code, logs, runbooks, and incident exercises should tell the same story.
No universal checklist can prove an API secure. Adapt the controls to the data, users, threat model, architecture, regulatory obligations, and consequence of failure. High-risk or regulated APIs require qualified application-security, identity, privacy, legal, infrastructure, and domain review. Record excluded checks explicitly; do not silently mark them not applicable.
API defects frequently cross trust boundaries that ordinary happy-path tests do not exercise. A user may be authenticated yet still read another tenant object by changing an identifier, update a protected property the interface never exposes, invoke an administrator function, exhaust an expensive operation, or trigger a server-side request to an internal destination. These failures arise when teams treat login, an API gateway, or a successful scanner run as complete security coverage.
Coverage also decays. Undocumented versions remain reachable, shadow endpoints bypass normal review, machine credentials outlive their owners, schema changes expose new fields, and third-party responses are trusted more than user input. Logs can contain tokens or personal data while still lacking the subject, client, decision, correlation identifier, and outcome required to investigate abuse. A release can therefore pass functional testing but remain difficult to constrain, observe, or recover.
The practical remedy is a control chain from inventory and threat model through implementation, negative testing, deployment configuration, monitoring, incident response, and retirement. Every consequential claim should have reproducible evidence from the deployed path. Exceptions need a risk owner, compensating control, deadline, and retest condition.
APIs concentrate business capabilities and data into machine-accessible interfaces. One authorization defect can scale across many objects; one unbounded endpoint can create availability or cost impact; one stale credential can give persistent access without an interactive warning. The same automation that makes APIs valuable also makes weaknesses repeatable.
A strong checklist improves release decisions and operational response. Engineering can see which boundary is enforced where, security can reproduce the test, product can identify sensitive business flows, operations can detect abnormal use, and leadership can understand accepted residual risk. The result is not a promise of zero vulnerability. It is traceable evidence that material risks were identified, controlled, tested, monitored, and assigned.
Maintain a discoverable inventory of hosts, base paths, versions, protocols, environments, exposure, data classification, authentication method, business owner, technical owner, and retirement status. Reconcile specifications, gateways, service meshes, DNS, code repositories, traffic logs, and cloud inventories to find shadow or forgotten APIs. Every reachable production endpoint must map to a maintained specification and owner. Deprecated versions need a dated migration and shutdown plan rather than an indefinite warning banner.
Identify every human, machine, workload, partner, and administrator authentication flow. Verify issuer, audience, signature, algorithm, time claims, nonce or state where applicable, token type, scope, rotation, revocation, storage, and transport. Reject weak or ambiguous token validation. OAuth authorization-code deployments should use PKCE, exact redirect URI matching, and current flow guidance from RFC 9700. Do not place bearer tokens, API keys, or secrets in URLs, client-side logs, analytics, repositories, or support tickets.
Enforce authorization in trusted server-side code for every request and every object reference. Test horizontal access between users and tenants, vertical access between roles, and ownership transitions. Allow-list writable and readable properties so clients cannot mass-assign protected fields or receive unnecessary sensitive attributes. Apply authorization to functions, background jobs, bulk endpoints, exports, GraphQL resolvers, webhooks, and alternate versions; hiding a control in the interface is not authorization.
Validate request method, media type, size, shape, type, range, format, enum, nesting, and relationship against an explicit schema. Reject unknown fields where the compatibility model allows it and normalise only with documented rules. Parameterise data access, encode output for its destination, constrain file handling, and prevent verbose errors from exposing internals. Apply a response allow-list and data-minimisation review so new database or domain fields do not appear automatically in API responses.
Set bounded request, response, upload, pagination, query complexity, batch size, concurrency, execution time, retry, and downstream fan-out limits. Use quotas and rate limits by the identities and resources that matter, not only source IP. Identify business flows that create disproportionate harm when automated, such as signup, reservation, purchase, invitation, password reset, promotion, search, export, or expensive AI inference. Add velocity, inventory, entitlement, proof-of-work, step-up, or review controls appropriate to the abuse case.
Treat URLs, webhook destinations, redirects, file locations, and third-party API responses as untrusted. For outbound requests, allow-list schemes and destinations where feasible, resolve and validate addresses, block private and link-local ranges, constrain redirects, apply egress policy, and isolate metadata services to reduce SSRF exposure. Authenticate third parties, validate their schemas, set timeouts and circuit breakers, limit privileges, verify webhook signatures with replay protection, and avoid propagating their errors or data directly into trusted actions.
Use supported TLS configurations end to end, including internal hops where the threat model requires them. Apply secure headers and cross-origin policy deliberately rather than using permissive wildcards by default. Disable debug interfaces, sample credentials, unused methods, directory listings, verbose stack traces, and unneeded gateway plugins. Store secrets in an approved manager, scope them narrowly, rotate them, audit access, and prove that build logs, client bundles, images, and infrastructure state do not contain them.
Record security-relevant events with a timestamp, request or trace identifier, authenticated subject, client, tenant, endpoint, authorization outcome, status, latency, and policy decision while excluding tokens and unnecessary sensitive payloads. Detect authentication failures, authorization denials, enumeration, unusual object access, schema violations, rate-limit events, credential misuse, administrative changes, and unexpected data volume. Route alerts to an owned response process and test containment, key rotation, token revocation, evidence preservation, customer communication, and recovery.
Record the API name, production hosts, base paths, protocols, current and deprecated versions, environments, exposure, owners, consumers, data classifications, critical business actions, downstream systems, availability objective, and recovery requirement. Reconcile the declared inventory with observed traffic and deployed infrastructure. Define the release or change being reviewed and the evidence cutoff. List reachable assets that cannot yet be attributed instead of excluding them from the assessment.
Required output: dated API inventory, ownership register, data-flow diagram, version and retirement register, consumer list, exposure classification, and unresolved-asset log.
Map trust boundaries, identities, credentials, objects, properties, functions, sensitive business flows, outbound calls, administrative routes, asynchronous work, and tenant boundaries. For each endpoint, define who may perform which action on which resource under what condition. Add misuse cases for identifier substitution, role escalation, mass assignment, excessive data exposure, replay, enumeration, expensive queries, automation, SSRF, unsafe third-party data, and stale versions. Prioritise by consequence and exposure.
Required output: versioned threat model, endpoint authorization matrix, object and property rules, abuse-case catalogue, risk ratings, and named control owners.
Configure authentication and token validation with exact issuer and audience expectations, approved algorithms, bounded lifetimes, rotation, revocation, and current OAuth protections where used. Enforce authorization in the service for every object and function. Bind requests and responses to explicit schemas, allow-list fields, parameterise data access, limit resource use, restrict outbound destinations, protect secrets, remove unsafe defaults, and use least-privilege service identities. Keep gateway and application policy aligned but do not assume one substitutes for the other.
Required output: configuration references, policy and code review, schema versions, credential lifecycle evidence, rate and resource limits, egress policy, secrets scan, and exception register.
Automate positive contract tests and negative tests for missing, invalid, expired, replayed, wrong-audience, wrong-issuer, and insufficient-scope credentials. Test cross-user and cross-tenant object access, protected properties, role boundaries, bulk and export paths, unknown fields, malformed and oversized inputs, pagination limits, query complexity, concurrency, retries, SSRF destinations, redirects, webhook replay, third-party schema failures, and error disclosure. Run tests against an environment that matches production controls and independently verify the deployed path.
Required output: reproducible test suite and results, tested build and environment identifiers, vulnerability findings, remediation evidence, residual exceptions, and security release decision.
Confirm that production telemetry records actionable identity, endpoint, authorization, rate-limit, error, and policy events without secrets or unnecessary personal data. Establish baselines and alerts for abuse cases. Exercise credential compromise, authorization failure, data exposure, denial-of-service, third-party failure, and rogue-version scenarios. Verify contact paths, containment, token and key rotation, consumer notification, evidence preservation, recovery, and post-incident review. Set review and retirement dates for versions, exceptions, credentials, and dependencies.
Required output: logging sample, detection rules, alert ownership, response runbook, exercise record, credential-rotation proof, recovery evidence, exception expiries, and version retirement plan.
A software company is releasing endpoints that let customers list invoices, view one invoice, upload evidence, approve a payment, and register a webhook. The initial implementation authenticates users and checks that they have an approver role. The threat review shows that invoice identifiers are globally unique, the object lookup does not also constrain tenant ownership, the update model accepts an internal approval-limit field, and webhook validation follows redirects to any HTTPS host. These are different control failures: object-level authorization, property-level authorization, and outbound-request trust.
The team changes data access so every invoice query binds the authenticated tenant and permitted account, allow-lists mutable properties, and evaluates the approval amount against server-side entitlements. It constrains webhook destinations, blocks private and link-local addresses, revalidates after DNS resolution and redirects, signs delivery payloads, limits retries, and records replay identifiers. OAuth clients use exact registered redirect URIs and PKCE according to the deployment profile; tokens are checked for issuer, audience, time, and scope.
Tests use two tenants, multiple roles, predictable and random identifiers, bulk requests, expired and wrong-audience tokens, protected fields, oversized files, concurrent approvals, webhook replay, redirect chains, and private-address targets. Production telemetry records the subject, tenant, client, invoice, action, decision, trace, and outcome but never logs the token or document body. The release is approved only after the deployed-path tests pass and one temporary exception has a compensating control, owner, expiry date, and scheduled retest.
Generate tests from subject, tenant, role, object state, action, property, and endpoint version. Include expected denials and verify that denial does not disclose object existence or data.
Use the maintained OpenAPI or equivalent schema in validation, contract tests, documentation, change review, and inventory. Detect drift between the declared contract and observed production traffic.
Scope users, clients, workloads, gateways, queues, databases, object stores, and third-party credentials to the smallest required capabilities and data. Review inherited and transitive privilege.
Define maximum sizes, depths, fields, pages, batches, complexity, concurrency, duration, retries, and downstream fan-out. Test behaviour at, below, and above every boundary.
Treat API keys and bearer tokens as secrets, rotate and revoke them, and never use them as durable public identifiers. Prefer short-lived and sender-constrained credentials where the architecture supports them.
Confirm the actual DNS, CDN, gateway, service, identity, egress, storage, and logging path after deployment. A passing local test or configuration review is not production evidence.
Give exceptions a risk statement, affected endpoints and data, compensating controls, accountable approver, deadline, monitoring, and retest. Reapproval should require fresh evidence.
Return minimal consistent errors, fail closed for authorization and validation, bound retries, avoid cascading load, protect idempotency, and provide operators with correlation evidence unavailable to unauthorised clients.
A valid identity does not prove access to a requested object, property, or function. Evaluate permission against the specific resource and action on every request.
Gateways can authenticate, limit, and route traffic, but application context often determines ownership and business permission. Enforce and test controls at the correct decision point.
Old versions, alternate hosts, debug paths, mobile backends, partner endpoints, GraphQL operations, and asynchronous consumers may remain reachable. Reconcile documentation with deployed assets and traffic.
A request rate can be legitimate yet still exhaust an expensive query or automate a sensitive workflow. Limit cost and business impact by identity, resource, operation, and state.
Partner data can be malformed, malicious, stale, excessive, or compromised. Authenticate the source, validate the response, constrain privileges, and handle failure without promoting untrusted data into commands.
Verbose telemetry can become a second data breach. Log the minimum fields needed to detect and investigate decisions; redact secrets and sensitive content before it reaches shared systems.
Automated tools help discover classes of defects but rarely understand tenant ownership, entitlement, business flow, operational context, or every deployment path. Combine automation with targeted review and negative tests.
A documented new version does not remove risk from the old one. Measure consumers, communicate deadlines, block new adoption, migrate dependencies, monitor residual traffic, and shut the version down.
Convert the endpoint authorization matrix into generated or table-driven tests. Each row should identify subject class, tenant, role, object owner, object state, action, protected properties, contextual conditions, and expected result. Include invalid relationships and transitions, not only wrong identifiers.
Keep denial evidence. A test should verify the status and response body, absence of protected data, absence of state change, audit event, and lack of side effects in queues, notifications, exports, or downstream systems. This catches partial failures where the client receives a denial after work has already occurred.
Jobs, integrations, agents, devices, and partner systems need owners, narrow permissions, credential expiry, rotation, revocation, workload identity where possible, and a monitored usage profile. A shared permanent API key hides accountability and makes safe revocation difficult.
Record which client is allowed to call which endpoint for which purpose and data. Detect a client using new operations, regions, volumes, tenants, or time patterns. Plan how that client continues or fails safely during credential rotation and dependency outages.
Old API versions preserve old schemas, dependencies, authorization assumptions, and client credentials. A deprecation notice without traffic measurement and a shutdown date is inventory growth, not risk reduction.
Block new consumers, publish migration evidence, contact active owners, monitor residual calls, define an emergency extension process, and remove routing, code, credentials, documentation, monitoring, and data access when the version closes. Verify that alternate hosts or caches do not keep it reachable.
An API is ready for a security decision when its reachable surface and owners are known, authorization is explicit at object, property, and function level, credentials and inputs are constrained, costly and sensitive flows resist abuse, outbound and third-party trust is limited, and the deployed path produces reproducible test and monitoring evidence.
Use the downloadable workbook as the release record. Attach evidence rather than relying on unchecked assertions, preserve failed tests and exceptions, and repeat the review after material changes to identity, schema, exposure, infrastructure, consumers, dependencies, data, business flows, or threat conditions.
At minimum, include inventory and ownership, threat modelling, authentication, object-, property-, and function-level authorization, schema validation, output minimisation, resource limits, sensitive business-flow abuse, SSRF and egress, third-party trust, TLS and configuration, secrets, dependencies, logging, negative testing, incident response, exceptions, and version retirement.
No. A gateway can enforce useful identity, routing, schema, quota, and network controls, but it may not know object ownership, tenant membership, record state, protected properties, or business permission. Application and data-access controls must enforce those decisions and be tested through the deployed path.
Create at least two isolated users or tenants and objects owned by each. For every read, update, delete, export, and nested-object path, replace identifiers and relationship values while keeping a valid credential. Expect a safe denial or non-disclosing not-found result, then verify no data or state changed. Repeat for bulk, indirect, predictable, and alternate-version identifiers.
Verify exact redirect URI matching, PKCE for authorization-code flows, state or nonce where applicable, issuer and audience validation, approved algorithms, bounded token lifetimes, secure client authentication, scope and resource restriction, refresh-token protection and rotation, revocation, replay controls, metadata, TLS, and rejection of deprecated or insecure flows according to RFC 9700 and the deployment profile.
Review before initial production exposure and every material change. Reassess after changes to schemas, authorization, identity providers, gateway or infrastructure configuration, third parties, data classification, clients, versions, dependencies, or business flows; after incidents or new relevant threats; and at the documented periodic review date.
No. Scanners provide useful evidence for detectable classes of weakness but usually cannot prove tenant isolation, business entitlements, property rules, sensitive-flow abuse resistance, operational ownership, or every deployment path. Combine automated analysis with threat-led code review, negative integration tests, configuration inspection, and authorised manual assessment.
Submit an email to download the API Security Checklist implementation workbook