API security checklist for developers and DevOps teams.

Why an API security checklist works

APIs fail in repeatable ways. Teams expose an endpoint too early, trust a gateway to do more than it really does, skip rate limits because they plan to add them later, or assume an identity provider configuration is enough to protect every downstream service. A checklist creates a shared baseline so developers, platform engineers, and security reviewers stop arguing about fundamentals and start closing gaps.

The point is not to create a giant compliance document. The point is to make sure your team can answer key questions quickly. Who can call this endpoint? What identity proves it? What input is accepted? What happens when clients send too much traffic? What gets logged? How do we detect abuse? If you cannot answer those questions with confidence, the checklist is not complete.

1. Lock down identity and authentication

Every API should have an explicit authentication model. That sounds obvious, but many incidents start because an endpoint was intended for internal use, later exposed through a public frontend, and never revisited. Treat each path as public until proven otherwise.

• Choose the authentication method per client type: user-facing apps, service accounts, partners, and internal jobs should not all share the same token strategy.
• Require short-lived credentials whenever possible. Long-lived bearer tokens become inventory problems.
• Validate iss, aud, expiration, and signature for JWTs on the API side, not only at the gateway.
• Rotate secrets and signing keys with a documented schedule and rollback plan.
• Disable anonymous access unless the endpoint is intentionally public and rate-limited.

A common mistake is accepting tokens that were minted for a different API or different audience. Another is trusting an upstream reverse proxy to verify tokens while backend services continue to accept any request that simply arrives over the internal network. Zero trust starts with the assumption that network location alone is not proof of identity.

app.use(async (req, res, next) => {
  const token = readBearerToken(req.headers.authorization);
  const claims = await verifyJwt(token, {
    issuer: "https://auth.example.com",
    audience: "orders-api"
  });

  if (!claims.scope?.includes("orders:read")) {
    return res.status(403).json({ error: "missing_scope" });
  }

  req.user = claims;
  next();
});

This kind of middleware is simple, but it captures the real rule: validation is contextual. A valid token is not enough if it was issued for the wrong service or lacks the right scope.

2. Enforce authorization at the object and action level

Broken object-level authorization is still one of the easiest ways to leak data through an API. Teams build an endpoint like /v1/invoices/{id}, confirm the user is logged in, and forget to verify that the logged-in user is allowed to access that specific invoice.

• Check ownership or tenant membership on every object lookup.
• Do not rely on guessable IDs as a security boundary.
• Review admin and support roles separately from standard user permissions.
• Audit bulk endpoints and export jobs, not only detail endpoints.

Real example: a SaaS application has tenant-scoped project IDs, but the export endpoint accepts a raw project identifier and only checks that the caller is authenticated. The result is quiet cross-tenant data exposure. The fix is not hiding the identifier. The fix is validating the tenant-to-object relationship every time the object is loaded or exported.

3. Validate input and control payload shape

Input validation is still underrated in API security. Developers often think about SQL injection or command injection, but the earlier and more common failure is accepting more structure than intended. That extra structure turns into mass assignment, unsafe filtering, oversized queries, and denial-of-wallet behavior.

• Define explicit schemas for request bodies, query parameters, and headers.
• Reject unknown fields by default on write operations.
• Set body size and array length limits.
• Normalize identifiers and validate expected formats early.
• Do not pass raw filter objects into your ORM or search layer.

const CreateKeySchema = z.object({
  name: z.string().min(3).max(80),
  scopes: z.array(z.string()).max(20),
  expiresAt: z.string().datetime().optional()
}).strict();

const parsed = CreateKeySchema.safeParse(req.body);
if (!parsed.success) {
  return res.status(400).json({ error: "invalid_request" });
}

The important detail is .strict(). Strict schemas prevent clients from sneaking in fields that your application was never meant to expose.

4. Harden transport, headers, and browser exposure

Even APIs that are not intended for browser use often end up behind documentation portals, developer consoles, or SPA clients. That means response headers matter. Weak CORS, missing HSTS, permissive caching, or verbose server fingerprints all make life easier for attackers and harder for defenders.

A quick win is to run your endpoint through the API header checker and capture easy fixes in the same sprint.

5. Build abuse prevention with rate limits and quotas

Rate limiting is not just for denial-of-service. It is one of the most effective controls against brute force, credential stuffing, scraping, inventory abuse, and runaway integrations. Many teams add it too late because they think of it as an infrastructure concern rather than an application safety feature.

• Set per-IP, per-user, or per-token limits depending on endpoint behavior.
• Use stricter policies for login, token refresh, search, export, and password reset routes.
• Return clear 429 responses and consider exposing rate-limit headers for developers.
• Monitor for distributed abuse that bypasses simple per-IP controls.

Real example: an unauthenticated username lookup endpoint is technically read-only, but it lets attackers enumerate valid accounts at scale. A small rate limit, a generic response shape, and better monitoring often reduce this risk dramatically.

6. Log security signals without logging secrets

Logs are where you will confirm or miss an API incident. They need enough detail to reconstruct abuse patterns, but not so much detail that they become a second data leak. Token bodies, raw secrets, and full personal records should not end up in application logs by default.

• Log request identifiers, caller identity, tenant, route, status code, and latency.
• Redact authorization headers, API keys, and secret payload fields.
• Track abnormal spikes in 401, 403, 404, and 429 responses.
• Correlate gateway and application logs so you can trace a request end to end.

Monitoring should include not just technical failures, but suspicious success. A burst of valid 200 responses against a profile export endpoint can still be abuse.

7. Make security part of delivery, not a final review

The most reliable API security programs are embedded into the delivery path. That means schema validation in code review, secret scanning in CI, header checks in staging, and policy reviews before an endpoint becomes public. Waiting for a quarterly security review is how quietly dangerous defaults reach production.

• Add security checks to pull requests for auth middleware, CORS config, and public routes.
• Keep an inventory of public endpoints and third-party integrations.
• Run a short security review before every major API version release.
• Document rollback steps for auth, rate limiting, and gateway policy changes.

Final API security checklist

• Authentication is explicit, short-lived, and validated by the API.
• Authorization is checked on every object and action.
• Inputs are schema-validated and unknown fields are rejected.
• HTTPS, headers, CORS, and caching are configured intentionally.
• Rate limits and quotas protect sensitive routes.
• Logs capture security signals without exposing secrets.
• Security checks are part of development and deployment.

If you want one practical next step, run the free tools on a live endpoint and compare the result against this checklist. That turns theory into a short remediation backlog your team can actually ship.