Anonymised engagements, real outcomes

Context. A banking partner made an independent penetration test a condition of going live. The platform had been built quickly by a small in-house team and had never been assessed by anyone outside it, with roughly six weeks left before the launch date.

Scope. Authenticated testing of the web application and its REST API across all four user roles, plus a review of the authorisation model behind them. Fixed in a signed statement of work: a mirrored pre-production environment running the same access-control code, no testing against live customer records, and no denial-of-service.

What we found. The headline issue was object-level authorisation: an authenticated business account could read another organisation's transaction history simply by changing an identifier in an API request. Alongside it, two medium issues in session handling and a low-severity information leak in error responses.

Outcome. The critical finding was fixed within days and verified in a free retest before launch. The partner's security review passed at the first attempt and the platform went live on the original date. The team now books an assessment ahead of each major release.

Engagement. Nine testing days · technical report and board summary · retest included.

Context. Fraudulent orders and suspected account takeovers climbed sharply going into a seasonal peak. Support was absorbing chargebacks and nobody could say whether the cause was leaked customer passwords, a flaw in the shop, or both.

Scope. Authentication, session management and checkout logic on the storefront, resistance to credential-stuffing, and the account-recovery flow. Separately, and with staff informed in advance, a consent-based phishing-awareness session for the whole company.

What we found. Neither login nor password reset was rate-limited, which made large-scale credential testing cheap for an attacker. Session identifiers were not rotated after sign-in, and a flaw in checkout allowed discount codes to be stacked beyond their intended limits.

Outcome. Rate limiting, session rotation and the checkout fix went in over the following fortnight, and automated login abuse fell away sharply. After the awareness session, staff began reporting suspicious email rather than deleting it quietly, which is the change that matters most.

Engagement. Seven testing days · half-day training · retest included.

Context. Enterprise prospects had started demanding evidence of independent security testing before signing. Two deals were stalled in procurement's security review, and the founders were answering the same questionnaire by hand each time.

Scope. A point-in-time penetration test of the multi-tenant application, focused on tenant isolation and the permissions model, plus a lightweight cloud configuration audit of identity, storage and logging against CIS benchmarks.

What we found. Tenant isolation held up under sustained testing, which was the answer the founders most needed. The real issues were in the cloud account: a service role with far broader permissions than its job required, a storage bucket readable by any authenticated user in the account, and audit logging switched off in one region.

Outcome. The company now has a report it can share under NDA, plus a remediation log showing what was fixed and when. Security reviews that used to take weeks close in days, and the same evidence fed straight into their ISO 27001 preparation.

Engagement. Six testing days · shareable report · annual retest cadence.

Context. A customer tracking portal and a set of partner integrations had accumulated over several years, built by different teams and suppliers. Nobody held a complete inventory of what was exposed to the internet, and none of it had been tested independently.

Scope. The external network perimeter, the tracking portal itself, and an access review of the API integrations shared with delivery partners. Where infrastructure sat with a hosting provider, we confirmed their authorisation in writing before starting.

What we found. A forgotten staging copy of the portal was reachable from the internet, running an outdated component and a database with test data closely resembling the real thing. One partner API key carried far more access than that integration ever used, and several management interfaces accepted connections from any address.

Outcome. The staging instance was decommissioned, partner keys were re-scoped and rotated, and management access moved behind the corporate VPN. The exercise also produced the asset inventory the operations team had been missing.

Engagement. Eight testing days · external and web · retest included.

Context. A platform handling patient records for a group of private clinics needed to demonstrate to its clients that access to health data was properly controlled — a question their own customers were asking with increasing precision.

Scope. Role-based access control across clinical, administrative and support accounts, the audit trail behind record access, and the export and reporting features. Testing ran entirely against a dataset of synthetic patients; no real health data was accessed at any point, which was written into the scope before we began.

What we found. Access control between clinics was sound. The gaps were narrower and specific: a support role could view records outside the cases assigned to it, exports were not written to the audit trail, and a reporting endpoint returned more fields than the interface displayed.

Outcome. The support role was tightened, exports now generate audit entries, and the reporting endpoint returns only what it needs to. The client uses the report as evidence in its own GDPR accountability file.

Engagement. Seven testing days · synthetic data only · retest included.