No Hacking Required
In May 2019, security reporter Brian Krebs disclosed that First American Financial Corporation — the largest title insurance company in the United States — had been exposing approximately 885 million documents on its website. The records dated back to 2003.
No sophisticated exploit was needed. Anyone who had a valid document link could modify the number in the URL to access other people's records. This type of vulnerability is called an Insecure Direct Object Reference (IDOR), and it's one of the most basic security flaws in web development.
What Was Exposed
The documents contained some of the most sensitive financial information imaginable:
- Bank account numbers and statements
- Social Security numbers
- Wire transfer receipts with full routing details
- Mortgage and tax records
- Driver's licenses and other identification documents
- Internal First American emails
These were digitized versions of documents exchanged during real estate transactions — among the most sensitive financial events in most people's lives.
How an IDOR Works
An IDOR vulnerability occurs when an application uses predictable identifiers (like sequential numbers) to reference records and doesn't verify that the requesting user is authorized to access a specific record.
In First American's case, documents were stored at URLs like:
firstam.com/document/000000001
Changing the number to 000000002 displayed a completely different customer's documents. There was no authentication check, no authorization verification — just direct access to any document by number.
The Regulatory Response
The SEC charged First American with cybersecurity disclosure failures, resulting in a $487,616 penalty. The New York Department of Financial Services fined the company $1 million — the first enforcement action under New York's cybersecurity regulation.
While these fines seem modest compared to the scale of exposure, they set precedents for holding companies accountable for basic security failures.
Lessons from First American
- Basic access controls are non-negotiable. Every record accessed through a web application must verify that the requesting user is authorized to view it.
- Security testing should include authorization checks. Automated scanners often miss IDOR vulnerabilities because they require contextual testing.
- Sensitive documents require authentication. No document containing PII should ever be accessible without verifying the requester's identity.
- Sequential IDs are a risk signal. Using random UUIDs instead of sequential numbers makes it much harder for attackers to enumerate records.
The Broader Problem
First American wasn't unique. IDOR vulnerabilities are consistently ranked among the most common and most dangerous web application flaws by OWASP. They persist because they're easy to introduce during development and hard to catch without thorough security review.
If you've been involved in a real estate transaction, your data may have been accessible. Check LeakedSource to monitor your personal information across breach databases and data exposures.