Unrestricted Access to Sensitive Business Flows
Sarah receives the BRD from the VP of Customer Experience and translates the business requirements into detailed functional requirements that the solution architect and development team can work with.
Translated from BRD-2024-0847
Complaint Form UI
Implement a web form with fields: Author (auto-populated from session), Comment (text area, max 500 chars), Rating (1-5 stars), and a Submit button.
CAPTCHA Integration
Display a math-based CAPTCHA challenge on the form. The user must solve the CAPTCHA before submission is allowed. CAPTCHA should be generated server-side.
API Endpoint
Create a POST /api/Feedbacks/ endpoint that accepts the complaint payload including captchaId, captcha answer, comment, rating, and author.
Database Storage
Store each complaint in the feedbacks table with auto-generated ID, timestamp, and all form fields. Assign a unique reference number.
Validation
Server-side validation: verify CAPTCHA answer matches the stored answer for the given captchaId. Reject submissions with incorrect CAPTCHA.
Structured form with proper field definitions
Server-side CAPTCHA generation and validation
Dedicated API endpoint with clear payload structure
Database persistence with unique reference numbers
Input validation for CAPTCHA correctness
No CAPTCHA lifecycle management
FR-02 says 'solve the CAPTCHA' but doesn't specify that the CAPTCHA must be invalidated after a single use. A solved CAPTCHA could be replayed indefinitely.
No rate limiting requirement
There's no functional requirement limiting how many complaints a user can submit per time period. An attacker could flood the system.
No abuse scenario consideration
The BA didn't consider what happens if someone automates the submission process — no requirement for detecting or preventing automated replay attacks.
No business flow protection
The complaint submission is a sensitive business flow, but there's no requirement to protect the flow itself — only the individual form fields.