Model the API’s identities, objects, and actions
Document who and what calls the API: end users, browser applications, mobile clients, internal services, partners, administrators, and webhooks may need different credentials and permissions. Authentication establishes an identity. Authorization must still decide whether that identity can perform this action on this specific object and field.
Test horizontal access between users or tenants and vertical access between roles. Do not rely on identifiers being difficult to guess. Centralize permission policy where practical and apply it consistently to list, read, create, update, delete, export, search, and batch operations.
Validate protocols and data strictly
Accept only expected methods and content types. Validate path parameters, query values, headers, and request bodies against explicit schemas, including sizes, formats, nesting, and unknown fields. Return a controlled error model without stack traces, query details, secrets, or internal hostnames.
Use parameterized database access and context-appropriate output encoding. If the API accepts URLs, file references, templates, filters, or expressions, treat each as a distinct high-risk input. Restrict outbound destinations to prevent server-side request forgery and block cloud metadata and private-network ranges where they are not needed.
The OWASP REST security guidance provides a useful baseline for HTTPS, access control, validation, tokens, methods, content types, and management endpoints.
Design tokens and sessions for their clients
Use established identity protocols and maintained libraries. Validate token issuer, audience, signature algorithm, expiry, and relevant claims. Keep access tokens short-lived and create a revocation or session-disable strategy appropriate to the risk. Never accept an unsigned token or select a verification key solely from an untrusted header without constraints.
Browser clients need careful cookie, CSRF, CORS, and token-storage decisions. CORS only controls which browser origins can read a response; it is not authentication and does not protect a server from direct requests. Native and public clients cannot safely hold a permanent client secret.
Bound cost and abuse
Set request, upload, response, pagination, concurrency, and execution-time limits. Apply rate controls by a useful combination of identity, operation, tenant, and network signal. Return a bounded number of records and protect exports, search, reports, AI operations, and password recovery separately.
For GraphQL, authorize each resolved object and sensitive field. Restrict query depth, complexity, aliases, and batch behaviour based on measured cost. Decide whether production introspection fits the use case; turning it off does not fix weak authorization. Avoid returning fields merely because they exist in the backend model.
Secure webhooks and integrations
Verify webhook signatures using the provider’s exact canonicalization rules and the raw request body. Check timestamps or replay identifiers where available, use constant-time comparison, store secrets per environment, and rotate them safely. Handlers should be idempotent and prepared for duplicates and out-of-order delivery.
Use TLS for every external and internal hop where sensitive data or credentials travel. For high-trust service communication, consider mutual TLS or workload identity. Give each integration its own credentials so it can be limited, monitored, rotated, and revoked without affecting others.
Make the API observable without leaking data
Log authentication outcomes, authorization denials, administrative activity, token changes, rate-limit events, schema failures, and unusual request patterns. Include a correlation identifier, but redact credentials and minimize personal or regulated data. Protect management, metrics, debugging, and documentation endpoints separately from public APIs.
Maintain an API inventory with owners, data classifications, clients, versions, and retirement dates. Removing an old route from documentation does not decommission it. Test incident procedures for credential compromise, excessive data exposure, abusive clients, and vulnerable dependencies.
API security review checklist
- Every route, object, field, and operation has an explicit authorization decision.
- Inputs, content types, files, filters, and outbound destinations are constrained.
- Tokens, cookies, CSRF, CORS, and service identities match the client architecture.
- Request cost, query complexity, pagination, rates, and concurrency are bounded.
- Webhooks are signed, replay-aware, idempotent, and independently revocable.
- Logs are useful but exclude tokens, secrets, and unnecessary personal data.
- Versions, clients, credentials, dependencies, and retirement dates are inventoried.
