What is the proposed Cheat Sheet about?

Preventing business logic vulnerabilities — the class of flaws that no scanner will ever find for you, because they require understanding what the application is supposed to do.

I've been doing pentesting for a while now, and the findings that cause the most damage are almost never the SQLi or XSS stuff — it's the business logic flaws. Price manipulation in e-commerce. Skipping steps in a multi-step workflow. Race conditions that let you double-spend. Abusing referral systems. Bypassing approval processes by replaying requests out of order. These are the bugs that actually cost companies real money, and there's surprisingly little structured guidance out there on how to prevent them during development.

What security issues are commonly encountered related to this area?

This is a broad category, but the patterns come up over and over:

• Price and quantity manipulation: Changing prices client-side, negative quantities, applying discounts multiple times, tampering with cart totals. I've seen this in production at companies you'd expect to know better.
• Workflow/state bypass: Skipping from step 1 to step 5 in a checkout or application process. Accessing features that should only be available after verification. Submitting forms out of sequence.
• Race conditions: TOCTOU bugs in financial transactions, double-spending through concurrent requests, draining rewards points by hitting an endpoint simultaneously from multiple threads. These are especially nasty because they're intermittent and hard to catch in testing.
• Privilege escalation through business logic: Not IDOR exactly, but things like "a regular user can trigger an admin-only workflow by crafting the right sequence of API calls" or "you can approve your own request by manipulating the approval chain."
• Abuse of legitimate features: Referral fraud, coupon stacking, exploiting free trial logic, gaming loyalty programs. The feature works as coded but not as intended.

What is the objective of the Cheat Sheet?

Provide developers with practical patterns for building business logic that's resilient to abuse. Specifically:

• How to think about business logic security during design (threat modeling from the business process perspective, not just the technical one)
• Server-side validation patterns — never trust client-side state, always re-derive prices/totals/permissions on the backend
• State machine enforcement — how to properly implement multi-step workflows so users can't skip or replay steps
• Race condition prevention — locking strategies, idempotency keys, serializable transactions where they matter
• Rate limiting and abuse detection for feature-level abuse (not just authentication)
• Real-world examples of what goes wrong, because I think the concrete examples are what actually help developers internalize this stuff

The goal isn't to be exhaustive about every possible business logic flaw — it's to teach developers the mindset of thinking about how their features can be abused, along with the most common defensive patterns.

I'm willing to draft the PR for this one too if there's interest.

What other resources exist in this area?

• OWASP Testing Guide has WSTG-BUSL (Business Logic Testing), but again it's tester-focused. It tells you how to find these bugs, not how to prevent them in your code.
• The OWASP Top 10 mentions business logic tangentially but doesn't dedicate focused guidance to it.
• The existing cheat sheets cover adjacent topics (Authorization, Transaction Authorization, Input Validation) but none of them address the broader pattern of "how to make your business logic resistant to abuse."
• CWE-840 (Business Logic Errors) exists as a category but doesn't provide implementation guidance.
• There are scattered blog posts and conference talks about this, but no consolidated, practical reference from a trusted source like OWASP.

Honestly, I think this is one of the biggest gaps in OWASP's defensive guidance right now. Scanners keep getting better at finding technical vulns, but business logic flaws are the ones that will always require human understanding to prevent — and developers need a good reference for that.