Clean at the edge, the risk all in the API. The server trusted the client to behave. 

• Six apps and one API, as one estate

  We tested every customer-facing app and the single API behind them together, from the outside, with the client’s authorisation — because an attacker would not treat them as separate products.

• Active, not just a scan

  Reconnaissance, TLS and configuration, injection testing, and the sign-in and one-time-code flows, including authorised credential and rate-limit testing against a top-level account.

25 findings, 6 of them high and none critical. Every high-severity issue was on the backend API, not the apps, and the thread through them was a server that trusted the client to behave.

• No brake on guessing

  Sign-in and the one-time code accepted attempt after attempt with no lockout, delay or limit. A top-level account stayed open after dozens of failures.

• A short code, unthrottled

  The one-time code was only a few digits, and nothing stopped a caller trying every value within its lifetime.

• A leftover that skipped the front door

  A left-behind test endpoint reached its handler without signing in; only the request method stood between a caller and it.

• Webhooks that trusted the caller

  Machine-to-machine webhooks ran for anyone who called them, with no check that the request really came from the integration partner.

• Cross-origin rules that said yes to everyone

  The API echoed back whatever site asked and allowed it to carry credentials, instead of naming the handful of sites it actually serves.

A fair assessment says what worked as well as what did not.

• Authentication itself was enforced

  The data endpoints refused anonymous and cross-account callers. The weaknesses were around sign-in, not in whether a token was required.

• No injection

  SQL and template-injection testing came back empty, and error responses leaked nothing about the stack behind them.

• The apps were behind a firewall

  The six web apps sat behind a web application firewall with sound transport settings; the gaps were specific to the API’s edge.

• A report written for the fixer

  Every finding reproduced and rated, with evidence and a specific fix, grouped so the team mends the API first.

• An honest boundary

  One round — access control for signed-in users — needed a working credential we did not have. We said so plainly and scoped exactly where the next pass picks up, rather than imply it was covered.