Engagement record
- Sector
- Internal workforce management platform at a software company
- Scope
- Web application, roles and supporting API
- Headline findings
- Authentication bypass, leave-record manipulation, access-control flaws
- Reachable by
- Any authenticated standard user
- Outcome
- Full report delivered to engineering with corrected patterns
- Confidentiality
- Client not named; findings described by class
Context
Internal tools are consistently the least-tested software an organisation runs, on the reasoning that only employees can reach them. That reasoning holds exactly until one employee account is phished, or one contractor keeps access after a project ends.
This platform handled the things internal tools usually handle (people, leave, approvals, records), which makes every access-control gap a personnel data problem as well as a security one.
Approach
Feature map before vulnerability map
Roles, approval chains and record ownership were mapped first. Only once the intended rules were understood could deviations from them be recognised: an authorisation gap is a deviation from intent, and intent has to be read.
Every role against every action
Each role was tested against each action rather than spot-checked, with particular attention to the gap between what the interface hides and what the API enforces.
Approval flows as transitions
Submit, approve, reject, amend and withdraw were tested as transitions, including out-of-order sequences a person would never produce by clicking.
The interface hid the admin routes. The API answered anyway.Report, access control section
What was found
Findings are described by class and impact. Reproduction detail stays in the client’s report, a case study that hands a reader a working attack against a former client is a breach, not marketing.
| Class | What it meant |
|---|---|
| Authentication bypass | A path that reached authenticated functionality without completing the intended authentication sequence. |
| Horizontal access control | Records belonging to other users readable and modifiable by a standard account. |
| Business logic | Leave records manipulable outside the approval chain the workflow implied. |
| Function-level authorisation | Administrative operations callable by non-administrative accounts. |
Outcome
Each finding arrived with the vulnerable pattern, the exploit path and the corrected implementation for the team’s own framework, rather than a link to a generic reference page. Engineering shipped fixes and each was verified by retest.
This engagement is the clearest example of the sector pattern noted on the SaaS page: the application was well built and functionally well tested, and the findings sat in the places functional testing was never going to reach.
Questions
Why do extra user roles increase what a SaaS penetration test costs?
Each extra role adds cost because penetration testing effort scales with roles and ownership boundaries, not with page count. On an internal SaaS platform we tested, every role was put against every action rather than spot-checked, and approval flows were walked as transitions. One more role multiplies that matrix rather than adding to it.
How long does a penetration test take for a multi-role SaaS platform?
Five to fifteen working days for the application and its API, plus two to three days of reporting, with a multi-role platform at the upper end of that range. The schedule tracks role and action combinations rather than screen count. One internal platform we tested covered the web application, its API and a source code review.
Do internal tools and admin dashboards need penetration testing?
Yes, internal tools and admin dashboards need testing, and they are the least-tested software most organisations run, on the reasoning that only employees can reach them. That reasoning holds until one account is phished, or a contractor keeps access after a project ends. On an internal platform we tested, an authentication bypass was reachable by any authenticated standard user.
Why can a SOC 2 audit pass while a penetration test still finds broken access control?
A SOC 2 audit confirms that a logical access control exists and operates as described, criterion CC6.1; a penetration test attempts to break the boundary, so the two produce different evidence. On a SaaS platform we tested, records belonging to other users were readable and modifiable from a standard account.
We hide admin features in the UI. Is the API still at risk?
Hiding an admin feature removes the button, not the endpoint, so the API is still at risk unless it enforces the rule the interface implies. That gap is broken function-level authorisation, API5 in the OWASP API Security Top 10. On an internal SaaS platform we tested, administrative operations stayed callable by non-administrative accounts.
How do you test tenant isolation in a multi-tenant SaaS platform?
Tenant isolation is tested from the other side of the boundary: ownership is mapped first, then one account’s identifiers are read and changed from an account in a second tenant. Two organisations with two accounts per role are asked for at scoping for that reason. On an internal platform we tested, the same boundary failed between users: other users’ records were readable and modifiable from a standard account.
Can a vulnerability scanner find broken access control, or does it need manual testing?
Scanners rarely find broken access control, the first category in the OWASP Top 10, because an authorisation gap is a deviation from intent, and intent has to be read first. A scanner cannot know which account should own a record, so IDOR and admin endpoints reachable by a standard user pass through. On one SaaS engagement the findings sat exactly there, in an application that was well built and well tested.