Written by the people running the engagements.

Anonymised accounts of real assessments: the system, what we found, why it mattered, and what the fix was. Client detail is withheld under the terms of each engagement, so these describe the flaw and never the organisation.

• Case studyAnonymised

  One Missing Check, Total Exposure: How a Single API Flaw Exposed Every Record Across 3 Apps

  One number, changed in a request, returned a different member’s file. Then it let us edit that file, close it, and download the identity documents attached to it. It worked identically from the web app, the iOS app and the Android app, because the check that should have stopped it was missing from the one thing all three of them share - the API underneath.

  Updated 16 July 20267 min read
• Case studyAnonymised

  Verified by Whoever Asked: Account Takeover Before the Victim Ever Signed Up

  We registered an account on an address we did not own. The application asked the browser whether that address had been verified, believed the answer, and let us in. Nothing had to be intercepted, guessed or brute-forced - the victim had not signed up yet, and by the time they did, the account was already somebody else’s.

  Updated 28 July 20267 min read
• Case studyAnonymised

  Beyond the Login Screen: The FinTech Flow That Left Balances Unprotected After Sign-In

  Once a session existed, this application never asked for anything again. No second factor at the transfer, no confirmation tied to the payment, no limit on attempts, and a PIN short enough to work through rather than guess. Every control sat at the front door, so a live session was all that stood between whoever was holding the phone and somebody else’s balance.

  Updated 6 August 20267 min read
• Case studyAnonymised

  Turning the Rate Limit Against the User: The Invisible Vulnerability That Locks Out Any Account at Will

  The control was present, configured, and working exactly as designed. That was the finding. It counted requests against the customer being messaged rather than against whoever was asking - so anybody who knew a customer’s number could spend that customer’s allowance from anywhere, and the platform would then refuse to let its own customer in.

  Updated 19 August 20266 min read
• Case studyAnonymised

  The Breach That Looks Like a Bug: How Broken Authorisation Hides in a Support Queue

  One identifier, changed, cancelled a payment somebody else had scheduled. Another deleted the card they had saved. Neither leaves the victim any sign of an attack - both look exactly like the platform malfunctioning, which is why the half of an authorisation flaw nobody tests is also the half that costs the most.

  Updated 31 August 20266 min read

What to scope, what a standard actually requires, and what to do with the report when it arrives.

• Scoping

  How to scope a penetration test

  9 min read

• What a penetration test costs

  8 min read

• Vulnerabilities

  What a penetration test actually finds

  9 min read

• When rate limiting locks out your users

  7 min read

• When your API returns more than it shows

  7 min read

• A code at login is not authorisation

  7 min read

• The Host header is user input

  8 min read

• What logging out should actually do

  7 min read

• Root detection, pinning, and what they actually buy you

  8 min read

• Compliance

  SOC 2 and penetration testing

  9 min read

• PCI DSS penetration testing requirements

  10 min read

• ISO 27001 and penetration testing

  9 min read

• The audit evidence checklist for a penetration test

  11 min read

• Remediation

  How to read a penetration test report

  9 min read