API Security Checklist: Auth, Rate Limits, and Abuse Cases

Quickstart

If you only have 30–60 minutes, do these steps in order. They’re the highest ROI moves to stop the most common API failures: broken authorization, unlimited data extraction, and “silent” abuse.

Overview

This is a checklist-style guide to shipping an API that’s harder to exploit and cheaper to operate. It focuses on three areas that cause most real incidents: authentication (who are you?), authorization (are you allowed?), and abuse controls (what happens when a bot tries 10M requests?).

The goal isn’t “perfect security” (doesn’t exist). The goal is a set of guardrails that make abuse expensive, mistakes contained, and incidents recoverable.

Core concepts

A good API security checklist is mostly about correctness under pressure: when you add new endpoints fast, when traffic spikes, and when someone intentionally tries to break your assumptions. These concepts help you build guardrails that keep working at scale.

Authentication vs authorization (and why people mix them up)

Threat-driven design: protect what’s valuable and abusable

Attackers don’t scan every endpoint equally. They focus on endpoints that: (1) return lots of data, (2) change account state, or (3) cost you money. A practical way to prioritize is to label each route with data sensitivity and abuse risk.

Rate limiting vs quotas (they solve different problems)

Abuse cases: think like a bot

Abuse is different from hacking: the attacker may use perfectly valid requests. Your job is to make misuse detectable and expensive without punishing legitimate users.

Step-by-step

This is a practical implementation path you can apply to an existing API or bake into a new one. The key is to avoid “security as a feature” and instead build default-safe patterns that every endpoint inherits.

Step 1 — Inventory endpoints and classify risk

Start by listing every route (including internal/admin) and adding two labels: data sensitivity (public, internal, PII, financial) and abuse risk (low, medium, high). This immediately tells you where to focus rate limits, scopes, and audit logging.

Step 2 — Choose an auth strategy (and document it)

Your API security checklist should start with one question: Who calls this API? A browser app, a mobile app, server-to-server integrations, or partners? Different callers imply different credentials. Whatever you choose, document it in OpenAPI so it’s visible and reviewable.

Here’s a compact OpenAPI example showing bearer tokens and per-endpoint security requirements. This doesn’t implement security by itself, but it forces clarity and makes reviews much easier.

openapi: 3.0.3
info:
  title: Example API
  version: 1.0.0

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
    apiKeyAuth:
      type: apiKey
      in: header
      name: X-API-Key

paths:
  /v1/users/{id}:
    get:
      summary: Get a user (self or admin)
      security:
        - bearerAuth: []
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: OK
        "401":
          description: Unauthorized
        "403":
          description: Forbidden

Step 3 — Implement authorization as a policy, not scattered if-statements

Authentication is a gate. Authorization is the map of what’s allowed. The safest pattern is: (1) resolve the actor, (2) resolve the resource, (3) ask a policy function if the action is allowed. That gives you a single place to test, audit, and change behavior.

Step 4 — Add request guards: validation, caps, and safe defaults

Most abuse relies on endpoints being too flexible. Add guardrails so requests stay inside safe bounds: validate input, cap pagination, and reject payloads that exceed your limits. This improves both security and reliability.

Step 5 — Implement rate limits that match abuse patterns

Rate limiting should be multi-dimensional (IP, account, tenant, API key) and route-aware. A single global limit is better than nothing, but it won’t stop targeted abuse (e.g., login or export endpoints).

Below is a practical Node/Express example that: (1) validates a bearer token, (2) enforces a per-user rate limit, and (3) applies a stricter limit for a high-risk route (login).

import express from "express";
import rateLimit from "express-rate-limit";
import jwt from "jsonwebtoken";

const app = express();
app.use(express.json());

// 1) Global baseline: protects your infra from obvious floods
app.use(rateLimit({
  windowMs: 60_000,
  limit: 300,
  standardHeaders: true,
  legacyHeaders: false
}));

function requireAuth(req, res, next) {
  const header = req.headers.authorization || "";
  const token = header.startsWith("Bearer ") ? header.slice(7) : null;
  if (!token) return res.status(401).json({ error: "unauthorized" });

  try {
    // In production: validate issuer/audience and use a JWKS-based verifier for OIDC providers.
    const payload = jwt.verify(token, process.env.JWT_PUBLIC_KEY, { algorithms: ["RS256"] });
    req.user = { id: payload.sub, role: payload.role, scope: payload.scope || "" };
    return next();
  } catch {
    return res.status(401).json({ error: "unauthorized" });
  }
}

// 2) Per-user limiter (fallback to IP if unauthenticated)
const userLimiter = rateLimit({
  windowMs: 60_000,
  limit: 120,
  keyGenerator: (req) => (req.user?.id ? `u:${req.user.id}` : `ip:${req.ip}`),
  standardHeaders: true,
  legacyHeaders: false
});

app.get("/v1/me", requireAuth, userLimiter, (req, res) => {
  res.json({ id: req.user.id });
});

// 3) High-risk endpoint: stricter limiter
app.post("/v1/login", rateLimit({ windowMs: 60_000, limit: 10 }), (req, res) => {
  res.status(501).json({ error: "not_implemented" });
});

app.listen(3000);

Step 6 — Harden against replay and webhook abuse

Webhooks and signed requests are common “forgotten” surfaces. The core idea is simple: include a timestamp and signature, verify both, and reject old requests. This prevents replay (an attacker re-sends a captured request later).

Example: verify a webhook signature using HMAC, enforce a maximum clock skew, and compare signatures safely. This belongs in your API security checklist if you accept inbound events from third parties.

import hmac
import hashlib
import time

MAX_SKEW_SECONDS = 300  # 5 minutes

def verify_webhook(secret: str, body: bytes, header_sig: str, header_ts: str) -> bool:
  """
  header_sig example: "v1=hex_digest"
  header_ts: unix timestamp as string
  """
  try:
    ts = int(header_ts)
  except (TypeError, ValueError):
    return False

  # Reject replays / very old requests
  if (time.time() - ts) > MAX_SKEW_SECONDS:
    return False

  # Sign (timestamp + "." + body) to bind time + payload
  msg = str(ts).encode("utf-8") + b"." + body
  digest = hmac.new(secret.encode("utf-8"), msg, hashlib.sha256).hexdigest()
  expected = f"v1={digest}"

  # Constant-time comparison to avoid timing attacks
  return hmac.compare_digest(expected, header_sig)

Step 7 — Add observability: logs you can use during an incident

Logging isn’t “nice to have” for security. It’s your reconstruction tool when something goes wrong. Log enough to answer: who did what to which resource, from where, and what happened.

Step 8 — Test the checklist (don’t trust “it seems fine”)

A checklist is only real when it’s tested. Add automated tests for the scariest failures: missing authorization, privilege escalation, and “infinite” list endpoints.

Common mistakes

These are patterns behind “we had auth, why did we still leak data?” The fixes are usually straightforward, but you have to be intentional because frameworks don’t automatically enforce them.

FAQ

Do I need OAuth if I already use API keys?

Not always. API keys work well for server-to-server integrations, but they’re coarse-grained unless you add scopes/permissions on top. OAuth/OIDC shines when access is tied to a user identity, delegated access (third-party apps), or you need standard flows like authorization code. Many teams use both: OAuth for user access and API keys for partner integrations.

What’s the difference between a scope and authorization?

A scope is a hint; authorization is the decision. Scopes (or roles/claims) describe what a token might be allowed to do, but your API still needs to check the specific resource: user A with “read” scope should not automatically read user B’s private object.

How do I choose rate limit numbers?

Start with intent and risk. Set looser limits for low-risk reads and stricter limits for high-risk routes (login/reset, exports, search). Use observed production traffic to tune. The important part is having some limit, returning predictable 429s, and limiting by the right keys (account/tenant/API key), not only IP.

How do I prevent scraping if the API is public?

You can’t “ban scraping” with one trick. You reduce it by adding caps (page size, fields), introducing quotas, requiring authentication for higher-value data, using route-specific throttles, and watching for automated behavior (high fan-out, sequential ID access, abnormal user agents). Also consider “bulk access” as a separate product feature with explicit permissions and audit logs.

Should I return 404 or 403 for unauthorized resources?

It depends on your enumeration risk. Returning 404 for unauthorized access can hide whether a resource exists, which reduces enumeration. Returning 403 is clearer for legitimate users. A common compromise: use 404 for sensitive resources and keep detailed reasons in internal logs.

How do I secure webhooks and signed requests?

Verify signatures and prevent replay. Use an HMAC (or asymmetric signature), include a timestamp, reject old requests, and use constant-time signature comparison. Also log verification failures and rate-limit webhook endpoints to prevent floods.

Cheatsheet

A scan-fast API security checklist you can paste into a PR description, run during a launch review, or keep as your “definition of done”.

Wrap-up

The best API security isn’t a single library or vendor. It’s a set of defaults you apply consistently: verify identity, enforce object-level authorization, cap and throttle what can be abused, and log the signals you’ll need when something goes wrong.

If you want to go deeper, the related posts below pair well with this checklist: threat modeling, modern auth, DevSecOps, and common real-world attack patterns.

Related posts

• OWASP Top 10 in Real Life: How Apps Actually Get Hacked
• Threat Modeling in 45 Minutes: A Lightweight Template
• Passkeys, MFA, Sessions: Modern Authentication Done Right
• DevSecOps Basics: Add Security to CI/CD Without Chaos
• Dependency Attacks: How One Package Can Burn Your App
• Linux Hardening 80/20: SSH, Updates, Firewall, Logs