All Playbooks
Securityadvanced

Securing Your API Endpoints

API security is not a sprinkle of middleware, it is a layered set of defenses where any one missing layer opens the door. This is my full checklist for hardening API endpoints: authentication, rate limiting, validation, CORS, audit logging, and the response headers that mitigate the long tail of browser-side attacks. Used on every production API I have shipped.

75 min7 steps
7

Steps

4

Tools

5

Outcomes

advanced

Difficulty

Technologies used

Next.jsJWTRedisZod

The methodology

The phases, in order

Each phase below is something I actually run in a project. The descriptions are how I think about the work, not abstract definitions.

01

Phase

Phase 1 of 7

Authentication Layer and Token Strategy

I use short-lived JWTs for API authentication, paired with a refresh token kept in an httpOnly cookie. Tokens carry the minimum claims needed: user id, role, and an issued-at timestamp. Verification happens in a single helper so the rules are not scattered. This builds on NextAuth setup for the broader auth story.
02

Phase

Phase 2 of 7

Rate Limiting Per Identity

Rate limits run on Redis with a sliding-window counter. I apply two layers: a global IP limit to absorb noisy scrapers, and a per-user limit for authenticated traffic. Limits get tighter on sensitive routes like password change and password reset. The response includes the standard X-RateLimit headers so well-behaved clients can self-throttle.
03

Phase

Phase 3 of 7

Input Validation with Zod

Every request body and query parameter passes through a Zod schema. I never trust shapes from the client, even on internal endpoints. Validation errors return 400 with a structured error body, not a stack trace. The schemas are exported and reused in the front-end forms, which removes a whole category of inconsistent validation bugs.
04

Phase

Phase 4 of 7

CORS and Origin Controls

CORS gets configured with an explicit allowlist of origins, never a wildcard in production. Preflight responses cache aggressively to reduce overhead. For internal services I add an HMAC signature on top of CORS so an origin spoofing attack still has to forge a signature it cannot compute.
05

Phase

Phase 5 of 7

Audit Logging

Every authenticated action gets a structured audit log entry: actor, action, resource, ip, user_agent, timestamp. Logs ship to a tamper-evident store, not the same database the app writes to. This is non-negotiable for fintech and healthcare, and quietly useful for everyone else when incidents happen.
06

Phase

Phase 6 of 7

Security Headers and CSP

I add a strict Content-Security-Policy, HSTS, X-Content-Type-Options, X-Frame-Options, and a Referrer-Policy. The CSP starts in report-only mode against real traffic for a week, then I enforce it. This is the difference between an XSS being a footnote and an XSS being a breach.
07

Phase

Phase 7 of 7

Secrets, Dependencies, and Periodic Review

Secrets live in a real secret manager, not the env file. I run a monthly review of access tokens, rotate anything older than 90 days, and run a dependency audit before each release. The whole checklist takes 30 minutes once it is in muscle memory, and it has caught real issues every time I have done it for a client.

Results

What You'll Achieve

Expected outcomes from implementing this playbook

Secure API authentication with short-lived tokens
Protection against scrapers, brute force, and abuse
Validated and sanitized inputs across every endpoint
A real audit trail you can hand to a compliance reviewer
Need a security review? Book a security audit or contact me.

Use this playbook

Want me to run this with you?

The playbook is the public version. The private version is me running it for your team against a real deadline. If you have a project on the line, that is usually the faster path.

Start a projectJust ask a question

Next up

Database · 45 min

Managing Database Migrations

Database migrations are the part of the system where a tiny mistake creates an outage that lasts hours. This is the playbook I follow when migrating a production schema: expand-then-contract, dual writes when needed, idempotent scripts, a real rollback plan, and verification that does not depend on the migration tool reporting success. Boring on purpose, because exciting migrations are the dangerous ones.

Previous

Optimizing Performance with Edge Caching

Next

Managing Database Migrations