Add architectural threat modeling checklist for workflow and state abuse

checklists/checklists/Architectural_Threat_Modeling_Checklist_for_Workflow_and_State_Abuse.md

@@ -0,0 +1,101 @@
+# Architectural Threat Modeling Checklist for Workflow and State Transition Abuse
+
+## Overview
+
+Modern distributed applications frequently fail not because of traditional vulnerabilities, but due to architectural flaws in workflow enforcement, state management, and API orchestration. This checklist helps identify abuse cases where attackers manipulate valid sequences to bypass business controls.
+
+---
+
+## 1. State Transition Enforcement
+
+| Check | Description |
+|------|-------------|
+| ☐ | All business workflows have an explicit server-side state machine |
+| ☐ | Backend validates that transitions occur only from allowed previous states |
+| ☐ | State is never inferred from client input |
+| ☐ | State changes are atomic |
+| ☐ | Invalid or out-of-order transitions are rejected |
+| ☐ | State change failures are logged with high severity |
+
+---
+
+## 2. Multi-Step Workflow Validation
+
+| Check | Description |
+|------|-------------|
+| ☐ | Each workflow step has mandatory prerequisites |
+| ☐ | API endpoints enforce correct step ordering |
+| ☐ | Replay of previously valid steps is blocked |
+| ☐ | Tokens are scoped to workflow state |
+| ☐ | Workflow cancellation is fully enforced server-side |
+
+---
+
+## 3. API Sequence Integrity
+
+| Check | Description |
+|------|-------------|
+| ☐ | APIs require sequence tokens or state hashes |
+| ☐ | Server rejects API calls that skip intermediate steps |
+| ☐ | Cross-service calls verify upstream workflow state |
+| ☐ | Retry logic cannot advance state incorrectly |
+
+---
+
+## 4. Cross-Layer Authorization Consistency
+
+| Check | Description |
+|------|-------------|
+| ☐ | UI restrictions are never relied on for authorization |
+| ☐ | All hidden UI actions are verified server-side |
+| ☐ | API endpoints are reviewed for orphaned permissions |
+| ☐ | Role changes propagate across services in real time |
+
+---
+
+## 5. Distributed System Abuse
+
+| Check | Description |
+|------|-------------|
+| ☐ | Event-driven services validate ordering guarantees |
+| ☐ | Idempotency is enforced on state transitions |
+| ☐ | Partial failures cannot leave workflows in exploitable states |
+| ☐ | Asynchronous queues cannot be abused to bypass checks |
+
+---
+
+## 6. Telemetry and Detection
+
+| Check | Description |
+|------|-------------|
+| ☐ | Workflow state transitions are logged centrally |
+| ☐ | Alerts exist for impossible transitions |
+| ☐ | Telemetry detects API misuse patterns |
+| ☐ | Incident playbooks include workflow abuse scenarios |
+
+---
+
+## 7. Threat Modeling Coverage
+
+| Check | Description |
+|------|-------------|
+| ☐ | Threat models include abuse of valid sequences |
+| ☐ | Architecture reviews consider logic and workflow risks |
+| ☐ | Abuse cases are reviewed quarterly |
+| ☐ | Product teams test at least one workflow abuse scenario per release |
+
+---
+
+## Example Abuse Scenarios
+
+- Confirming orders without payment  
+- Approving refunds without prior authorization  
+- Skipping approval workflows via API  
+- Replaying legacy endpoints removed from UI  
+
+---
+
+## Objective
+
+Prevent attackers from abusing legitimate application flows to achieve unauthorized outcomes by enforcing architectural integrity across UI, API, and backend layers.
+

document/6-Appendix/Architectural_Threat_Modeling_for_Workflow_and_State_Transition_Abuse.md

@@ -0,0 +1,15 @@
+# Architectural Threat Modeling for Workflow and State Transition Abuse
+
+Modern application security failures increasingly arise not from traditional coding defects, but from architectural flaws in how workflows, APIs, and distributed services enforce business logic.
+
+Security testing tools are effective at detecting injection flaws and misconfigurations, but they rarely identify abuse scenarios that follow valid execution paths.
+
+In distributed and API-driven environments, attackers manipulate state transitions, replay legitimate tokens, and invoke backend functionality out of intended order. These attacks do not appear anomalous to scanners or WAFs because every individual call is technically valid.
+
+This class of risk—workflow and state-transition abuse—requires architectural threat modeling rather than vulnerability enumeration. Testing must begin by mapping application state machines and identifying required prerequisites before each action is authorized.
+
+For example, payment workflows often assume that the “confirm order” action can only occur after successful payment processing. In practice, many APIs accept confirmation requests based solely on token presence rather than verified transaction state.
+
+Security teams must therefore validate not only authentication, but whether the workflow is in the correct state for the requested operation. This requires server-side state machines, idempotency enforcement, and telemetry capable of detecting impossible transitions.
+
+As enterprises increasingly adopt microservices, asynchronous messaging, and event-driven designs, the attack surface expands beyond what traditional scanning tools observe. Embedding architectural threat modeling into development lifecycles is now a Tier-1 security requirement.