Plaid Integration Penetration Testing
Plaid confirms which account a user linked, but your app decides who that access token actually belongs to. We test that mapping, the token exchange and the webhook listener behind it. CREST-certified testers, fixed price from £3,860 for a 3-day single-integration scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
An Item is Plaid’s record of one login at one institution. Nothing in Plaid’s API ties it to a user in your own system, your application makes and enforces that link.
Which of your users an access token belongs to is your application’s decision, not Plaid’s
When a user finishes Plaid Link, your backend calls /item/public_token/exchange and gets back an access_token and an item_id for that one login. Plaid does not attach either to a user in your own system. The client_user_id you pass when creating the link_token is, in Plaid’s own documentation, used as a means of searching logs for the given user in the Plaid Dashboard, not as an access control on the resulting Item. If your backend stores the access_token against the wrong session, or against no session at all, nothing in Plaid’s API catches that.
The exchange only works with your client_id and secret, so it has to happen on your server, not in the browser or a mobile app. Plaid’s Link flow documentation sets out the sequence: your backend calls /link/token/create for a link_token that expires after 4 hours, or 30 minutes in update mode, Link returns a public_token that itself expires after 30 minutes, and only a server holding your credentials can turn that into a permanent access_token. Where that access_token then lives, whether it reaches a log line, an error response or client-side state, is entirely down to your build.
Plaid signs every webhook with a JWT carried in the Plaid-Verification header, and its own webhook verification guide states plainly that checking it is optional. A listener that skips verification acts on whatever item_id and webhook_code it is sent, without confirming the message actually came from Plaid, that it is not more than five minutes old, or that its request_body_sha256 claim matches the body received. Sandbox and Production sit on separate hosts with separate keys, and an Item created in one cannot move to the other, so which environment a given client_id, webhook payload or stored token actually belongs to is worth checking on its own.
SCOPE
What we pen test on a Plaid integration
User-to-Item binding
Whether the access_token and item_id returned by /item/public_token/exchange are stored against the authenticated session that started Link, rather than a client-supplied user or item ID, and whether one user can reach another user’s Item by guessing or submitting its identifier.
Server-side token exchange
Whether /link/token/create and /item/public_token/exchange are only ever called from your backend using your client_id and secret, and whether a public_token or access_token is generated or exchanged anywhere in client-side or mobile code where those credentials could leak.
Access token storage and exposure
How access_tokens are stored at rest, who and what can read that table or secret store, and whether a token ever reaches application logs, error responses or client-side state, given that Plaid access_tokens do not expire on their own.
Webhook signature verification
Whether your listener validates the Plaid-Verification JWT against the ES256 key from /webhook_verification_key/get, rejects a JWT whose iat is more than five minutes old, and checks request_body_sha256 against the actual body with a constant-time comparison, rather than acting on the item_id and webhook_code it is sent.
Client ID and secret handling
Whether the client_id and secret used in the PLAID-CLIENT-ID and PLAID-SECRET headers ever reach browser or mobile code, how they are stored and rotated, and what an exposed client_id alone actually grants an attacker compared with the secret.
Sandbox and Production separation
Whether a Sandbox client_id, secret or test Item can reach Production code paths or vice versa, since Plaid Items cannot move between environments, and what your webhook listener or product logic does if it receives an event meant for the other environment.
Linked financial data exposure
Whether the accounts, balances, transactions or identity data your application requests from Plaid are returned only to the user who linked them, and whether an authenticated user can reach another user’s linked financial data by changing an account, item or user identifier in a request.
Duplicate and re-linked Items
Whether your application detects a user linking the same institution login a second time, and whether the resulting Items and access_tokens all end up correctly scoped to that one user rather than left as separate, ambiguously owned credentials.
Item removal and revocation
Whether disconnecting an account in your application actually calls /item/remove and invalidates the stored access_token, or leaves a token that still works against Plaid’s API after the user believes the connection has ended.
Consent scope and re-authentication
Whether your integration requests only the products and data scopes it uses, checks an Item’s consent_expiration_time, and routes a user through Link’s update mode when an Item enters an ITEM_LOGIN_REQUIRED state rather than silently retrying against a dead token.
OUR PROCESS
Plaid Integration Penetration Testing: From Scope to Attestation
Scope the integration
We list every Plaid touchpoint in your application: Link initialisation, the token exchange, your webhook listener and every place an access_token is stored, and confirm which client_id and secret belong to Sandbox and which belong to Production.
Test against Sandbox first
Item creation, token exchange, webhook and consent logic are tested against Plaid’s Sandbox test institutions wherever the check allows; anything that genuinely needs live Production is agreed with you first and run read-only.
Exploit the integration logic
CREST-certified testers chain findings across the Item, token and webhook flow, covering forged webhooks, exposed credentials, cross-user Item access and stale-consent handling, rather than relying on scanner output alone.
Report and retest
Executive summary, technical report with CVSS scores and reproduction steps, a walkthrough call, free retest after remediation, and an attestation letter.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Plaid pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Plaid Integration Penetration Testing Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
3 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote6 to 8 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Plaid For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Plaid Integration Penetration Testing
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need?
Sandbox client_id and secret for the integration under test, plus Plaid’s default Sandbox institution logins. We do not need your live Plaid Dashboard login or production secret, and only need scoped, read-only production access where a specific check genuinely requires it.
Does this touch live Plaid accounts or real financial data?
No, wherever the check allows. Plaid’s Sandbox environment supports the full API and Link flow against test institutions, so Item creation, token exchange, webhook events and consent flows can all be run without touching a real bank account. Anything that must run against live Production is agreed with you in advance and scoped tightly.
How long does a Plaid integration test take?
A single integration is a 3-day scope. Multiple Plaid products in the same flow, such as Auth alongside Transactions and Identity, several linked institutions per user, or a second open banking provider sitting alongside Plaid, add testing days, which we agree before the engagement starts.
We use Plaid’s hosted Link UI, not a custom flow. Is there still anything to test?
Yes. Link handles the bank login screen, but the token exchange, webhook verification, access_token storage and which of your users an Item is attached to are still your backend’s code, and that is where the risk sits regardless of how Link itself is presented.
What is out of scope?
Plaid’s own infrastructure, its bank connections and its fraud and risk systems are out of scope. We test the integration your team built: your token exchange, webhook listener, credential handling, consent logic and user-to-Item mapping, never Plaid’s platform itself.
Does Plaid have a policy on this kind of testing?
Plaid runs its own vulnerability disclosure programme for its platform, published via a security.txt file and HackerOne, which covers Plaid’s infrastructure rather than a customer’s integration. We test against your Sandbox credentials for exactly that reason, and confirm Plaid’s current developer terms for any check that would need live Production access before it is scoped in.
Do you test other Plaid products, like Identity or Transactions, as well as Auth?
If your integration uses them, yes, they are scoped in alongside Item creation and webhooks. Tell us at quoting stage which Plaid products your application calls and which data scopes you request, so the scope and day count reflect what is actually integrated.
Our app shows linked balances and transactions to our own users. Do you test that?
Yes. We check whether the accounts, balances and transactions your application requests from Plaid are only ever returned to the user who linked them, and that no endpoint lets an authenticated user reach another user’s linked financial data by changing an identifier.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Plaid integration
Plaid confirms which account a user linked, but your app decides who that access token actually belongs to. We test that mapping, the token exchange and the webhook listener behind it. CREST-certified testers, fixed price from £3,860 for a 3-day single-integration scope, quoted within 24 hours.
