Each user type sees a different slice of the system
The platform connects patients and clinicians through intake, documentation and ongoing records. Each user type is meant to see and change a different slice of the system. That separation is the core security promise, and it has to hold for every endpoint, not just the ones the interface happens to show.
Authorization flaws are quiet
The product works, the screens look right, and nothing errors out. The gap only appears when someone calls a function their role should never reach, or reads a field the interface never displays.
Each role sees a tailored set of screens and actions. Anything outside that set looks unavailable.
Every endpoint answers any valid request. Whether it should is decided only by server-side checks.
Hidden buttons are not access control. Access control is what the server does when someone asks anyway.
Every role against every function
Map the application
Enumerate every user role, screen and API endpoint the platform exposes.
Assume every role
Test as a standard user and as a provider-level user, and attempt to act across the boundary between them.
Test every combination
Run each function against each role and record what the server actually allows.
Prove and report
Reproduce each issue with a clean request, confirm the impact, and report it with a fix path.
| Function | Standard user | Provider-level user |
|---|---|---|
| Own profile | Enforced | Enforced |
| Personal records | Violation | Enforced |
| Role changes | Violation | Enforced |
| Restricted settings | Violation | Enforced |
Green: the server correctly refused the request. Red: the server allowed it.
One root problem, four groups of findings
Almost every finding came from one root problem: the server trusted what the client sent or failed to check who was asking. The issues fell into four groups.
Self-service role elevation
A standard account could set fields that belong to the system, including the field that grants a higher-privilege role. No verification step stood between the request and the change.
Writes without a proven caller
Some write actions accepted requests with no credentials, and others did not confirm that the caller was linked to the record being changed.
Over-exposed responses
Responses returned more than the requesting role needed. This included restricted platform settings, personal contact details, and content meant only for trusted users.
Sensitive data in transit and logs
Session tokens carried more personal content than they needed, and those tokens travelled inside URLs that routinely end up in proxy and monitoring logs.
Two additional leads are still being verified and are not counted in the findings above.
Not a technical footnote
For a platform that holds sensitive personal information, an access control gap is not a technical footnote. A single self-service role change can expose records across the whole user base, including records shared within clinician groups. Unauthenticated writes can corrupt the audit trail that providers and regulators rely on. Exposed restricted values can be reused outside the product.
The cost of these issues is rarely the fix itself. It is the investigation, notification duties, customer trust, and the time spent explaining to partners why the product behaved this way in production.
The takeaway for healthcare platforms
For healthcare platforms that handle patient information, authorization has to be tested per role and per function, on every release. Passing a general scan is not evidence that it holds.
Find what your last pentest missed.
Perfai maps every role and endpoint in your application and tests each combination, so authorization gaps are found before they reach production.
Book a Perfai test →Case studies are summarized from authorized testing engagements. Client details have been withheld.