A marketing team connects a new email platform to the customer database with a couple of clicks, delighted at how quickly the integration works. Nobody in that moment is thinking about security, because the whole appeal of the connection is how effortless it feels. Yet that new integration has just created a door between two systems, built partly by your business and partly by a company you have never audited, and that door will remain open, largely unexamined, for as long as the integration stays active.
Every integration is a door built by someone else
Modern businesses connect dozens of third-party services together, payment processors, marketing platforms, booking systems, analytics tools, each one exchanging data through an API behind the scenes that customers never see directly. Every one of those connections extends your attack surface, whether or not your own team wrote a single line of the code involved. If the third-party service has a flaw, or if the credentials used to connect to it leak somewhere else entirely, your business inherits that risk the moment the integration goes live and starts moving data.
Few businesses maintain an accurate, current list of every external service connected to their systems, largely because these integrations tend to accumulate gradually, department by department, over several years without any central oversight. A thorough API pen testing specifically maps these connections and tests how they actually behave, rather than assuming that a third-party’s own security claims are automatically true for your particular setup.
Trusting an external service means inheriting its weaknesses too
The trust placed in these external services is rarely examined properly at the point of connection. A business will check that a marketing platform integrates smoothly and delivers the features it was promised, but will not always ask what happens if that platform itself is later breached, or whether the access it has been granted is broader than the specific task it was actually brought in to perform. An integration configured with far more permission than it genuinely needs sits there as unnecessary risk indefinitely.
William Fieldhouse regularly finds forgotten or over-permissioned integrations during assessments that nobody else remembered were still connected.
“We found an old booking-widget integration still had full read access to a client’s entire customer database years after the widget itself had actually been retired, because whoever removed it from the website never revoked the underlying access it had originally been granted.”
— William Fieldhouse, Director of Aardwolf Security Ltd
Nobody had acted maliciously in that situation, and nobody had even been careless in any obvious sense. The team that removed the widget from the website reasonably assumed that meant the connection was gone entirely, without realising that access permissions and the visible integration itself are two genuinely separate things that need to be dealt with independently. That gap between removing a feature and revoking its access is exactly where forgotten risk tends to accumulate quietly over time.
Knowing exactly what every connection can actually reach
Every third-party connection your business relies on was built, at least in part, by someone outside your organisation, using judgement and priorities you have never had the chance to review yourself. A proper penetration testing quote treats these integrations as seriously as anything built in-house, checking what each one can actually reach rather than trusting the sales page it was purchased from. Reviewing your current list of connected services is a sensible place to start before the next integration gets added.
