APPSEC-EXPERIAN-API-2021
API · Finance · Experian (Experian Connect API)
Summary
On 28 April 2021 KrebsOnSecurity reported that researcher Bill Demirkapi had found an unnamed student-loan lender's website performing credit checks via the Experian Connect API in a way that exposed the credit scores of tens of millions of Americans. The lender's loan-eligibility form took only a consumer's first name, last name, mailing address, and date of birth and used them to query Experian's API for an automated FICO lookup. The API enforced no meaningful authentication, and entering all zeros in the date-of-birth field still returned a result, so in practice only a name and address were required. For each consumer the API returned the credit score plus up to four 'risk factors' explaining why the score was not higher, which Demirkapi automated into bulk lookups. This maps to OWASP API2 Broken Authentication (no real auth on the endpoint, defeated by the date-of-birth bypass) combined with Excessive Data Exposure. Contrary to some accounts, no client-side API key was leaked; the flaw was missing authentication, not a leaked credential. Experian fixed the specific endpoint, while Demirkapi warned other lender integrations remained unsecured.
How to avoid it in your code
- Require strong server-side authentication on every credit-lookup endpoint; never expose a partner API that returns PII to unauthenticated callers.
- Validate and reject sentinel inputs like all-zero dates of birth instead of treating them as a passing identity check.
- Enforce identity verification with enough factors that knowing a name and address alone cannot return a score.
- Return only the minimal fields the caller is authorized to see; do not include risk-factor explanations by default.
- Add rate limiting and anomaly detection to block automated bulk credit-score enumeration.
References
Related vulnerabilities
All AppSec →- CRITICALAPPSEC-OPTUS-2022
On September 22, 2022 Australian telco Optus disclosed a breach exposing the personal data of around 9.8 million current and former customers (the figure regulators later litigated as approximately 9.5 million), including names, dates of birth, addresses, phone numbers, email addresses, and passport, driver licence and Medicare numbers. The data was served by an internet-facing API endpoint (api.www.optus.com.au) that required no authentication, and customer records were keyed by a sequential, enumerable contactid. An attacker could iterate the identifier (contactId + 1) with a simple script and pull every customer record, combining broken/missing authentication with Broken Object Level Authorization via a user-controlled key. The ACMA alleged an access-control coding error introduced around 2018 weakened the API; Optus fixed the same flaw on its main domain in August 2021 but never on the exposed sub-domain. Regulators characterised the attack as not highly sophisticated.
- HIGHAPPSEC-PARLER-2021
Between 9 and 11 January 2021, as Parler was being deplatformed from Apple's App Store, Google Play and AWS following the 6 January Capitol riot, archivists led by the researcher known as donk_enby scraped roughly 99.9% of the platform before it went offline, capturing on the order of 70 TB of data including about 1.1 million videos along with public posts, photos and user data. Parler exposed API endpoints that served public posts and raw media without requiring any authentication, and post and object identifiers were sequential, so the archivists simply incremented IDs to enumerate and harvest the entire site. There was no rate limiting, allowing high-speed bulk extraction, and media files were served raw with EXIF and GPS metadata intact, while deleted posts were only flagged as deleted rather than removed and remained retrievable. The core flaw maps to OWASP API1 Broken Object Level Authorization (sequential IDs with no authorization check) combined with API4 Unrestricted Resource Consumption from the missing rate limiting, with Excessive Data Exposure in the unstripped media metadata.
- HIGHAPPSEC-3FUN-2019
On 8 August 2019 Pen Test Partners (researcher Alex Lomas) publicly disclosed that the 3fun dating app, which claimed about 1.5 million users, was leaking the precise location and private profile data of its users. The app collected real-time GPS coordinates and let users hide their location, but that privacy setting was enforced client-side only, hidden purely in the mobile app interface. The server's API endpoint still returned each user's exact latitude and longitude plus private profile data including dates of birth, sexual preferences, chat information and private photos stored in Amazon S3, regardless of the user's privacy settings. Because an attacker could spoof arbitrary coordinates and read raw coordinates directly from the response, no trilateration was even necessary, and Pen Test Partners located users at the White House, US Supreme Court and 10 Downing Street. This is a classic Excessive Data Exposure flaw, the read side of Broken Object Property Level Authorization (OWASP API3:2023), where the server returns sensitive object properties the client should never receive and relies on the client to filter them. 3fun pushed a fix roughly a week after notification.
- CRITICALAPPSEC-FIRSTAM-2019
On 24 May 2019 KrebsOnSecurity disclosed that First American Financial Corp. had exposed roughly 885 million mortgage and title records dating back to 2003, including Social Security numbers, bank account numbers and statements, wire transaction receipts, mortgage and tax records, and driver's license images. The records were served by First American's EaglePro document system at sequential URLs containing a nine-digit document reference number. No authentication of any kind was required, so anyone holding a single valid link could simply increment or decrement the document number in the URL to retrieve any other customer's document. This is a textbook Broken Object Level Authorization / IDOR flaw (OWASP API1) compounded by complete Broken Authentication (OWASP API2), with a user-controlled object identifier and no authorization or login check. The defect was introduced in a May 2014 software update and was flagged by First American's own penetration test in January 2019 but left unremediated; researcher Ben Shoval reported it after the company failed to respond. New York DFS later brought a cybersecurity enforcement action (settled for $1 million) and the SEC settled disclosure-controls charges for $487,616.
- MEDIUMAPPSEC-SOURCEMAP-DISCLOSURE
A source map (.map) is a build artifact that maps minified bundle code back to the original source, and bundlers embed the full original code in its sourcesContent field. Left reachable in production or shipped inside a package, it hands anyone the unminified codebase, internal comments, hidden API endpoints, auth logic, and any secrets that were compiled in. Discovery is trivial: open DevTools and read the Sources tab, request the bundle's .map URL directly, or Google-dork for ext:map intext:webpack, then reconstruct the whole project with a tool like unwebpack-sourcemap. Passive scanners such as Acunetix and Burp already flag it as a standalone finding. It is usually rated medium on its own but escalates fast when the recovered source contains live credentials or undocumented endpoints; exposed Webpack source maps have leaked hardcoded Stripe secret keys that enabled unauthorized payments. High-profile cases include Apple's App Store web front-end in November 2025, shipped with source maps still enabled, and Anthropic's Claude Code, whose entire TypeScript source leaked via a source map left in a published npm package in March 2026.
- HIGHAPPSEC-GRAPHQL-ABUSE
GraphQL servers expose three abuse primitives stemming from the query language's flexibility. Leaving introspection enabled lets any client send a __schema query and recover the entire type system, including internal admin mutations and deprecated fields, providing a map of the attack surface (OWASP API8/API2). Because per-request rate limiters count one HTTP request regardless of operations inside it, an attacker can use field aliasing (e.g. attempt0:login(...), attempt1:login(...)) or array batching to pack dozens of login or verifyOtp mutations into a single request, brute-forcing credentials or short OTP/2FA codes while the rate limiter sees only one request; this aliasing-bypass technique is reproduced in the PortSwigger Web Security Academy 'Bypassing GraphQL brute force protections' lab and Wallarm's GraphQL batching research. Deeply nested or recursive queries cause an exponential explosion of resolver and database calls, exhausting CPU, memory and connection pools for denial of service, the core of OWASP API4:2023 Unrestricted Resource Consumption. HackerOne has disclosed a real GraphQL authentication-bypass finding, and Apollo Server v4 disabled array batching by default in response to these attacks.