INSECURE MODE — CAPTCHA is NOT invalidated after use, no rate limiting
Phase 3Solution Architect — System Design

Solution Architect — James Rivera

James receives the functional requirements from Sarah and designs the system architecture for the Customer Complaint module. He must decide how the complaint flow integrates with the existing banking portal infrastructure.

Insecure Design — System Architecture

Customer BrowserComplaint Form
POST /api/Feedbacks/
API GatewaySecureBank Portal
Pass through
CAPTCHA ServiceValidate only
Answer correct? → proceed
Complaint ServiceProcess & Store
INSERT
Banking DatabaseFeedbacks Table

Architect's Design Decisions

CAPTCHA validates the answer against stored value

Standard validation — checks if user solved the math correctly

No CAPTCHA lifecycle management

CAPTCHA record remains valid after successful use — can be reused

No rate limiting on the endpoint

Any authenticated user can submit unlimited complaints

No request replay detection

Identical payloads are processed as new submissions each time

The Architectural Flaw

The architect designed the CAPTCHA as a one-time gate — solve it once and you're in. But the CAPTCHA was never designed to be invalidated after use. This means a single solved CAPTCHA can be replayed in the request body indefinitely. Combined with no rate limiting, an attacker can automate thousands of complaint submissions with one CAPTCHA solve.

This is API6:2023 — Unrestricted Access to Sensitive Business Flows