In November 2018, reporting by KrebsOnSecurity described a USPS web API weakness tied to the Informed Visibility service that allowed a logged-in USPS.com user to query account information associated with other users. The reporting estimated that roughly 60 million users were potentially exposed, and some account data could reportedly be modified. The case remains a useful illustration of a core API-security principle: authentication proves who a caller is; it does not prove that the caller may access the requested object.
What was reported in 2018
KrebsOnSecurity reported on November 21, 2018 that USPS had fixed a weakness allowing anyone with a USPS.com account to view account details for approximately 60 million other users and, in some cases, modify account data. The API was associated with Informed Visibility, a service intended to provide near-real-time tracking information to business mailers.
Reportedly exposed fields included information such as usernames or IDs, email addresses, account numbers, street addresses, phone numbers, authorized users, and mailing-campaign data. The issue was described as an authentication or authorization weakness in the API logic rather than a sophisticated infrastructure compromise.
The root problem: authentication without object authorization
The central security failure maps closely to what OWASP now calls Broken Object Level Authorization (BOLA). A user could authenticate legitimately and then request data associated with another account because the backend did not sufficiently verify that the caller was entitled to that object.
| Control | What it proves | What it does not prove |
|---|---|---|
| Login / session | The caller has a valid account | Ownership of every requested account or record |
| Object ID | Which record the caller is asking for | Whether the caller may access it |
| UI restrictions | What the normal interface presents | What a direct API request can request |
| HTTPS | Traffic confidentiality in transit | Authorization to the returned data |
Why enumeration makes authorization flaws scale
An authorization flaw becomes much more serious when identifiers can be enumerated or queried in bulk. Attackers do not need to break encryption if the API itself returns another user’s data after a small parameter change. Automation can then repeat the same logically valid request many times.
- Do not rely on unpredictable IDs as the primary security control.
- Perform ownership or entitlement checks after resolving the requested object.
- Limit bulk lookup functions to roles that truly need them.
- Detect users that access unusually large numbers of unrelated objects.
- Minimize returned fields so a single authorization error exposes less information.
Read exposure and write access need separate authorization
Public reporting indicated that some details could also be modified. Read and write permissions should be evaluated independently. A caller may be allowed to view a record but not change contact information, account relationships, campaign settings, or administrative attributes.
Modern API designs should enforce object-level and property-level authorization for both response fields and update fields. Generic update endpoints that bind every submitted property can turn one missed policy check into a broader account-integrity problem.
The disclosure timeline is also a security lesson
The researcher who contacted Krebs reportedly said the weakness had been disclosed to USPS more than a year earlier without a response. Krebs reported that USPS addressed the issue after he verified the finding and contacted the organization. Regardless of the internal reasons, the story illustrates why vulnerability-intake and escalation processes are part of application security.
- Provide a monitored security-reporting channel.
- Acknowledge researchers and assign an owner quickly.
- Create severity-based escalation for internet-facing authorization failures.
- Preserve evidence and test whether similar endpoints share the same flaw.
- Communicate remediation status without exposing details that increase risk.
How modern API testing would catch this class of issue
- Create two ordinary user accounts belonging to separate tenants or identities.
- Capture a valid request that retrieves an object for User A.
- Replay the request as User B while changing only the target identifier.
- Repeat through alternate endpoints, search functions, bulk APIs, and nested resources.
- Test read, update, delete, export, and administrative variants separately.
- Verify that unauthorized responses do not leak sensitive metadata or object existence.
This negative testing is more valuable than proving that the happy path works, because the vulnerability exists precisely at the boundary between two valid users.
Runtime signals that can reveal object-access abuse
Static testing may miss a new endpoint or regression. Runtime API monitoring can add a second layer by detecting behavior such as one user rapidly accessing thousands of unrelated accounts, sequential identifier scans, unusual response sizes, or newly exposed endpoint versions.
Identity expansion
One account begins accessing objects far outside its normal set.
Enumeration
Object IDs change rapidly while the endpoint and token remain constant.
Bulk extraction
Response volume or pagination behavior grows sharply.
Write anomalies
A low-privilege user updates records belonging to many unrelated accounts.
Security lessons that still apply
- Authentication and authorization must be separate design decisions.
- Every object lookup that uses caller-controlled identifiers needs an entitlement check.
- Bulk and search APIs deserve especially strict authorization and monitoring.
- Response minimization limits the impact of a missed check.
- A vulnerability-disclosure process can shorten the time between discovery and remediation.
- Inventory and runtime monitoring help find equivalent flaws across alternate versions and endpoints.
The USPS case predates the current OWASP API Security Top 10, but the underlying lesson aligns directly with today’s BOLA guidance.
Frequently asked questions
What was the USPS API vulnerability?
Public reporting described an authorization weakness in a USPS web API tied to Informed Visibility that allowed logged-in users to retrieve account information belonging to other USPS.com users.
Were 60 million USPS users definitely breached?
The reporting said data for roughly 60 million users was potentially exposed through the flaw. That is different from proof that an attacker downloaded all 60 million records.
Was this an authentication or authorization problem?
The users were authenticated, but the API reportedly failed to enforce the correct object-level authorization. That distinction is why the incident is a useful BOLA case study.
What data was reportedly accessible?
Reports described usernames or IDs, email addresses, account numbers, street addresses, phone numbers, authorized users, and mailing-campaign information among the potentially accessible fields.
How can teams prevent similar incidents?
Use object-level authorization on every lookup, separate read and write policy, minimize response fields, test cross-user access, monitor enumeration, and maintain a responsive vulnerability-disclosure process.
Sources and further reading
- KrebsOnSecurity — USPS Site Exposed Data on 60 Million Users — original public reporting on the 2018 issue
- TechTarget — USPS website flaw exposed data for one year — contemporary summary of the disclosure and remediation timeline
- OWASP API1:2023 Broken Object Level Authorization — modern framework for the authorization failure class
Protect APIs with runtime context, not just static rules
Ammune helps security teams discover APIs, understand normal behavior, detect abuse and authorization anomalies, and apply runtime protection across modern API environments.