What the Constructor.io incident illustrates
Constructor.io is a product search and discovery platform integrated into e-commerce and retail products. When a vendor at that layer of the stack is compromised, the exposure is not limited to the vendor's own data. It extends to every customer dataset that passed through their systems and every API credential that was shared with them.
This is the core problem with third-party integrations: you inherit their security posture without visibility into it. You can build excellent security into your own systems and still be exposed through a vendor you trusted.
How third-party API breaches actually cascade
The mechanism varies by how tightly integrated the vendor is. The three most common exposure patterns:
1. Data shared with the vendor is exposed
Any product data, user behaviour data, or PII you send to a third-party API through their SDK or direct API calls can be accessed by an attacker who has compromised the vendor's systems. For a search platform like Constructor.io, this typically includes search queries, product views, purchase events, and user identifiers used to personalise results. Depending on implementation, it can also include user email addresses or session tokens passed for identity.
2. The vendor's SDK becomes an attack surface
Frontend SDKs loaded from a vendor's CDN can be modified by an attacker who controls the vendor's infrastructure. A tampered SDK can exfiltrate keystrokes, form data, payment card numbers typed into your checkout, and session tokens. This is the Magecart-style supply chain attack pattern that has affected major retailers for years. Your Content Security Policy is your primary defence:
# A restrictive Content Security Policy blocks
# malicious SDK modifications from exfiltrating data
Content-Security-Policy:
default-src 'self';
script-src 'self' https://cnstrc.com;
connect-src 'self' https://ac.cnstrc.com;
img-src 'self' data:;
style-src 'self' 'unsafe-inline';3. API credentials held by the vendor are compromised
Some integrations require the vendor to hold your credentials (OAuth tokens, API keys to your systems) to enable features like product catalog sync or order updates. If the vendor is breached, those credentials are compromised. The question is whether you can detect the breach, revoke those credentials immediately, and whether the scope of those credentials was minimally scoped.
The audit questions to ask about every third-party integration
Third-party integration security audit checklist:
[ ] What data do we send to this vendor? (PII, session tokens, payment data)
[ ] Is the vendor's SDK loaded from their CDN or self-hosted?
[ ] Do we have a Content Security Policy that would contain a compromised SDK?
[ ] What API credentials does this vendor hold for our systems?
[ ] Are those credentials minimally scoped (read-only where possible)?
[ ] Can we rotate those credentials immediately if we get a breach notification?
[ ] Do we validate responses from this vendor's API before acting on them?
[ ] Is there a Data Processing Agreement in place?
[ ] Does our incident response plan include steps for vendor breach notification?For Nigerian fintech products specifically
Nigerian fintech products integrate with a significant number of third parties: BVN verification providers (Smile ID, YouVerify, Dojah), KYC data vendors, payment gateways (Paystack, Flutterwave, Monnify), telco APIs for OTP delivery, open banking aggregators (Mono, Okra, Stitch), cloud providers, and a range of analytics and monitoring tools.
Each of these is a potential entry point. The NDPA holds you responsible for the data your processors handle. A breach at a vendor does not transfer your regulatory liability to that vendor. You are still responsible for having selected them, scoped their access appropriately, and protected your customers' data.
The 72-hour checklist
1. Identify every credential you shared with the vendor. Rotate immediately. 2. Identify every category of data you sent to the vendor. Assess whether it constitutes personal data under NDPA. 3. If personal data was affected, assess whether you have a 72-hour NDPC breach notification obligation. 4. Review your audit logs for any API calls from the vendor's systems to your endpoints in the period of the breach. 5. Notify affected users if their data was exposed. 6. Document the response timeline. Your documentation of the response is as important as the response itself for regulatory purposes.
Want us to audit your third-party integration risk and data flows?
Talk to Our TeamFrequently asked questions
What was the Constructor.io breach?
Constructor.io, a product search and discovery platform used by e-commerce companies, disclosed a security incident involving unauthorised access to customer data. The incident highlighted the risk that a single compromised third-party vendor can expose data from every company that uses them.
How does a third-party API breach affect my product?
If a third-party vendor you integrate with is breached, attackers may gain access to API credentials your vendor held, customer data you shared with the vendor, behavioural or product data passed through the vendor's SDK or API, and in some cases the ability to inject malicious responses into your product through the compromised vendor.
What should I test regarding third-party integrations?
Test what data you send to each third-party API, whether API keys and secrets are rotatable and rotated on breach notification, whether the third-party SDK loaded in your frontend can exfiltrate data, and whether your backend validates responses from third-party APIs rather than trusting them unconditionally.
Related reading
Blog: Third-party vendor risk in fintech · KYC vendor security · Hardcoded API keys in mobile apps
Blog: How to report a data breach to the NDPC · CBN and NDPC breach reporting sequence
Services: Penetration testing · NDPA compliance