domains / families / security / api-security-best-practices

api-security-best-practices

combined

Implement secure API design patterns including authentication, authorization, input validation, rate limiting, and protection against common API vulnerabilities

When to use

• Use when designing new API endpoints
• Use when securing existing APIs
• Use when implementing authentication and authorization
• Use when protecting against API attacks (injection, DDoS, etc.)
• Use when conducting API security reviews
• Use when preparing for security audits
• Use when implementing rate limiting and throttling
• Use when handling sensitive data in APIs

When not to use

• This guide is not a full identity service, certified security audit or penetration test. Snippets omit application adapters and integration error middleware. Unit tests of a parser do not verify database transactions, proxy behavior or pro…

Skill page

Conflict

The two copies cover the same topic but with materially different depth and scope. The sickn33 copy is a rigorous, defensive procedure focused on exact token contracts, tenant-scoped authorization predicates, strict input parsing, and refresh-token atomicity, with explicit constraints against inferring permissions before verification and against implicit admin bypasses. The LeoYeAI copy is a broader, more prescriptive checklist that includes rate limiting, data protection, security testing, and a full JWT login/refresh implementation example that the first copy deliberately avoids (it treats refresh as a server-side opaque design and warns against storing tokens in a database). Because the LeoYeAI copy contains steps (rate limiting, data protection, testing) and a concrete implementation pattern (storing refresh tokens in a database) that the sickn33 copy lacks or explicitly contradicts, crowning one would hide a real alternative approach.