Postmortem: How We Missed an Unauthenticated API Data Leak

Monday Morning Alert: Suspicious Traffic

At 08:47, our SIEM flagged unusual activity on the customer API – 412 requests in 15 minutes to /v1/users/profile from a single IP. No 429 errors meant rate limits weren't triggered. First thought: "Another marketing team script gone wild."

Reality was worse. The endpoint returned:

1. Full names
3. Phone numbers
5. Password hashes (thankfully bcrypt)
7. Order history

8. ...with zero authentication. Just knowing the URL granted access.

   How This Passed Code Review

   Process failures we identified:

   1. Testing: Mock authorization existed but only checked for HTTP 200 status
   3. Documentation: Swagger marked the endpoint as "requires JWT" while the code ignored it
   5. Monitoring: Anomaly alerts for unauthorized requests were only added post-breach

   6. We'd dismissed a similar case in last year's report as "not applicable to our stack."

      Remediation Steps

      Beyond the obvious (hotfix, API audit, user notifications):

      • Implemented mandatory auth checks via pre-commit hooks
      • Added SIEM rules for authorized/unauthorized request ratios
      • Filed a CVE (yes, we're angry) against the framework that silently swallowed JWT errors

      • And yes, marketing finally got their dedicated endpoint with restricted data. After three attempts to explain that "we need everything" isn't a security rationale.