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

[bad-antics]

Hi @Maikuolan! Thanks for the review. I already fixed the duplicate sections in a previous commit - the 'API Security Best Practices (Advanced)' section now appears only once. Could you take another look? The PR should be clean now. 🙏

[bad-antics]

Hi @Maikuolan, thanks for the feedback!

I've reviewed the PR and it looks like there's only one instance of each section now. Could you point me to where you're seeing the duplicates? I want to make sure I address everything before this gets merged.

Happy to make any additional changes needed! 🙏

[Maikuolan]

Hi @bad-antics,

Thanks for the changes, and LGTM now. 👍

Sorry for the delayed response; Limited available time and all that.

I'll go ahead and merge this now. (And if anyone has any further suggestions for improvements, possible changes, etc, additional pull requests can always be made and are always welcome. For now, I see no reason to delay this further). :-)