---

name: api-hardening description: API hardening for Express, FastAPI, and serverless. Use for rate limiting, CORS, input validation, API keys, or OWASP API Top 10.

API hardening

Defense-in-depth patterns for protecting APIs from abuse, injection attacks, and data leakage. Recipes are oriented around the OWASP API Security Top 10:2023 and were last verified on 2026-05-08.

Step 0: Research the current security landscape (do this first)

Security knowledge ages on a 6-12 month half-life. The recipes below were last verified on 2026-05-08; they may be stale by the time you read this. Before applying any pattern in this skill, fan out research scoped to the API surface or web defense being added so the recipes are interpreted against current authoritative sources, not against this file's snapshot.

Default-on, with a documented skip

Run the 4-angle research below by default. Skip ONLY when ALL of these hold:

• (a) You ran this same skill on this same primitive within the last 4 hours of the current session,
• (b) That prior research surfaced no urgent advisories for the API surface or web defense being added,
• (c) You log a one-line Research skipped because <reason> note in your response.

"I think I know" / "moving fast" / "user wants this done quickly" / "already familiar" are NOT valid skip reasons. The whole point of this preamble is that future-you should not trust this skill body's defaults until current state is checked.

Fan out 4 subagents in parallel

Each subagent returns ≤300 words of bullets with citations. Dispatch all 4 in a single message so they run concurrently.

Angle 1, Authoritative standards. Have NIST / OWASP / IETF (RFCs and Internet-Drafts) / W3C / CISA published anything new about the API surface or web defense being added in the last 6-12 months? Look for: spec finalizations, deprecations, replacement specs, RFC publications, draft revisions, NIST SP updates, OWASP project version bumps. Cite by document number + publication date.

Angle 2, Active exploitation. What's actively being exploited that targets the API surface or web defense being added? Pull from: CISA Known Exploited Vulnerabilities (KEV) catalog (filter to last 6-12 months), recent CVE / GHSA entries with high CVSS or in-the-wild exploitation, breach postmortems and incident reports (CSRB, vendor RCAs, security-vendor research). Surface CWE patterns dominating recent KEV adds. Cite by CVE number + advisory URL.

Angle 3, Tooling and library state. Are the libraries this skill recommends still current? What are the latest major versions in the relevant package registry (npm / PyPI / RubyGems / crates.io)? Have any been deprecated, replaced, or merged into another project? Have any flipped a secure default? Look up current versions in: registry.npmjs.org, pypi.org, rubygems.org, crates.io, pkg.go.dev. Cite by package + version + release date.

Angle 4, Practitioner discourse. What are practitioners and security teams talking about in the last 6 months? Pull from: OWASP Cheat Sheet Series (last-modified date matters), GitHub Security Lab posts, vendor security blogs (Cloudflare, Fastly, Snyk, Datadog, Wiz, GitGuardian), conference talks (Black Hat, DEF CON, OWASP Global AppSec, USENIX Security), SANS ISC, Krebs, recent OWASP project re-releases. Surface the patterns being adopted and the anti-patterns being called out. Cite by post URL + author + date.

Synthesize before applying recipes

After the 4 returns land, write a 1-paragraph "current state for the API surface or web defense being added, as of <today's date>" that names:

• The current normative ceiling (what specs say SHOULD be the default in 2026).
• 1-2 active threats specific to the API surface or web defense being added from the last 6-12 months.
• Any tooling drift (deprecated lib, new default in a framework, package merged or replaced).
• Any practitioner consensus shift visible in recent cheat sheet / blog updates.

If the synthesis flags drift in this skill body's recipes (e.g., a spec finalized after 2026-05-08, a library now deprecated, a default flipped), call that out explicitly in your response and override the skill body where they conflict. The synthesis wins. The skill body is scaffolding, not scripture.

When you cannot run subagents

If subagents are not available in your runtime, the same shape applies in-line: do 4 sequential targeted searches (web search for standards, KEV catalog lookup, package registry version checks, recent cheat-sheet diff). Land the same 1-paragraph synthesis. Cost goes up; the protection does not change.

OWASP API Security Top 10:2023 mapping

The active edition for API-specific threat modeling is the OWASP API Security Top 10:2023 (https://owasp.org/API-Security/editions/2023/en/0x00-header/). The general OWASP Top 10:2025 (released late 2025, succeeding the 2021 edition) covers web applications more broadly; for an API surface, the 2023 API-specific list is the right framing.

The 2023 categories, and which sections of this skill speak to each:

• API1:2023 Broken object level authorization, enforce per-object access checks; covered alongside API key management and per-user rate limiting.
• API2:2023 Broken authentication, see the secure-auth skill for the auth primitive itself; this skill covers rate limits, request size, and timeout protections that flank auth endpoints.
• API3:2023 Broken object property level authorization, input validation (Zod / Pydantic) and explicit allowlist of writable fields.
• API4:2023 Unrestricted resource consumption, rate limiting, request size limits, timeout protection, file upload limits.
• API5:2023 Broken function level authorization, out of scope here; route-level auth lives in your framework.
• API6:2023 Unrestricted access to sensitive business flows, graph-traversal quotas, per-account read budgets, behavioral signals for credential stuffing.
• API7:2023 Server side request forgery, outbound URL allowlists; covered briefly under timeout protection and external API calls.
• API8:2023 Security misconfiguration, security headers, TLS posture, CORS configuration.
• API9:2023 Improper inventory management, out of scope here; an API gateway / catalog problem.
• API10:2023 Unsafe consumption of APIs, input validation on data fetched from upstream, plus deserialization safety.

For the broader web context, OWASP Top 10:2025 reorders the 2021 list. Notable shifts: A03:2025 "Software Supply Chain Failures" absorbs the old 2021 A06 "Vulnerable and Outdated Components", that 2021 category is dissolved into the supply-chain category. A09:2025 is "Security Logging and Alerting Failures" (previously "Logging and Monitoring"). The 2025 ordering: A01 Broken Access Control / A02 Security Misconfiguration / A03 Software Supply Chain Failures / A04 Cryptographic Failures / A05 Injection / A06 Insecure Design / A07 Authentication Failures / A08 Software or Data Integrity Failures / A09 Security Logging and Alerting Failures / A10 Mishandling of Exceptional Conditions.

Threat exemplars

Real 2023-2024 incidents that anchor the patterns in this skill. Cite these when explaining "why" to stakeholders.

• Polyfill.io supply-chain attack (2024-06-25). Funnull acquired the polyfill.io domain in February 2024 and injected malware into roughly 110,000 sites that loaded the script (per https://sansec.io/research/polyfill-supply-chain-attack). Lesson: every third-party <script> and <link rel="stylesheet"> needs a Subresource Integrity hash and a strict CSP; "trusted CDN" is not a guarantee.
• 23andMe credential stuffing (disclosed 2023-10). Attackers reused leaked credentials against 23andMe accounts, then pivoted via the DNA Relatives feature to enumerate roughly 6.9 million users from a smaller initial-account compromise (per https://blog.23andme.com/articles/addressing-data-security-concerns). Lesson: per-IP rate limits don't catch distributed credential stuffing, and per-account read quotas on graph or relationship endpoints are needed to cap the blast radius.
• MOVEit Transfer CVE-2023-34362 (disclosed 2023-05-31). A pre-authentication SQL injection in Progress MOVEit Transfer (per https://nvd.nist.gov/vuln/detail/CVE-2023-34362) was used by Cl0p to exfiltrate data from thousands of organizations, and the chain landed in the CISA KEV catalog. Lesson: parameterized queries are not optional, even on file-transfer paths that don't look like "user-facing APIs."
• Ivanti Connect Secure zero-day chain (disclosed 2024-01). CVE-2023-46805 (auth bypass) and CVE-2024-21887 (command injection) chained for unauthenticated remote code execution (per https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-060b). Lesson: command injection (CWE-78) plus auth bypass is the modern unauthenticated-RCE recipe; both halves need defenses.

Rate limiting

Maps to API4:2023 (unrestricted resource consumption) and API6:2023 (sensitive business flows).

Why it matters

Without rate limiting:

• Brute force attacks succeed
• APIs get DDoS'd by accident or intent
• One bad actor affects all users
• You get a surprise bill from your cloud provider

Distributed credential stuffing defeats per-IP limits, attackers rotate through residential proxy networks and one IP rarely hits the threshold. Pair per-IP limits with per-account quotas, behavioral signals (impossible-travel, device fingerprint anomalies), and a WAF in front for botnet patterns.

Express.js with express-rate-limit

Library versions current as of 2026-05-08: express-rate-limit and rate-limit-redis, verify in registry.npmjs.org before pinning.

const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis').default;
const { createClient } = require('redis');

const redisClient = createClient({ url: process.env.REDIS_URL });
redisClient.connect();

// General API rate limit
const apiLimiter = rateLimit({
  store: new RedisStore({ sendCommand: (...args) => redisClient.sendCommand(args) }),
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // 100 requests per window
  standardHeaders: true,
  legacyHeaders: false,
  message: { error: 'Too many requests, please try again later' },
  skip: (req) => {
    // Skip rate limiting for health checks
    return req.path === '/health';
  }
});

// Strict limit for auth endpoints
const authLimiter = rateLimit({
  store: new RedisStore({ sendCommand: (...args) => redisClient.sendCommand(args) }),
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5, // 5 attempts
  message: { error: 'Too many login attempts, please try again in 15 minutes' },
  keyGenerator: (req) => {
    // Rate limit by IP + email to prevent distributed attacks
    return `${req.ip}-${req.body?.email || 'unknown'}`;
  }
});

// Very strict limit for password reset
const passwordResetLimiter = rateLimit({
  store: new RedisStore({ sendCommand: (...args) => redisClient.sendCommand(args) }),
  windowMs: 60 * 60 * 1000, // 1 hour
  max: 3, // 3 requests per hour
  message: { error: 'Too many password reset requests' }
});

// Apply limiters
app.use('/api/', apiLimiter);
app.use('/auth/login', authLimiter);
app.use('/auth/forgot-password', passwordResetLimiter);

Sliding window implementation (custom)

// Redis-based sliding window rate limiter
class SlidingWindowRateLimiter {
  constructor(redisClient, options = {}) {
    this.redis = redisClient;
    this.windowMs = options.windowMs || 60000; // 1 minute default
    this.maxRequests = options.maxRequests || 100;
    this.keyPrefix = options.keyPrefix || 'ratelimit';
  }

  async isAllowed(identifier) {
    const now = Date.now();
    const windowStart = now - this.windowMs;
    const key = `${this.keyPrefix}:${identifier}`;

    // Remove old entries and count recent ones
    const multi = this.redis.multi();
    multi.zRemRangeByScore(key, 0, windowStart);
    multi.zCar