Case study: First American's EaglePro document exposure (2019)

First American, a US title insurance and settlement company, used an application called EaglePro to send document images from real estate transactions to the people involved. On the morning of 24 May 2019 a cybersecurity journalist told the company its application was 'leaking more than 800 million documents from real estate transactions going back from 2003', including bank account numbers, Social Security numbers and driver's license images. Changing the document number in a link 'yielded other people's records'. First American shut down external access to EaglePro and disabled every link it had generated before the article was published that evening.

The flaw was ordinary: an insecure direct object reference (IDOR). What makes the case worth studying is what happened before May. The company's own security team had found the same flaw in a penetration test and reported it in January 2019. A clerical error recorded it at a lower severity, the longer deadline that gave it passed, and no one asked for a risk acceptance. When the company made its public statements, the executives approving them did not know any of that.

Two regulators examined the case. The SEC's order of 14 June 2021 is about disclosure controls, and NYDFS's consent order of November 2023 is about access controls and risk-based policies under New York's cybersecurity regulation. This page reports what those orders found; it draws no legal conclusions.

Every document uploaded to First American's image repository got a numbered document ID. EaglePro links pointed at documents by that number. According to the SEC, 'a user could take the URL generated as part of an EaglePro package ... and alter the digits in the URL to view other document images to which the user should not have had access.' NYDFS adds that the link 'provided access to title-related documents to anyone with the link', 'without login or authentication', and that 'until May 24, 2019, EaglePro hyperlinks had no expiration date'. Some images sent through unsecured packages had also been cached by public search engines.

Every protection the design relied on was outside the request. Staff were 'instructed not to transmit documents containing NPI through these hyperlinks, but there were no technical controls' to stop them. Documents with nonpublic personal information were supposed to be tagged by hand, and the SEC records a 2018 internal analysis that the repository potentially held 'tens of millions' of such images without the tag. NYDFS found the company's risk assessment had classified EaglePro as an application that did not contain NPI.

The fix for an IDOR is an authorization check on every request: does this caller have the right to this object? Random, unguessable IDs and links that expire make enumeration harder and shorten exposure, but a link that leaks or is forwarded still works; they are defense in depth, not the control. The object authorization guide (/domains/appsec/authorization/object-level-authorization/) covers the check, and the missing-authorization fix cards (/fix/missing-authorization/) show it in ten stacks.

Between December 2018 and January 2019 First American's information security staff ran a manual penetration test of EaglePro. The final report of 11 January 2019 rated the finding 'serious', level 3, and described it exactly: 'Access to PDF's and OrderDetails without authentication.' It said no nonpublic personal information was found in the documents reviewed, but 'It is unknown if any additional documents expose [sic] contained NPI. This requires further investigation by the application owner.' NYDFS found that no such investigation, and no review by senior management, took place before 24 May.

Under the company's vulnerability remediation policy, level 3 meant 'medium risk' and a 45-day fix. 'Due to a clerical error the vulnerability was erroneously input as a level 2 or low risk severity' in the automated tracking system, which then set a 90-day deadline of 8 May 2019. The policy said an owner who could not fix in time must go to information security, and if a fix was not possible, obtain 'a waiver or risk acceptance approval from the CISO.' The SEC records that the owner 'did not request a waiver or risk acceptance'. The deadline passed silently.

Every step here is a governance control that existed on paper. The report was right; the severity was copied wrongly; the tracker trusted what it was given; and a missed deadline triggered nothing. Compare the tracker against the source report, compute deadlines from the report's severity, and make a missed deadline either a fix or a recorded risk acceptance by a named person. The risk exceptions guide (/frameworks/risk-exceptions-and-metrics/) and the SLA guide (/frameworks/appsec-metrics-and-slas/) cover both.

On 24 May First American told the journalist it had 'learned of a design defect in an application that made possible unauthorized access to customer data'. On 28 May it furnished a Form 8-K whose press release reported '[n]o preliminary indication of large-scale unauthorized access to customer information.' The SEC found that the CISO learned of the January report on 24 May and the CIO on 25 May, and that both met the CEO and CFO repeatedly over those days, yet 'the company's senior executives responsible for the disclosures were not made aware' of the report or the missed remediation before either statement.

The SEC also found that as of 24 May 2019 First American 'did not have any disclosure controls and procedures related to cybersecurity'. It found a violation of Exchange Act Rule 13a-15(a), ordered the company to cease and desist, and imposed a $487,616 penalty; First American consented without admitting or denying the findings. For engineering teams the practical point is simple: when an incident touches a system, the people writing the public statement need the history of known findings about that system, and someone has to be responsible for handing it to them.

This test uses only Node built-ins (node:http, node:test and fetch) and passed on Node 26. The handler looks the document up, then checks that the caller owns it, and answers 404 both for 'not yours' and 'does not exist', so neighbouring IDs reveal nothing. The test asks for the next sequential ID with a valid session and expects 404, and asks with no session and expects 401. Put a test like it on every route that takes an object ID.

// Regression test: a document link must not open someone else's document.
// Run with: node --test documents.test.mjs (Node 22 or later, no dependencies)
import {test} from 'node:test';
import assert from 'node:assert/strict';
import {createServer} from 'node:http';

const documents = new Map([
  [1001, {owner: 'alice', body: 'Alice closing disclosure'}],
  [1002, {owner: 'bob', body: 'Bob wire instructions'}],
]);
// Stand-in for real authentication: the session cookie names the user.
const userOf = req => /(?:^|;\s*)session=(\w+)/.exec(req.headers.cookie ?? '')?.[1];

function handler(req, res) {
  const match = /^\/documents\/(\d+)$/.exec(new URL(req.url, 'http://x').pathname);
  const doc = match && documents.get(Number(match[1]));
  const user = userOf(req);
  if (!user) return res.writeHead(401).end();
  // Same answer for "not yours" and "does not exist", so IDs cannot be probed.
  if (!doc || doc.owner !== user) return res.writeHead(404).end();
  res.writeHead(200, {'content-type': 'text/plain'}).end(doc.body);
}

async function get(server, path, user) {
  const {port} = server.address();
  const headers = user ? {cookie: `session=${user}`} : {};
  return fetch(`http://127.0.0.1:${port}${path}`, {headers});
}

test('object-level authorization on document links', async t => {
  const server = createServer(handler).listen(0, '127.0.0.1');
  await new Promise(resolve => server.once('listening', resolve));
  t.after(() => server.close());

  assert.equal((await get(server, '/documents/1001', 'alice')).status, 200);
  // The next sequential ID belongs to another customer.
  assert.equal((await get(server, '/documents/1002', 'alice')).status, 404);
  assert.equal((await get(server, '/documents/1003', 'alice')).status, 404);
  // No session, no document, even with a valid ID.
  assert.equal((await get(server, '/documents/1001')).status, 401);
});

The script reads an export of findings with the severity from the source report and the severity in the tracker. It flags any finding whose tracker severity is lower than the report's, and any open finding past the deadline computed from the report's severity that has no recorded risk acceptance. Run on the sample export as of 24 May 2019, it reports the EaglePro-like finding twice: wrong severity, and 88 days past due. The SLA table is an example; use your own policy's numbers.

"""Cross-check findings between the test report and the tracker.

Input: a CSV export with id, report_severity, tracker_severity, reported
(date the report was issued), status, and risk_acceptance (approver or empty).
The deadline comes from the REPORT's severity, not the tracker's, so a
mistyped severity cannot buy extra time.
"""
import csv
import sys
from datetime import date, timedelta

SLA_DAYS = {"critical": 15, "high": 30, "medium": 45, "low": 90}  # set from your policy
RANK = {name: i for i, name in enumerate(["low", "medium", "high", "critical"])}


def review(rows, today):
    for row in rows:
        report, tracker = row["report_severity"], row["tracker_severity"]
        if RANK[tracker] < RANK[report]:
            yield row["id"], f"tracker says {tracker}, report says {report}"
        due = date.fromisoformat(row["reported"]) + timedelta(days=SLA_DAYS[report])
        if row["status"] != "fixed" and today > due and not row["risk_acceptance"]:
            yield row["id"], f"open {(today - due).days} days past {due} with no risk acceptance"


if __name__ == "__main__":
    with open(sys.argv[1], newline="", encoding="utf-8") as f:
        rows = list(csv.DictReader(f))
    today = date.fromisoformat(sys.argv[2]) if len(sys.argv) > 2 else date.today()
    issues = list(review(rows, today))
    for finding, problem in issues:
        print(f"{finding}: {problem}")
    sys.exit(1 if issues else 0)

The SSDF column names NIST SP 800-218 version 1.1 practices and tasks; the ASVS column names ASVS 5.0 requirements.

• An object ID in a URL is a request, not a permission. Check the caller against the object on every request.
• Unguessable IDs and expiring links are worth having, and are not authorization.
• A finding is only as good as its record: reconcile the tracker against the source report and compute deadlines from the report.
• A missed deadline must force a decision, fix or a named risk acceptance, not pass silently.
• When an incident hits a system, the people speaking for the company need its history of known findings.

Neither order establishes how many documents unauthorized people actually viewed or downloaded before 24 May 2019; First American's May 28 press release spoke of '[n]o preliminary indication of large-scale unauthorized access', and NYDFS describes 'potential unauthorized access to NPI'. The document counts differ: the SEC describes about 800 million images in the repository, while the 885 million figure comes from the journalist's article as NYDFS recounts it. The SEC settled without First American admitting or denying its findings, and the NYDFS order records the department's findings in a negotiated consent order. Neither order explains how the clerical error happened.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. SEC: In the Matter of First American Financial Corporation, Release No. 34-92176 (order). 14 June 2021.
2. NYDFS: Consent order, In the Matter of First American Title Insurance Company. November 2023.
3. NYDFS press release: $1 million cybersecurity settlement with First American Title Insurance Company. 28 November 2023.
4. KrebsOnSecurity (journalism that first reported the exposure): First American Financial Corp. leaked hundreds of millions of title insurance records. 24 May 2019.
5. OWASP ASVS 5.0.0: V8 Authorization. Version 5.0.0.
6. MITRE CWE-639: Authorization Bypass Through User-Controlled Key

Reference information

Tags

Access controlAPI securityIncident responseSecurity testingVulnerability managementAppSec programs

SDLC phase

DevelopmentTestingMaintenanceSecurity program

Role

DevelopersAppSec engineersSecurity leaders

ASVS 5.0.0 requirements

v5.0.0-8.2.2 · v5.0.0-8.3.1

Download this guide as Markdown

Continue exploring