feat: Add FastAPI Security Cheat Sheet

[Sikandar1310291]

You're A Rockstar

Thank you for submitting a Pull Request (PR) to the Cheat Sheet Series.

🚩 If your PR is related to grammar/typo mistakes, please double-check the file for other mistakes in order to fix all the issues in the current cheat sheet.

Please make sure that for your contribution:

• In case of a new Cheat Sheet, you have used the Cheat Sheet template.
• All the markdown files do not raise any validation policy violation, see the policy.
• All the markdown files follow these format rules.
• All your assets are stored in the assets folder.
• All the images used are in the PNG format.
• Any references to websites have been formatted as [TEXT](URL)
• You verified/tested the effectiveness of your contribution (e.g., the defensive code proposed is really an effective remediation? Please verify it works!).
• The CI build of your PR pass, see the build status here.

If your PR is related to an issue, please finish your PR text with the following line:

This PR fixes issue #1969.

AI Tool Usage Disclosure (required for all PRs)

Please select one of the following options:

• I have NOT used any AI tool to generate the contents of this PR.
• I have used AI tools to generate the contents of this PR. I have verified
  the contents and I affirm the results. The LLM used is Gemini 2.5 Pro
  and the prompt used is Create a FastAPI Security Cheat Sheet based on issue #1969.

Thank you again for your contribution 😃

[szh]

We should really have someone familiar with FastAPI review this.

[szh]

Seems kind of strange to link to the project itself

[andrzejsydor]

What is the value of the PR?

[Sikandar1310291]

What is the value of the PR?

The value of this PR is to provide a dedicated security resource for the rapidly growing FastAPI ecosystem, filling a specific gap in the current OWASP Cheat Sheet Series.

While generic API security principles apply, FastAPI introduces unique architectural patterns that require specific security guidance not found in other Python (Flask/Django) or generic guides:

Dependency Injection Security: It guides developers on using FastAPI's dependency injection system for consistent authentication & authorization (e.g., Depends(get_current_user)), which is the framework's primary way of handling security.

Pydantic & Type Hinting: It demonstrates how to leverage Pydantic models (specifically Field constraints and types) for strict input validation, a core part of FastAPI that differs from other frameworks.

Default Misconfigurations: It addresses FastAPI-specific defaults that can be insecure in production, such as the automatically generated Swagger UI (/docs) and providing concrete code to secure or disable them.

Async/ASGI Context: It covers security configurations specific to the ASGI/Uvicorn deployment model, which differs from the traditional WSGI approach.
This cheat sheet ensures developers have a "canonical" reference for implementing OWASP Top 10 controls using idiomatic FastAPI code.

[web4akash]

Thanks for taking the time to put together this PR — I appreciate the effort and the solid FastAPI examples included here.

That said, I want to clarify that this PR is somewhat different from what I originally proposed in the issue. (#1969)

My original intent for the FastAPI Security Cheat Sheet was not primarily to document how to use FastAPI security features, but rather to focus on:

• Threat modeling specific to FastAPI’s architecture (dependency injection, async execution, background tasks)
• Common misuse cases and anti-patterns seen in real-world FastAPI applications
• Security pitfalls that arise when following common tutorials or examples without additional controls
• Explicit mapping of FastAPI-specific issues to OWASP API Security Top 10 risks
• “What can go wrong” scenarios, not just “how to implement”

The current content is closer to an implementation-oriented best practices guide, which overlaps significantly with existing FastAPI documentation and general API security guidance.

I think this PR could still be valuable with a shift in focus toward:

• Highlighting insecure patterns first, then contrasting them with secure approaches
• Calling out FastAPI-specific gotchas (e.g., dependency bypass, auth gaps in background tasks, OpenAPI exposure, async-related assumptions)
• Including misuse cases and attacker perspectives rather than only code correctness

Happy to discuss how we can align this PR with the original scope, or whether it makes sense to treat this as a separate contribution.

[Sikandar1310291]

@web4akash Thank you for the detailed feedback and clarification on the original intent of issue #1969. I completely understand your perspective now.

You're right that the current PR leans more heavily toward implementation-oriented best practices rather than focusing on threat modeling and real-world misuse cases. I appreciate you laying out this distinction so clearly.

Looking at your suggestions, I think there are a few paths forward:

1. Pivot this PR to align with the original scope by reorganizing the content to:

   • Lead with common attack scenarios and misconfigurations rather than "how to do it right"
   • Highlight FastAPI-specific gotchas (e.g., dependency injection bypass, auth gaps in background tasks, OpenAPI schema exposure)
   • Contrast insecure vs. secure patterns side-by-side
   • Map vulnerabilities directly to OWASP API Top 10

2. Create a focused "What Can Go Wrong" section within the current structure that addresses the threat modeling angle

3. Split into two resources - keep the best practices guide as-is and create a separate "FastAPI Security Pitfalls & Threat Modeling" cheat sheet

I'm leaning toward option 1, as it seems closer to the OWASP Cheat Sheet Series philosophy of addressing "what can go wrong" and how to defend against it.

Would you be open to collaborating on restructuring this? I can start refactoring the content based on these principles and get your feedback before finalizing.