Edge Case Analysis: Password Reset Feature

Current AC Coverage: 30% (happy path only, missing critical security, error handling, and abuse prevention edge cases)

---

Missing Edge Cases Identified (14 cases)

Category: Empty/Null States

Edge Case 1: What if user submits empty email field? 🔴 HIGH PRIORITY
Current Status: Not defined
Suggested AC:

• “Reset button is disabled when email field is empty”
• “If somehow submitted empty, show error: ‘Email address is required’”
• “Empty field is highlighted with red border”

Why Important: Basic validation prevents unnecessary server calls and improves UX

---

Category: Input Validation

Edge Case 2: What if email format is invalid? 🔴 HIGH PRIORITY
Current Status: Not defined
Suggested AC:

• “Validate email format client-side (must contain @ and valid domain structure)”
• “Show error below field: ‘Please enter a valid email address’”
• “Disable reset button until email is valid format”

Why Important: Prevents API calls with invalid data, improves user experience

---

Edge Case 3: What if email contains SQL injection or XSS attempts? 🔴 CRITICAL PRIORITY
Current Status: Not defined (security risk)
Suggested AC:

• “All email inputs are properly sanitized server-side”
• “Use parameterized queries to prevent SQL injection”
• “Escape special characters to prevent XSS”
• “Log suspicious input patterns for security monitoring”

Why Important: Critical security requirement to prevent attacks

---

Edge Case 4: What if email is extremely long (500+ characters)? 🟡 MEDIUM PRIORITY
Current Status: Not defined
Suggested AC:

• “Email field has maximum length of 255 characters”
• “Show error if exceeded: ‘Email address is too long’”
• “Prevent additional character input beyond limit”

Why Important: Prevents potential buffer overflow or database issues

---

Category: Error Scenarios

Edge Case 5: What if email doesn’t exist in system? 🔴 CRITICAL PRIORITY
Current Status: Not defined (security vulnerability)
Suggested AC:

• “Show generic success message even if email doesn’t exist: ‘If this email is in our system, you will receive a reset link shortly’”
• “Do not reveal whether email exists in database”
• “Send confirmation with same timing regardless of email existence”

Why Important: Security - prevents email enumeration attacks where attackers discover valid user emails

---

Edge Case 6: What if email service fails to send the reset link? 🔴 HIGH PRIORITY
Current Status: Not defined
Suggested AC:

• “If email service fails, show generic success message to user (don’t reveal failure)”
• “Log email delivery failure with full error details for ops team”
• “Queue email for retry (3 attempts over 15 minutes)”
• “Alert ops team if retries fail”

Why Important: Prevents service outages from blocking users; maintains security posture

---

Edge Case 7: What if email server is down or unreachable? 🔴 HIGH PRIORITY
Current Status: Not defined
Suggested AC:

• “System continues to show success message to user”
• “Queue reset request for when service recovers”
• “Trigger monitoring alert for email service outage”
• “Reset requests expire after 24 hours if undeliverable”

Why Important: Graceful degradation; maintains user confidence during outages

---

Edge Case 8: What if reset token generation fails? 🔴 HIGH PRIORITY
Current Status: Not defined
Suggested AC:

• “Show error: ‘Unable to process password reset. Please try again shortly.’”
• “Log token generation failure with stack trace”
• “Do not save partial reset record to database”

Why Important: Prevents stuck states where user expects email that will never arrive

---

Category: Concurrent/Conflict Scenarios

Edge Case 9: What if user requests multiple reset links rapidly? 🔴 CRITICAL PRIORITY
Current Status: Not defined (abuse potential)
Suggested AC:

• “Rate limit: Allow 1 reset request per email address per 5 minutes”
• “If limit exceeded, show: ‘Password reset already requested. Please check your email or try again in X minutes.’”
• “Don’t invalidate existing valid token when new request is blocked”
• “Log excessive reset attempts for security review”

Why Important: Prevents spam, abuse, and email bombing; reduces server load

---

Edge Case 10: What if user requests reset while previous token is still valid? 🟡 MEDIUM PRIORITY
Current Status: Not defined
Suggested AC:

• “New reset request invalidates all previous reset tokens for that email”
• “Send new reset email with fresh token”
• “Show message: ‘A new password reset link has been sent’”
• “Previous reset links show error: ‘This reset link has expired. Please request a new one.’”

Why Important: Security - ensures only most recent reset attempt is valid

---

Edge Case 11: What if user clicks reset link after already resetting password? 🟡 MEDIUM PRIORITY
Current Status: Not defined
Suggested AC:

• “Token is invalidated immediately after successful password reset”
• “If user clicks expired token, show: ‘This reset link has already been used or has expired’”
• “Provide link to request new reset or to login page”

Why Important: Prevents confusion and potential security issues with reused tokens

---

Category: Boundary Conditions

Edge Case 12: How long is the reset link valid? 🔴 CRITICAL PRIORITY
Current Status: Not defined (security requirement)
Suggested AC:

• “Reset tokens expire after 1 hour from generation”
• “If user clicks expired link, show: ‘This reset link has expired. Reset links are valid for 1 hour.’”
• “Provide ‘Request New Reset Link’ button on expired page”
• “Include expiration timestamp in reset email”

Why Important: Security best practice; limits window for token compromise

---

Edge Case 13: What if user’s account is locked, suspended, or deleted? 🔴 HIGH PRIORITY
Current Status: Not defined
Suggested AC:

• “Show same generic success message regardless of account status”
• “Do not send reset email for suspended/deleted accounts”
• “For locked accounts, send email explaining account is locked with support contact”
• “Log reset attempts on non-active accounts for security review”

Why Important: Security - prevents account enumeration; provides appropriate support path

---

Category: Network/Performance

Edge Case 14: What if reset request takes very long (slow connection)? 🟡 MEDIUM PRIORITY
Current Status: Not defined
Suggested AC:

• “Show loading spinner on ‘Send Reset Link’ button during request”
• “Disable button to prevent duplicate submissions”
• “Timeout after 30 seconds with error: ‘Request timed out. Please try again.’”
• “Re-enable button after error or timeout”

Why Important: Prevents double submissions and user confusion during slow network

---

Priority Summary

CRITICAL/HIGH (10 cases) - Must address:

• Email doesn’t exist in system (security - email enumeration)
• SQL injection/XSS prevention in email input
• Rate limiting for reset requests (abuse prevention)
• Reset token expiration time (security)
• Email format validation
• Empty email validation
• Email service failure handling
• Email server outage handling
• Token generation failure
• Account status handling (locked/suspended/deleted)

MEDIUM (4 cases) - Should address:

• Multiple tokens for same user (token invalidation)
• Reused/already-used tokens
• Extremely long email addresses
• Network timeout and loading states

---

Coverage Improvement

Before: 3 acceptance criteria (happy path only)
After: 17 acceptance criteria (3 original + 14 edge cases)

Estimated Bugs Prevented: 12-15 (including critical security vulnerabilities and abuse vectors)

Recommended Next Steps:

1. URGENT: Review security edge cases with engineering and security team (email enumeration, rate limiting, token expiration, injection prevention)
2. Add CRITICAL/HIGH priority cases to acceptance criteria immediately
3. Implement rate limiting and abuse prevention before launch
4. Set up monitoring for reset request patterns and email delivery failures
5. Document incident response for email service outages
6. Consider adding email confirmation or secondary verification for sensitive accounts
7. Test edge cases with security/penetration testing tools