In April 2021, KrebsOnSecurity reported that an Experian API used through a lender website could return credit-score information with insufficient access controls. The researcher said the API could be reached directly without authentication and that a placeholder date of birth value was accepted, allowing a lookup using largely public identity information. Experian said it confirmed a single instance involving a partner and resolved it. The incident is a useful case study in partner API design because the risk was not just one exposed endpoint—it was the possibility that the same integration pattern could exist across many downstream partners.
What was reported
Security researcher Bill Demirkapi discovered the issue while examining a lender site that performed eligibility checks. KrebsOnSecurity reported that the page invoked an Experian API and that the researcher could call the API directly without normal authentication. The lookup reportedly returned a consumer’s credit score and up to four risk factors.
Experian told KrebsOnSecurity that it confirmed one instance, alerted the partner, and resolved the matter. It also stated that the situation did not implicate or compromise Experian’s own systems. That distinction should be preserved: public reporting supports a partner-integration exposure, not a claim that Experian’s core infrastructure was broadly compromised.
Public identity data is not strong authentication
Name, mailing address, and date of birth are often treated as identity attributes. They are not strong authenticators because much of that information can be known, purchased, inferred, breached elsewhere, or socially engineered.
| Data element | Useful for | Not sufficient for |
|---|---|---|
| Name | Record matching | Authenticating a high-risk financial lookup |
| Address | Disambiguation and delivery | Proof of exclusive identity control |
| Date of birth | Matching and eligibility logic | Secret knowledge factor |
| Credit score | Sensitive output | Something that should be returned without strong access control |
Partner APIs need controls that survive a weak client
A secure financial API should assume a partner’s front-end code can be inspected and that requests can be replayed outside the official website. Browser JavaScript, mobile apps, and public HTML are not trusted enforcement points.
- Authenticate the partner or workload at the server-to-server boundary.
- Bind requests to an approved client, purpose, scope, and environment.
- Do not rely on hidden form fields, client-side logic, or obscured endpoints.
- Enforce consumer consent and identity-verification rules in trusted backend systems.
- Use per-partner credentials so one integration problem does not expose the entire ecosystem.
One vulnerable partner can reveal a systemic design problem
The researcher’s concern, according to KrebsOnSecurity, was that fixing a single lender endpoint might not answer whether the same API pattern was exposed through other partners. This is an important third-party architecture lesson: a weakness can live in the shared integration contract even when it is first discovered at one customer.
Providers should be able to inventory every client using a sensitive API, identify authentication and version differences, and revoke or constrain individual clients without affecting the rest of the ecosystem.
Return the minimum financial data required
The API reportedly returned not only a credit score but also risk factors explaining aspects of the score. Sensitive financial APIs should define the smallest data response needed for the specific business purpose.
- Separate eligibility results from full score or risk-factor details where possible.
- Use field-level authorization for partner tiers and consumer-consent states.
- Avoid returning raw sensitive values if a yes/no or category result is sufficient.
- Log which partner retrieved which data class and why.
- Review response expansion as carefully as new endpoints.
Detect automated lookup and enumeration
Even after strong authentication is added, a compromised partner credential can be abused. Runtime controls should monitor query volume, distinct consumers accessed, failure/success ratios, geographic and network changes, and differences from the partner’s historical usage.
Volume anomaly
A lender suddenly queries far more consumers than its normal workflow.
Population anomaly
One credential begins accessing a broader geography or demographic set.
Timing anomaly
Bulk calls occur outside expected business windows.
Response anomaly
The partner starts using higher-sensitivity endpoints or fields it rarely accessed before.
Security responsibility must be explicit across the provider–partner boundary
Sensitive data providers should define technical security requirements in the integration program, not leave each partner to improvise. That includes credential storage, server-side request origination, logging, breach notification, test environments, version lifecycle, and offboarding.
- Issue unique credentials per partner and environment.
- Define which flows require consumer authorization or stronger verification.
- Continuously validate that the API is not callable from unauthorized contexts.
- Monitor partner behavior and set contractual security expectations.
- Provide a rapid revocation path for compromised or noncompliant integrations.
- Retire legacy API versions that cannot meet current controls.
Practical lessons from the Experian API exposure
- Do not use publicly knowable identity attributes as the primary security boundary.
- Treat partner front ends as untrusted and enforce security server-side.
- Inventory all consumers of shared sensitive APIs.
- Use per-partner credentials, scopes, and behavioral baselines.
- Minimize sensitive fields returned to each integration.
- Test APIs directly rather than assuming the official UI constrains requests.
- When a partner exposes a weakness, investigate whether the integration pattern is systemic.
Frequently asked questions
What happened in the Experian API leak?
KrebsOnSecurity reported in 2021 that a partner website exposed access to an Experian API in a way that allowed credit-score lookups with inadequate authentication. Experian said it confirmed one instance involving a partner and resolved it.
Was Experian’s core network breached?
Experian stated that the reported situation did not compromise its systems and described it as a partner-related instance. Public reporting should not be expanded into claims beyond that evidence.
Why was date of birth not enough?
Date of birth is an identity attribute, not a strong secret. Financial APIs should use stronger authentication, authorization, consent, and purpose controls.
What is the biggest partner-API lesson?
Controls must be enforced at the trusted server boundary and should remain secure even if a partner website, mobile app, or client code is inspected or manipulated.
How can providers limit systemic partner risk?
Use unique credentials, narrow scopes, version governance, partner inventories, monitoring, revocation, and recurring security validation across the entire integration ecosystem.
Sources and further reading
- KrebsOnSecurity — Experian API Exposed Credit Scores of Most Americans — primary contemporaneous reporting of the API exposure and Experian statement
- OWASP API2:2023 Broken Authentication — authentication risk context
- OWASP API10:2023 Unsafe Consumption of APIs — third-party API trust context
- OWASP API Security Top 10 — 2023 — broader API security framework
Protect APIs with runtime context, not just static rules
Ammune helps security teams discover APIs, understand normal behavior, detect abuse and authorization anomalies, and apply runtime protection across modern API environments.