The starting point
The group ran three internet-facing applications: the dealer-network portal, the customer area (workshop bookings, vehicle history, financing) and the APIs connecting them to the ERP. A manufacturer they were about to integrate with required a recent security test signed by a third party, and the group hadn't run one in years: development was outsourced to two different providers and nobody had the full picture.
How we approached it
A grey-box pentest — with credentials for the various roles, no source-code access — following OWASP methodology (WSTG for the web apps, API Security Top 10 for the services), in production with agreed windows and a direct channel to both development providers.
The two critical findings, described without exploitable detail:
- Insecure direct object references (IDOR) in the customer area — by manipulating identifiers it was possible to access other customers' personal and financing data. With no logging that would have allowed a prior abuse to be detected: impossible to know how long it had been exposed.
- File upload without effective validation in the dealer portal — chained with a server misconfiguration, it allowed code execution in the environment. Proven in a controlled manner and documented with reproducible evidence.
Each finding was delivered with business impact, reproducible evidence and concrete remediation addressed to the responsible provider — not a scanner dump, but a report both development teams could act on without back-and-forth. The critical findings were reported the same day they were confirmed, without waiting for the final report.
Results
14
documented vulnerabilities: 2 critical, 3 high, 6 medium, 3 low
72 h
from reporting the critical findings to their mitigation in production
100 %
of critical and high findings closed, verified in the retest six weeks later
The executive report served as evidence for the manufacturer and the integration went ahead on schedule. The group also adopted two deeper changes that came out of the pentest: access logging with alerts in the customer area, and contractual security requirements for its development providers.
What made it work
- With outsourced development, an independent pentest is the only objective picture: no provider audits its own code well.
- Reporting the critical findings in real time — not in the final report — cut weeks of real exposure.
- Retesting turns a pentest into demonstrable risk reduction, not a PDF ageing in a drawer.
Related services
When was your last pentest?
If your applications handle customer data and haven't had a serious test in years, there are probably findings waiting. Clear scope, actionable report and retesting included.