Add advanced API security best practices

[bad-antics]

Summary

Added new security checklist items covering advanced topics:

Rate Limiting & Abuse Prevention

• Sliding window rate limiting
• Exponential backoff for failed auth
• CAPTCHA/proof-of-work challenges

GraphQL-Specific Security

• Disable introspection in production
• Query depth limiting
• Query cost analysis

Secrets Management

• Regular key rotation
• HSM usage
• Secret scanning in CI/CD

Zero Trust Architecture

• mTLS for service-to-service
• Validate internal requests
• Short-lived tokens

These additions help cover modern API security concerns that weren't in the original checklist.

[guest20]

Is this suggesting both access tokens and mtls?

[Maikuolan]

These sound like good additions to me, and I'm generally inclined towards merging, though you've listed some of them twice, and the "API Security Best Practices (Advanced)" has been listed twice, too. I'll leave this open for a little while to allow others the opportunity review and comment, and in the meantime, maybe some of the duplication could be removed and cleaned up a little?

Cheers. :-)

[bad-antics]

Good question! The suggestion is to use mTLS for service-to-service authentication (machine identity) alongside access tokens for user authorization. They serve complementary purposes - mTLS verifies the calling service, while tokens carry user context and permissions. For high-security APIs, using both provides defense in depth. Happy to clarify or adjust the wording if needed!

[bad-antics]

Good question! The suggestion is to use mTLS for service-to-service authentication (machine identity) alongside access tokens for user authorization. They serve complementary purposes - mTLS verifies the calling service, while tokens carry user context and permissions. For high-security APIs, using both provides defense in depth. Happy to clarify the wording if needed!

[bad-antics]

Fixed! Removed the duplicate sections as requested. The 'API Security Best Practices (Advanced)' section now appears only once, properly placed before the Contribution section. Thank you for the review!

[guest20]

This needs a limit - exponential gets pretty long pretty quickly, so you need an explicit timeout too

[guest20]

Your mum is suspicious activity.
~~ everybody I went to highschool with

You might want to be more concrete about what qualifies about "suspicious" activity, since most tools define "not watching all the ads" as suspicious

[Maikuolan]

Absolutely not wrong, but that said, "suspicious" is also likely to be highly subjective, and opinions of what, exactly, meets the criteria for being "suspicious" is likely to vary significantly from one person to another (and from one context to another; i.e., the intended purpose of the API, the inherent sensitivity and intended consumption of the data provided and so on). Adding clarification in cases where confusion could otherwise be caused is good, but likewise, being preemptively somewhat generic can help to avoid future arguments and nitpicking in cases where the details of the specifics of the matter at hand can be highly opinionated and/or varied. Finding the right balance is often the preferred ideal, but also, I wouldn't stress too much on that front. :-)

[guest20]

"don't commit secrets" and "scan for secrets" seem like the same point - one is the policy, one is the enforcement mechanism