What First American’s $885M Leak Teaches API Teams
Explore the First American API breach — and how automated testing could have uncovered the data exposure early.
Note: This series aims to analyze and simplify breach and vulnerability reports that are usually cryptic and mostly written by legal. The simplified version hopes to educate and help security and engineering leadership avoid the same mistakes.
Company: First American Financial
Report Date: May 24, 2019
Vulnerable Data: 885M customer records
The complexity of hack: Medium
Vulnerability Type: Zero-Day Exploit. A common vulnerability that can existacross multiple endpoints.
Vulnerable Data
- Social Security Numbers
- Drivers licenses
- Account statements
- Corporate documents, etc.
Sample vulnerable endpoint/URLs
https://../documents?id=1001https://../documents?id=1002https://../documents?id=1003
Exploit Rule #1: Hackers are looking for monetizable data like customer names, emails, addresses, company names, credit cards, transactions, orders, financial records, etc unless if the intention is to disrupt your business.
The flaw in the URL:
The above URL suggests that it’s a document endpoint. It may contain sensitive and financial information since the First American Financial is a financial company. This endpoint is more important to hackers than let’s say “/locations”, or “/products” endpoints which are mostly public information and exploiting or accessing this data will have very little financial gains.
Once the hackers identify endpoints with critical data, the next steps are to look for the exploits.
Exploit Techniques
- Insecure Direct Object Reference (IDOR)
- Parameter Tampering
The IDOR is a common design practice across the industry to solve some common problems, for example, Google Docs, Dropbox they all use this design to allow users to share private documents by just sharing the auto-generated non-guessable document URLs. The only time this design becomes an easy pray is if the URLs are guessable or predictable and in First American Financial’s case, it seems the product had sequential or number-based document ids. That means it was easy to guess document Ids for the entire 885 million records.
If the above URL were public or non-protected, which means it doesn’t require any authentication, then this would have allowed hackers to download all the data without leaving any digital fingerprints. Also, it requires much less work on their part, as they don’t have to sign-up for the service or steal a customer or employee credentials to perpetuate the breach.
Sequential Identifiers
id=emp-1001id=customer-1001
Never ever use sequential numbers and weak random string generators. These are easy to predict or reverse generate.
Example of good ID design: Google’s private doc’s public URL (The highlighted ID is tough to guess or predict). Anybody with the URL can access the document.
https://docs.google.com/spreadsheets/d/1mCPqlQSTI3K4YzJqbW8peTQ3zBF7tlNptmOEuLybvXI/edit?usp=sharing
The next step would have been to use parameter tampering technique along with a script to download all the documents. Example shell script
#!/bin/bashfor i in {1..1000000000}do wget "https://../documents?id="$idone
Solution: Tactically secure and validate the most critical data endpoints first.
Attackers are consistently going after three critical pieces of information if monetary benefits drive them. e.g., customer information, customer financial data, credit cards, bank accounts, transfers, transactions, orders, etc.
Financial Repercussions:
- Even though there was no reported breach but the First American Financial stock still shed $110M or 2% of the $5.7B market cap.
- Have to go through expensive third-party forensics and audits.
What won’t work in thwarting these kinds of attacks
Web scanners may not detect these exploits, as they focus more on injection and on fuzzing attacks than on tailored scenarios like these.
How to protect your Apps and APIs against these attacks?
- Design best practice: never use Incremental IDs for record identifications in your database. Instead, use random UID’s and in addition, do salting of IDs. It will slow down the attack as it will be much harder to guess and fish ID.
- Proper Access-Controls checks in the business logic to validate caller against the requesting data.
- Continuously scan & validate access-controls logic on all endpoints. As the product grows these vulnerabilities becomes very common.
- A Type-2 Scanner that looks in addition to injection attacks and looks for business logic vulnerabilities including RBAC, ABAC, Hijack, Sensitive Data Exposure attacks, etc.
FAQs
1. How do sequential identifiers like predictable document IDs lead to data breaches?
Predictable IDs allow attackers to enumerate resources and access other users’ data simply by incrementing or decrementing identifiers.
2. What kind of automated testing can detect Insecure Direct Object Reference (IDOR) vulnerabilities?
Role-based, object-level authorization tests that validate ownership and enforce identity boundaries reliably detect IDOR.
3. Why are parameter tampering attacks effective against APIs with weak access controls?
APIs that trust client-side parameters let attackers modify IDs, roles, or flags to escalate actions or access other accounts.
4. Why don’t traditional web scanners always detect business logic vulnerabilities like IDOR?
Logic flaws require contextual, workflow-aware understanding that generic scanners can’t replicate.
The deploy gate is the last control point
The depth of a human. The coverage of a machine.
Start free and see a proven exploit against your own application, or get a walkthrough tailored to your stack.
