The practice
A multi-site allied health practice with a booking and records platform a developer built for them some years ago. It works, the staff like it, and it holds appointment histories and clinical notes for tens of thousands of patients.
They came to us because an enterprise client wanted evidence of testing before renewing a contract. That is how most first penetration tests get commissioned: not because somebody was worried, but because somebody else asked.
This file is a composite, and it is not the engagement in our published sample report. The findings here are lettered rather than numbered so the two cannot be confused.
What the scan had already said
They had run an automated scan the year before. It found both of the issues in this story and rated them, accurately by its own logic, as low and medium.
Nobody fixed either one. That was not negligence. It was triage. The report had forty-odd findings, the two criticals got fixed, and a low-severity information disclosure sat where low-severity findings always sit, which is at the bottom of a list nobody returns to.
The two findings
Finding A, rated low. When a sign-in failed, the error message distinguished between “no account with that email” and “wrong password”. Textbook account enumeration: it tells anyone trying addresses which ones are real accounts. That does not let them in. It does make password guessing, and the reuse of passwords leaked from other breaches, far more practical, because the attacker is no longer guessing at accounts that do not exist.
Finding B, rated medium. Patient records were fetched by a numeric identifier in the request, and the server checked that you were signed in but never checked that the record belonged to you. Change the number, get somebody else’s record. Rated medium by the scanner because it requires an authenticated session.
What testing actually demonstrated
The scope authorised authenticated testing, and the practice supplied a low-privilege test account for it, the same kind of account any ordinary user holds. Using that account, we changed the record identifier in a request and the server returned another patient’s clinical record. We repeated it for two more records and stopped at three, which was enough to demonstrate it.
That is a serious finding on its own. One signed-in account, with no special privileges, could read other patients’ clinical records, and the only barrier was that nobody had tried changing a number.
We did not demonstrate how an outsider would come to hold an account, and the report did not claim it. What Finding A adds is exposure: it narrows a password attack to accounts that genuinely exist, so a weak or reused password on any one of them becomes the way in to Finding B. The scanner treated the two as unrelated. They are not.
Why the ranking changed
In our report Finding B was not medium. It was the first thing in the executive summary, because we rank by what it would cost this business rather than by what the tool scored it.
For an allied health practice, unauthorised access to clinical records is not an IT problem with an IT-sized consequence. Confirmed access of that kind has to be assessed under the Notifiable Data Breaches scheme, and it can mean a report to the regulator, letters to patients, and a conversation with the enterprise client who asked for the test in the first place.
The remediation advice was correspondingly specific: enforce the ownership check server side on every record request, stop treating identifiers as a secret, make the sign-in error generic, and log repeated failed ownership checks so the next attempt is visible while it is happening.
What happened next
The practice fixed both in under a fortnight. The ownership check was, as it usually is, a small change in one place that should have been there from the beginning.
We retested the reported findings and reissued the report showing both verified closed, which is the document their enterprise client actually wanted.
The point of the story
An automated scan is a good and necessary starting point, and we run one at the start of every engagement. What it cannot do is check whether the server enforces who may see what, or reason about what two findings mean together in your business. A person testing by hand verified the authorisation flaw, showed its real impact, and explained why the low-rated finding beside it mattered. That is the manual part, and it is what you are actually buying.
The details above are a composite and the identifying details are changed. If you want to see how we write findings up before you commission anything, there is a redacted sample report from a different engagement, and the Security Assessments and Penetration Testing page walks through how an engagement runs.
