Add Enterprise API Security Architectural Patterns Cheat Sheet - Unified Guidance for All API Types

[ZMelliti]

Summary

This PR introduces the Enterprise API Security Architectural Patterns Cheat Sheet for enterprise-scale API security challenges beyond basic controls.

Key Features

• 8 enterprise patterns across multi-tenant isolation, cross-org federation, token security, and multi-protocol environments
• Pattern Selection Matrix for scenario-based implementation decisions
• Performance-optimized implementation roadmap with rollback triggers
• Architecture-agnostic works with monoliths, microservices, SOA, hybrid systems
• Complete threat-to-pattern mapping for enterprise security challenges

Unique Value

• Fills enterprise API security gap not covered by existing OWASP sheets
• Zero duplication with Authentication, Authorization, REST Security sheets
• Business-focused guidance linking patterns to compliance and operational needs
• Complete implementation lifecycle from assessment to monitoring

Addresses enterprise challenges like multi-tenancy, cross-organizational trust, advanced token security, and unified multi-protocol security that no other OWASP sheet covers.

Checklist

Please make sure that for your contribution:

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

Verification Details

• New Cheat Sheet: Created using the official template structure with Introduction, main sections, and References
• Link Validation: All internal references use proper [TEXT](CheatSheet.md) format and external links use [TEXT](URL) format
• Format Compliance: Follows markdown formatting rules with proper headers, code blocks, and structure
• No Assets: Text-based content with code examples only, no images or external assets required
• Effectiveness: All security practices validated against OWASP API Security Top 10 2023, RFC standards, and industry best practices
• Cross-References: Properly integrates with existing OWASP cheat sheets without duplication

This PR fixes #1865

AI Tool Usage Disclosure (required for all PRs)

Please select one of the following options:

• [x] 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 [llm name and version] and the prompt used is [your prompt here]. [Feel free to add more details if needed]

Thank you 😃

[jmanico]

I do not like structure of this cheatsheet, 50% is just API top 10 (we do not need to duplicate content from different OWASP project) and there is a lot of duplication from other cheatsheets.

I hear you Mac. The goal here was to not duplicate content. https://github.com/OWASP/CheatSheetSeries/issues/1865

[ZMelliti]

Thanks @mackowski and @jmanico for the feedback. The goal isn’t to duplicate content from the API Top 10 or other cheat sheets — rather, to complement them with practical, implementation-focused guidance. I’ll revise the structure to make that clearer and remove any overlapping sections.

[ZMelliti]

@mackowski, @jmanico I've restructured the cheat sheet to eliminate content duplication by adding an explicit scope section that separates enterprise patterns from existing OWASP sheets (Authentication/Authorization/API Top 10) and added new sections for API versioning security and performance considerations with concrete metrics. The sheet now serves as a complementary enterprise reference focused on multi-tenant isolation, federation, and gateway patterns without duplicating existing OWASP resources.

[ZMelliti]

Hello @jmanico and @mackowski, I'm still awaiting your review. If there are any changes needed or feedback to discuss, please let me know. Thank you.

[mackowski]

I am still not approvig that baseuse

Centralized Gateway Security - this is not best solution for all APIs and we already have a good content here for it https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets_draft/Authorization_Patterns_Cheat_Sheet.md

Technology-Agnostic Authentication - again this is useful for some APIs but not all of them and for many it will only complicate authentication logic.

All "Enterprise Security Patterns" ale useful but there are not recommandations for all APIs...

This content drifted a lot from beeing universal API recommendation to list of possible architectual patterns for some enterprise APIs.

We could re-name this to Enterprise Security Architectual Patterns Cheat Sheet and update narrative at the beginning a little bit. In such case I would still add more patterns - one specific example is proof of possession. Also I would review content that we have in draft to not duplicate it but link to it where possible

[mackowski]

The content is good but, in my opinion, this are just not general purpos APIs recommendations - and that was the orginal goal. For simpler APIs implementing all of that is overkill :-) I personally would also make performance section less concrete - from where you took the numbers for this section? They look like LLM random generated but since you did not used LLMs you have some data or sources to back it up?

[ZMelliti]

@mackowski Thanks for the detailed review — I really appreciate your feedback.

The draft focuses on enterprise-oriented API architectural patterns, following earlier feedback that removed OWASP Top 10 references. I propose renaming it to “Enterprise API Security Architectural Patterns Cheat Sheet” and updating the introduction to clarify scope.

Code snippets were flagged by GitHub Copilot, which is expected — they are intentionally illustrative, not full implementations. Regarding the performance section, the quantitative numbers were just illustrative examples to support my point, not sourced from benchmarks or generated by an LLM. They were intended to demonstrate relative trade-offs, but I understand that this can be misleading, so I’ll revise it to qualitative guidance with references where possible.

Here’s a roadmap of the updates I plan to make:

• Rename the cheat sheet and update the introduction to clearly reflect enterprise-focused scope.

• Revise the performance section to be qualitative and, where possible, include references or links to real-world guidance.

• Keep code snippets illustrative, with a note clarifying their conceptual purpose.

• Link to existing OWASP cheat sheets to avoid duplication.

• Add relevant additional patterns, such as Proof of Possession, to strengthen coverage.

Could you please review these proposed updates and confirm if this approach aligns with your expectations before I make the changes? Thank you :-)

[mackowski]

@jmanico and @szh what do you think?

[szh]

@mackowski I like the proposal

[ZMelliti]

Hello @mackowski, @szh and @jmanico, I've implemented all the updates from my previous roadmap based on your feedback.

What I've Addressed

• Renamed and updated introduction - Now clearly focused on enterprise scope.
• Fixed performance section - Removed those quantitative numbers, made it qualitative with proper references.
• Added more patterns - Including Proof of Possession and 7 other enterprise patterns.
• Linked to existing OWASP sheets - To avoid any duplication concerns.
• Clarified code snippets - They're illustrative examples, not production code.

New Additions

• Pattern Selection Matrix to help teams choose the right approach.
• Threat landscape mapping so you can see which patterns address specific risks.
• Step-by-step deployment guidance with performance considerations.

I think this version really fills the enterprise API security gap we discussed while staying true to OWASP standards. The patterns here aren't covered in the existing sheets, so it should complement the collection nicely.

Really looking forward to hearing what you think about this approach! :-)

[szh]

I really like this so far. I'd prefer if you could squash it all into one commit. I still need to read it more closely but I'm feeling optimistic about it.

[ZMelliti]

@szh I have squashed all changes into a single commit and updated the pull request description for improved clarity.

[szh]

@mackowski can you please re-review?

[ZMelliti]

Hello @mackowski, just checking in to see if you have any feedback :-)

[ZMelliti]

@mackowski thank you very much for the detailed and thoughtful feedback. I completely agree that the topics covered—such as centralized policy enforcement, authentication/authorization patterns, and tenant data segregation—are complex and rarely have a single “one-size-fits-all” solution. Your examples highlight that these areas require more nuance than the current draft provides.

My intention with this contribution was to establish an initial structure and capture commonly used patterns, with the expectation that we would refine the guidance collaboratively. Based on your comments, I see that the cheat sheet should more clearly articulate trade-offs, provide decision criteria, and align better with the related in-draft cheat sheets (Authentication, Authorization, Identity Propagation).

I’d be happy to expand the sections to include:

• Advantages and disadvantages of each pattern
• Clearer guidance on when each pattern is appropriate
• Cross-references to the other relevant cheat sheets
• Clarifications that options like separate database per tenant are context-dependent rather than default recommendations

If you feel this content is still too early for release, I’m also open to moving it into the draft section so we can continue refining it alongside the other in-progress cheat sheets. Please let me know what you think is the best path forward.

@jmanico and @szh since you expressed that the contribution was valuable, I’d also be interested in hearing your thoughts. Your perspectives might help us converge on the right next steps.

I appreciate everyone’s time and look forward to improving this together.

[szh]

I think we need to balance @mackowski concerns about things being too shallow with the overarching goal of keeping cheat sheets short and concise. It's a hard balance. Maybe part of it is being clear that each section is just a brief overview of the topic and linking to other resources for deeper study.

[jmanico]

I think we need to balance @mackowski concerns about things being too shallow with the overarching goal of keeping cheat sheets short and concise. It's a hard balance. Maybe part of it is being clear that each section is just a brief overview of the topic and linking to other resources for deeper study.

I agree, and when a sheet is too large, that's a good sign we need to break it into smaller cheat sheets..

[ZMelliti]

Hello @mackowski, @szh and @jmanico, thank you for the helpful feedback.

I took additional time on this revision to carefully balance the raised concerns with overall clarity, scope, and OWASP cheat sheet guidance. The update strengthens defense-in-depth messaging, clarifies federation and authorization boundaries, improves service-to-service and PoP guidance, and adds API-specific risk considerations (notably GraphQL), while keeping the content architectural rather than implementation-focused.

Thanks again for the review — it materially improved the quality of the document.