API Security Checklist Before Launch

How to use this checklist before production

A pre-launch API security checklist should be an evidence-based release gate, not a list checked from memory. For every item, record the endpoint or flow, test identity, request, expected response, accountable owner and retest status.

Friday Works groups the checks around practical risks in web apps, mobile apps and integrations. The structure references the OWASP API Security Top 10 2023 and adds pre-runtime and runtime controls from NIST SP 800-228. It is a baseline for triage; payment, sensitive-data and multi-tenant systems still need a scope-specific assessment.

Before testing, freeze the host, version, endpoint, role, tenant, test-data and third-party inventory. Run active tests only on authorized assets and environments; do not use production for payloads that may modify data without a safe plan.

• ✓Name the owner and the person authorized to make the go/no-go decision.
• ✓Inventory hosts, versions, endpoints, webhooks and third-party APIs.
• ✓Prepare at least two accounts in separate tenants plus relevant user and administrative roles.
• ✓Use synthetic data, rollback controls and an agreed test boundary.
• ✓Attach evidence and a retest result before closing each release-gate item.

A useful checklist does not ask whether the API works; it makes the team prove that the API rejects the wrong requests correctly.

1. Authentication, tokens and sessions

The API must identify the user or workload correctly before processing any non-public operation. Test missing tokens, invalid signatures, expiry, wrong issuer or audience, cross-environment tokens and revoked tokens. Do not stop at a happy-path request with one valid credential.

Use an OAuth or OIDC flow appropriate for the client instead of inventing a custom login scheme. For JWTs, lock the accepted algorithms, validate required claims and never choose the algorithm solely from token-controlled data. API keys need minimum scope, rotation or expiry, and must not be embedded in downloadable client code.

Login, refresh, password-recovery, OTP and token-issuance endpoints need rate limits, abuse signals and responses that do not expose account existence. Authentication logs should support investigation without storing raw secrets or tokens.

• ✓Private endpoints return 401 for missing, invalid, expired or revoked credentials.
• ✓JWT validation covers signature, algorithm, expiry, issuer, audience and defined clock skew.
• ✓Refresh tokens rotate or can be revoked appropriately; logout meaningfully ends continued access.
• ✓Every API key has a scope, owner, creation record, status and rotate/revoke process.
• ✓No real token, secret or credential appears in URLs, logs, client bundles, mobile apps or repositories.

2. Object, property, function and tenant authorization

OWASP lists Broken Object Level Authorization first because API endpoints commonly accept a client-supplied ID. Authentication alone does not prove that the caller may read, change or delete the object. Every ID-based data access needs a server-side owner, tenant and policy check.

Create a role × action × object matrix and turn it into negative tests. Use account A against B's objects; call administrative routes as a normal user; alter tenant IDs, organization IDs, parent IDs, HTTP methods and sensitive fields. Responses must filter properties by permission, while requests must not mass-assign role, price, status or owner fields.

Random IDs and UUIDs are not authorization. They reduce trivial enumeration but do not replace a policy check on every request and object.

• ✓User A cannot read, update or delete user B's object by changing an ID.
• ✓Tenant A cannot reach tenant B through paths, queries, bodies, headers or nested objects.
• ✓A normal user cannot call administrative functions by knowing the route or changing the HTTP method.
• ✓Responses expose only fields needed and permitted for the caller.
• ✓Requests bind only allowed fields; role, owner, price, approval and status are server-controlled.
• ✓Policies cover batch, export, search, files, webhooks and GraphQL resolvers where applicable.

3. Input, output, resources and business flows

Validate schema, type, length, enum, format and cross-field relationships on the server. Bound body and file size, batch count, JSON or GraphQL depth, pagination and processing time. Error responses must not disclose stack traces, SQL, internal paths or infrastructure details.

Rate limiting is not merely requests per IP. Apply quotas by user, token, tenant, endpoint and real cost. A request that sends email, creates a report, calls AI, exports data or triggers SMS can consume very different paid resources. OWASP describes this as Unrestricted Resource Consumption.

Test sensitive business flows such as registration, reservations, coupon use, ordering, invitations, refunds and voting. An API can be technically correct yet economically exploitable at machine speed.

• ✓Schemas reject unknown fields, wrong types, excessive length, invalid enums and oversized payloads.
• ✓Pagination, batches, uploads, query depth, timeouts and downstream costs all have bounds.
• ✓Rate limits use the right identity and return a consistent signal for clients.
• ✓Paid flows such as email, SMS, AI, exports and payments have dedicated quotas and alerts.
• ✓User-controlled URLs are allowlisted or validated to reduce SSRF, including internal targets and unsafe redirects.
• ✓Errors do not leak secrets, tokens, stack traces, SQL, hostnames or internal structure.

4. Secrets, configuration, inventory and third parties

Secrets belong in an appropriate management system, receive least-privilege access and can rotate without source changes. Check CI/CD, environment variables, logs, backups, container images and configuration files. Removing a secret from current Git is insufficient if it ever appeared in history.

Maintain an inventory of hostname, environment, base path, version, owner, processed data, public/internal state and end-of-support date. Compare OpenAPI or GraphQL schemas with live routes to find shadow APIs, debug endpoints, old versions and publicly exposed staging hosts.

Third-party API data remains untrusted input. Verify TLS and webhook signatures where available; add timeouts, bounded retries, circuit breakers, schema validation and idempotency. An abnormal provider response must not collapse your own security boundary.

• ✓Secrets do not appear in source, clients, logs, URLs, tickets or build artifacts.
• ✓Every credential has an owner, minimum scope, rotate/revoke path and audit trail.
• ✓Production disables unnecessary debug, sample routes, directory listing and insecure defaults.
• ✓OpenAPI/schema, gateway and deployed routes agree; old versions have a retirement plan.
• ✓Webhooks verify signatures and timestamps, prevent replay and use idempotent handlers.
• ✓Third-party calls use timeouts, validation, bounded retries and fail closed for sensitive decisions.

5. Logs, alerts and investigation readiness

Security logs should answer who did what, to which resource, from which client, with what outcome and correlation ID. Capture authentication failures, authorization denials, role or secret changes, administrative actions, rate-limit spikes, webhook failures and abnormal use of sensitive flows.

Do not log passwords, API keys, access tokens, refresh tokens, raw session IDs or unnecessary sensitive payloads. Standardize redaction and restrict log access; otherwise the observability system becomes a new repository of secrets.

An alert is useful only with an owner, threshold, delivery channel and runbook. Before launch, generate a controlled test event to prove that the log arrives, the alert fires and the on-call owner knows the next step.

• ✓Important requests have correlation IDs, but those IDs are never credentials.
• ✓Authentication, authorization, privilege changes and resource abuse are recorded.
• ✓Logs redact secrets/PII and have appropriate retention, access and tamper protection.
• ✓Critical alerts have owners and runbooks and have been tested end to end.

6. Negative tests and go/no-go evidence

Functional tests prove that valid requests succeed; security negative tests prove that invalid requests fail correctly. A minimum suite covers missing or bad tokens, wrong scopes, cross-user, cross-tenant, low-role/high-function access, extra fields, oversized payloads, webhook replay and quota abuse.

Each case needs an expected status and expected side effect. A 403 is not enough if data changed before the response. For creates, payments, emails, webhooks and asynchronous jobs, inspect the database, queue and downstream systems to confirm no unauthorized effect occurred.

Friday Works recommends three evidence groups at release: repeatable CI checks, contextual manual checks for authorization and business logic, and explicitly accepted residual risks with owners. Important findings need remediation and retest, not only a scanner screenshot.

• ✓A role, tenant and object matrix covers sensitive endpoints.
• ✓Tests cover tokens, input boundaries, quotas, replay, idempotency and error leakage.
• ✓Verification checks both the response and side effects in databases, queues and downstream services.
• ✓Severe issues are fixed and retested; residual risks have an owner and explicit acceptance decision.
• ✓Tests and inventory are preserved for future releases instead of discarded after launch.

When is a checklist not enough?

A checklist is useful for pre-release self-review and a repeatable baseline. It is not enough when an API handles payments, sensitive records, multiple tenants, complex administrative roles, public webhooks, file uploads, URL fetching or high-impact financial flows. Those cases need an assessment shaped by a specific threat model, identities and test data.

An API scanner can find misconfiguration and known patterns but usually cannot infer ownership, tenant boundaries, business preconditions or asynchronous side effects. Stronger evidence combines an inventory, automated checks, manual review, request/response proof and remediation retesting.

For an independent pre-launch scope, Friday Works assesses web apps and APIs against agreed objectives, focusing on authentication, authorization, input, configuration and critical flows; deliverables include evidence, remediation priorities and in-scope retesting.

• ✓Use the checklist for self-review and a repeatable release gate.
• ✓Add contextual assessment when data, tenants or business impact are significant.
• ✓Do not present a one-time scan as proof that a system is secure.
• ✓Retest fixes and evolve the checklist from real findings.