TL;DR: A Life360 API issue allowed an attacker to retrieve about 400,000 user phone numbers and related account data through an unsecured endpoint, illustrating OWASP API Top 10 excessive data exposure and the failure of hiding data only in the app layer, according to Salt. Obfuscation does not substitute for server-side access control, response minimisation, and runtime API monitoring.
At a glance
What this is: Life360’s API exposure shows how excessive data disclosure can leak sensitive user details even when the mobile app does not display them.
Why it matters: It matters because IAM and API security teams must treat response shaping, access control, and runtime visibility as enforcement points, not the user interface.
Context
API excessive data exposure happens when a service returns more information than a requester needs or is allowed to see. In this case, the problem was not a broken front end, but a server-side response that exposed name and phone number data through an unsecured endpoint. That is a classic application security failure with an identity angle, because the leaked fields directly identify users and can be used for targeting or account correlation.
The deeper governance issue is that hiding data in the client is not equivalent to restricting data at the API layer. For IAM and API security practitioners, this is the boundary where authorisation, data minimisation, and telemetry have to work together. If the API can disclose sensitive attributes during normal request handling, the app presentation layer is only cosmetic protection.
Key questions
Q: What breaks when an API hides sensitive data only in the app UI?
A: The control fails because attackers can inspect the raw backend response directly and retrieve fields the interface never displays. UI masking does not reduce exposure if the API still sends names, phone numbers, verification hints, or object details. Real protection requires server-side response minimisation and access enforcement, not presentation-layer secrecy.
Q: Why does excessive data exposure create identity risk?
A: Excessive data exposure turns routine API calls into a source of personal data that can be used for phishing, account correlation, or social engineering. Even when the app does not show the data, the response can still reveal enough to identify users. That makes response design part of identity protection, not just application hygiene.
Q: What are the signs that an API authorization control is failing in practice?
A: Common warning signs include endpoints returning valid data without a token, access to records that should be scoped to another user, and responses that expose credentials or keys in configuration data. Another indicator is when iterating a parameter reveals large volumes of records in predictable increments. Those patterns suggest broken object or function level authorization, not just a minor configuration issue.
Q: How should teams respond when an API returns more data than the user needs?
A: Revoke the assumption that presentation-layer masking is enough, then reduce the response to the minimum data needed for the transaction. After that, test the endpoint through proxies and automated abuse scenarios to confirm the unwanted fields are no longer present and the authorisation logic still holds.
Technical breakdown
Why excessive data exposure happens in API responses
Excessive data exposure occurs when backend services return fields that the client does not need, then rely on the application to hide them. That is a design failure, because anyone intercepting traffic through a proxy, emulator, or browser tooling can inspect the raw response. In API security terms, the problem is not just visibility, but unnecessary data being authorised for release at all. Once sensitive attributes leave the server, client-side masking cannot recover them. The result is often a clean user interface paired with a leaky trust boundary.
Practical implication: Prune response payloads at the server and treat every returned field as an access decision, not a presentation choice.
How obfuscation fails against proxy and emulator inspection
Obfuscation only changes what the user interface shows. It does not change what the API returns, which means a user with a proxy, emulator, or interception tool can still see the full payload. This is why client-side hiding is weak security: it assumes the attacker will only use the intended interface. In mobile and API-heavy architectures, the real control plane is the response itself. If the server includes first name, email, or phone number in a response, those values can be captured regardless of what the app renders.
Practical implication: Assume every API response can be inspected and design the backend so sensitive fields are omitted unless explicitly required.
Why runtime API monitoring matters for parameter enumeration and BOLA
Runtime monitoring can detect repeated enumeration, unusual access patterns, and requests that return sensitive data outside normal user behaviour. In this case, the article points to parameter enumeration and a Single-ID BOLA style pattern, where an attacker iterates through identifiers and extracts data that should not be exposed. BOLA, or broken object level authorisation, is especially dangerous when the endpoint returns both object access and personal data in the same response. Detection has to watch for both the request pattern and the data class returned.
Practical implication: Correlate request behaviour with response content so object-level abuse and sensitive-data disclosure are visible together.
Threat narrative
Attacker objective: The attacker’s objective was to harvest personal account data at scale from an API that disclosed more information than the user interface showed.
- Entry occurred through an unsecured API endpoint that returned user account data during routine login-related traffic.
- The attacker inspected the raw API response and collected names, email addresses, and phone numbers that were not meant to be visible in the app.
- The impact was large-scale exposure of personal contact data for roughly 400,000 users, with the potential for follow-on phishing or account correlation.
Breaches seen in the wild
- T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
- Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Excessive data exposure is an authorisation failure, not a display problem. If the backend returns personal data, the attack surface already exists before the app decides whether to render it. That means security teams have to govern the response object itself, not just the user interface. For identity programmes, this is where API security and privacy controls meet, because leaked fields can be used to identify and target users.
Obfuscation creates false confidence in mobile and API design. Hiding a value in the client encourages teams to believe the data is safe when it is merely concealed. That assumption breaks as soon as an attacker uses a proxy or emulator to inspect traffic. The governance lesson is simple: if a field is not safe to disclose, it should not be in the response.
API abuse detection has to account for both access pattern and data class. Enumeration alone is not always enough to flag a compromise when each request looks plausible in isolation. The stronger signal is the combination of repetitive object access and the return of sensitive identity attributes. Practitioners should treat that combination as a control gap in object-level authorisation and telemetry.
Response minimisation is now part of identity protection. When phone numbers, names, and account identifiers are exposed through APIs, the issue moves beyond API security into user identity risk. That makes OWASP API Security Top 10 and NIST-CSF access control logic directly relevant to the way teams design and monitor data-bearing endpoints. The practitioner conclusion is to minimise what an API can reveal before asking how to detect abuse.
From our research library:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- Read next: API Key Management Guide
What this signals
API response minimisation is now an identity control. When the backend returns personal data that the interface never needs, the security problem shifts from disclosure to governance. Teams should expect attackers to use proxies and emulators to inspect traffic, so the decision point is what the API emits, not what the app renders.
Excessive data exposure aligns with OWASP API Security rather than cosmetic UI hardening. The practical boundary is object-level authorisation and response shaping, which means security teams need testing and telemetry at the endpoint itself. That is especially important where identity-bearing fields can be used to profile or target users.
For practitioners
- Enforce server-side response minimisation Remove unused identity fields from API responses and return only the attributes required for the transaction. Do not rely on the mobile app or front end to hide sensitive data that the backend still sends.
- Review object-level authorisation on identity-bearing endpoints Test login, profile, and account lookup APIs for broken object level authorisation and confirm that each object is authorised before any personal data is returned.
- Instrument API telemetry for enumeration patterns Flag repeated identifier sweeps, unusual parameter variation, and responses that return personal data outside normal user behaviour. Pair request analytics with response inspection so sensitive disclosure is visible.
- Treat client-side masking as cosmetic only Assume proxies, emulators, and interception tooling can expose every field the server sends. Build controls around what the API releases, not around what the interface displays.
Key takeaways
- The Life360 exposure shows that hiding data in the client does not prevent the API from leaking it.
- About 400,000 user phone numbers were exposed, which makes this a scale problem as well as a design problem.
- Server-side response minimisation, object-level authorisation, and runtime API monitoring are the controls that actually reduce risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API3 — Broken Object Property Level Authorization | The article centres on an API returning more user data than the client needed. |
| API6 — Unrestricted Access to Sensitive Business Flows | The login flow exposed identity data through a business path that should have been tightly constrained. | |
| Recommendation — Review endpoint payloads against API3 and remove any identity fields not explicitly authorised for release. Apply API6 checks to sensitive flows so personal data is only returned when the business step genuinely requires it. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The root issue is over-disclosure caused by weak authorization at the endpoint boundary. |
| Recommendation — Use PR.AA-05 to verify that each API response is limited to authorised entitlements and intended data scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | The exposed fields were tied to user account identities and should have been constrained by account governance. |
| Recommendation — Use CIS-5 to tighten account data handling and reduce identity exposure in account-related API responses. | ||
| MITRE ATT&CK | TA0007;TA0009 — Discovery; Collection | The article describes enumeration and collection of sensitive data through repeated API access. |
| Recommendation — Map repeated API sweeps to TA0007 and TA0009 and hunt for collection patterns across identity-bearing endpoints. | ||
Key terms
- Excessive Data Exposure: Excessive data exposure occurs when an API returns more information than the caller actually needs. The issue is usually a design and authorization problem rather than a coding typo, and it increases breach impact because a stolen credential can reveal far more data than intended.
- Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
- Claim Minimisation: The practice of including only the identity attributes required for a specific access decision. In API security, claim minimisation reduces unnecessary data exposure, simplifies token review, and lowers the risk that broad identity context becomes a hidden authorisation dependency.
- Parameter Enumeration: Repeatedly varying request parameters to discover valid identifiers, records, or records that return extra data. In API abuse, enumeration often becomes the path from ordinary requests to bulk extraction of identity or account information.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives practitioners a practical way to connect identity controls to broader security architecture.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org