What are the signs that a public API is being misused to harvest account data?

Common warning signs include unusual query volume, repeated lookups against predictable identifiers, access from unauthenticated sources, and requests that enumerate many profiles in a short period. Security teams should also watch for patterns that suggest data gathering rather than normal application use, such as broad sweeps across user records or requests that vary only slightly to bypass simple checks.

What misuse looks like in practice

Public API abuse is usually less about a single bad request and more about a pattern that diverges from normal product use. Repeated lookups, high-frequency requests, and broad sweeps across record sets are especially important when the endpoint returns stable, user-linked fields that are easy to collect at scale. OWASP’s API Security Top 10 is the most useful external lens here because it frames the problem around excessive exposure and resource consumption rather than only authentication failures.

A second signal is behaviour that looks automated but not necessarily disruptive: evenly spaced calls, small parameter changes, or sequential identifier testing across many accounts. That can indicate an actor is trying to stay under simple thresholds while building a dataset. Where the endpoint is undocumented, weakly rate-limited, or accepts predictable identifiers, the line between normal client traffic and harvesting becomes easier to cross.

For teams that want a broader control baseline, the NIST AI Risk Management Framework is not API-specific, but its emphasis on monitoring and accountable operations is useful when API usage is part of a larger automated workflow. If the endpoint is part of a machine-to-machine integration, NHIMG’s Ultimate Guide to NHIs, what are Non-Human Identities helps anchor the identity and access context for tokens, service accounts, and other non-human credentials that often sit behind API traffic.

What defenders should inspect first

Look at request shape before you look at volume alone. Harvesting campaigns often reveal themselves through enumeration, predictable sequencing, and repeated retrieval of adjacent records, not just through a spike in traffic. If the same client repeatedly asks for profiles, account summaries, or list endpoints with only tiny variations, that is a stronger signal than a generic increase in calls.

Also inspect whether requests are coming through the intended application path. Direct calls from unauthenticated sources, requests that bypass the normal browser or app flow, and traffic that lacks the expected session or device context can all indicate that the endpoint is being treated as a data source rather than a user-facing API. This is where logging, alerting, and access control need to be aligned so you can distinguish legitimate integrator behaviour from collection activity.

The most useful baseline is not simply “is this allowed,” but “does this pattern fit how real clients behave.” A public API can be documented and still be abused if it exposes too much data, trusts predictable identifiers, or lacks enough behavioural controls to spot systematic retrieval.

Risk and Threat Considerations

Misuse of a public API to harvest account data creates both exposure and scale risk. Once an endpoint supports easy enumeration, an attacker can often collect many records without needing to compromise a user account first, which makes the abuse fast, quiet, and hard to separate from legitimate integration traffic.

Failure mechanism: The API returns account-linked data in a way that can be queried repeatedly, batched, or iterated across predictable identifiers, while monitoring and throttling are too weak to distinguish collection from normal use.

Impact: Sensitive profile data, account metadata, and other personally linked records can be exfiltrated at volume, enabling privacy harm, targeted phishing, credential attacks, or broader fraud.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Exposure	API harvesting often relies on exposed tokens or keys that enable bulk account queries.
Recommendation — Rotate exposed API credentials and eliminate long-lived secrets from client and repository paths.
CIS Controls v8	8 — Audit Log Management	Detecting account-data harvesting depends on logging and reviewing enumeration-like API patterns.
	6 — Access Control Management	Public API misuse is constrained by limiting who can query sensitive account data and how much.
Recommendation — Centralize API audit logs and alert on repetitive lookups, sweeps, and unusual source patterns. Restrict API access paths and apply least privilege to high-value account endpoints.
NIST CSF 2.0	DE.CM — Security Continuous Monitoring	Misuse signs are behavioural and require continuous monitoring of API activity.
	PR.AA — Identity Management, Authentication and Access Control	Account-data harvesting is easier when API access and request authorization are too permissive.
Recommendation — Monitor API traffic for enumeration, abnormal volume, and repeated retrieval patterns. Tighten API authorization checks so each request can only retrieve the data it truly needs.
MITRE ATT&CK	T1210 — Exploitation of Remote Services	Abuse of a public API commonly uses remote requests to enumerate and extract data at scale.
Recommendation — Map repeated API retrieval activity to remote-service abuse and hunt for systematic enumeration.
OWASP Agentic AI Top 10	A1 — Prompt Injection	Not selected.

Practitioner Guidance

What to verify: Confirm whether the endpoint is serving a single-user request pattern or an enumeration pattern by checking for sequential identifiers, repeated page traversal, and many near-identical lookups from the same source.

Decision rule: If the traffic can systematically retrieve many distinct accounts with little client-side friction, treat it as harvesting risk even if each individual request is technically valid.

What practitioners underestimate: Abuse often comes from “normal-looking” requests that are individually low risk but collectively reveal a data collection objective. The control objective is to make that pattern visible early enough to slow it down, attribute it, and limit the blast radius before large-scale export occurs.

Practitioner takeaway: The key judgement is whether the API is revealing a stable, enumerable data surface. If it is, detection and throttling must be tuned to collection patterns, not just to authentication failures or raw request volume.