Attackers harvested 533 million Facebook user records by sending automated queries to the Contact Importer endpoint. The endpoint accepted any phone number, returned the matching name, email, and location, and performed no check that the requester actually knew the person. No password, session cookie, or second factor was ever supplied, so the entire collection happened without touching an authentication system.
Direct API Queries Without Sessions
The Contact Importer feature let users upload a list of phone numbers to discover matching accounts. The same endpoint accepted scripted requests that simply enumerated ranges of numbers. Because the server returned data without verifying the caller's relationship to those numbers, attackers collected 533 million records containing phone numbers, names, emails, and locations. Facebook later confirmed the exposure window closed in 2019, yet the earlier period proved sufficient for the harvest. The full attack-chain timeline appears on the companion site.
No credential was presented at any point. The requests reached an internal data path that did not require a login, so the question of whether a password or second factor would have helped never arose.
MFA's Scope Stops at Authentication
Authorization abuse sits outside the reach of any authentication factor. The server accepted queries it should have rejected on the basis of caller identity, not on the presence of a valid session. Once an endpoint grants access without authentication, no OTP, push notification, or device-bound signature can intervene. The same pattern appears whenever an API trusts the caller without least-privilege checks.
Device-bound keys close replay and credential theft paths only when an authentication decision actually occurs. They do not add authorization logic to endpoints that lack it. The Facebook scrape therefore illustrates the boundary of what authentication technology can address rather than a shortcoming in any particular factor.
Fixing Authorization Instead of Authentication
Passkeys and FIDO2 protect the login step by keeping private keys inside hardware and producing origin-bound signatures. That protection applies only when an application requests proof of identity. It does not constrain what an already-accepted request may retrieve. A passkeys-only rollout at Facebook would have left the Contact Importer endpoint untouched because the endpoint never required proof of identity.
Full lifecycle coverage matters once every access path routes through an authentication decision. Endpoints that return data without that decision remain exposed regardless of the technology protecting the login screen. The practical lesson is to enforce authorization checks at the data layer rather than hoping stronger login requirements will compensate for missing access controls.
FAQ
Did any form of MFA have an opportunity to act during the Facebook data scrape?
No. The Facebook data breach involved direct API queries against the Contact Importer feature. No login, password, or second factor was ever presented, so MFA had no opportunity to act.
How many records were actually taken in the Facebook breach?
Researchers confirmed 533 million unique user records containing phone numbers, names, emails, and locations were scraped and later posted publicly.
Would passkeys at the login layer have blocked the Contact Importer queries?
No. The attackers never logged in. Passkeys protect authentication events; they do not add authorization checks to endpoints that accept unauthenticated requests.
Was the vulnerability still active when the data appeared on forums?
Facebook stated the Contact Importer flaw was patched in 2019. The data set that surfaced in 2021 had been collected during the earlier exposure window.
Could stronger login requirements have prevented this scrape?
Stronger login requirements would not have helped. The attackers never logged in; they simply queried an endpoint that did not enforce proper authorization for the requested data.
