Securing Modern APIs: Best Practices for 2026

## Security Is Not a Sprint Task Every project we've ever worked on has a security section somewhere in the Jira backlog. It's usually in the last sprint, labeled "Security Hardening", with the implicit understanding that it may not get done if the deadline is tight. This is backwards. And in 2026, with AI-generated attack vectors and automated exploit tooling, the cost of shipping insecure APIs has never been higher. This post covers the security practices we bake into every backend we ship — not as afterthoughts, but as defaults. ## Layer 1: Authentication — Stop Using JWTs Wrong JSON Web Tokens are everywhere. They're also frequently misconfigured. **Common mistakes:** - Signing tokens with a weak or hardcoded secret (SECRET_KEY=mysecret) - Not validating the aud (audience) claim — allows token reuse across services - Storing tokens in localStorage — vulnerable to XSS attacks - Setting expiry times too long (24+ hours on access tokens) **What we do instead:** - RS256 (asymmetric) signing for tokens shared between services - Short-lived access tokens (15–30 minutes) + refresh token rotation - HttpOnly, SameSite cookies for browser clients — XSS can't touch them - Token revocation list in Redis for immediate invalidation when needed ## Layer 2: Authorization — Never Trust the Client Authentication answers "who are you?" Authorization answers "what are you allowed to do?" The rule is simple: **never make authorization decisions based on data the client sends**. Always derive permissions from the authenticated user's identity on the server. Bad pattern: ```js // ❌ Never do this const { userId, role } = req.body; // client-sent if (role === 'admin') allowDelete(); ``` Good pattern: ```js // ✅ Always do this const { userId } = req.auth; // server-verified JWT payload const user = await db.users.findById(userId); if (user.role === 'admin') allowDelete(); ``` This distinction catches an entire class of privilege escalation attacks. ## Layer 3: Input Validation — Treat All Input as Hostile Every piece of data entering your API — headers, query params, body, cookies — should be validated against a strict schema before it touches your business logic. We use **Zod** in TypeScript projects for runtime validation that's also type-safe: ```ts const createOrderSchema = z.object({ productId: z.string().uuid(), quantity: z.number().int().min(1).max(100), addressId: z.string().uuid(), }); const body = createOrderSchema.parse(req.body); // throws if invalid ``` This single pattern prevents SQL injection via malformed input, business logic abuse via out-of-range values, and crashes from unexpected data shapes. ## Layer 4: Rate Limiting and Abuse Prevention Without rate limiting, your API is vulnerable to: - Credential stuffing (automated login attempts with breached passwords) - Enumeration attacks (discovering valid user emails via timing differences) - Cost amplification (an attacker triggering expensive AI calls at your expense) We implement three tiers: 1. **IP-based rate limits** at the edge (Vercel, Cloudflare) — 100 req/min for anonymous 2. **User-based rate limits** in middleware — prevents authenticated abuse 3. **Endpoint-specific limits** — tighter limits on expensive operations (file upload, AI inference, email sending) ## Layer 5: Secrets Management Never commit secrets to Git. This sounds obvious. It still happens to experienced teams. Our workflow: - **Local development**: .env.local (gitignored) + 1Password CLI for team sharing - **Production**: Environment variables injected at deploy time by Vercel/AWS - **CI/CD**: GitHub Actions secrets — never printed in logs - **Rotation**: Quarterly rotation schedule with automated reminders One tool we strongly recommend: **GitGuardian** for automatic scanning of your commits for accidentally committed secrets. It catches what developers miss. ## Building a Security Culture Technical controls matter, but they don't help if the team doesn't have a security mindset. Practices that stick: - **Security review checklist** as part of every PR template - **Monthly threat model sessions** — 30 minutes of "what could an attacker do with this?" - **Post-incident blameless reviews** — learning focus, not punishment Security is a team sport. The goal isn't to build a perfect fortress on day one. It's to systematically reduce your attack surface over time, faster than attackers can find new holes. Start with the five layers above. They'll block 90% of attacks in the wild.

nirmataAI team

Author