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.
Frequently asked questions
How long does a web application and API pentest take?
It depends on the number of applications, roles and endpoints, but a serious pentest of two or three applications and their APIs typically runs two to four weeks, plus the retest afterwards. This engagement took three weeks for three applications and their APIs. A two-day pentest over that scope isn't a pentest — it's a scan by another name.
Can a pentest take down production or affect my customers?
The risk exists and is managed: a controlled methodology, agreed testing windows, a direct channel to the technical teams, and destructive tests only with explicit authorisation. In this case we worked directly against production within agreed windows, with no incidents. A serious provider explains before starting what will be tested, when, and with which safeguards.
What do you get at the end of a pentest?
A technical report with every finding documented (business impact, reproducible evidence and concrete remediation), an executive summary suitable for management or third parties requiring the test, and a follow-up retest that verifies the findings have been closed. Critical vulnerabilities are reported as soon as they are confirmed, without waiting for the final report.
How often should a pentest be repeated?
At least once a year, and additionally after significant changes: new internet-facing functionality, third-party integrations, migrations or a change of development provider. Many customers and manufacturers require a test no older than twelve months, so an annual cadence also covers the commercial requirement.
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.