An object identifier that increments in a predictable pattern, such as 1234, 1235, 1236. Sequential identifiers are risky in web applications because they make object guessing easier. When access controls are weak, attackers can modify one value and probe for another user’s record.
How Sequential Identifiers Work
Sequential identifiers are values that rise in a predictable order, such as 1234, 1235, and 1236. They are common in databases, queues, tickets, invoices, and web application object references because they are simple to generate, easy to sort, and easy for humans and systems to understand.
The simplicity is also the weakness. When an application exposes a sequential object reference in a URL, API call, or form field, the identifier often becomes guessable. If the application does not enforce strong access checks on every request, predictability can turn into a direct path to another user’s record.
Why Predictability Creates Exposure
A sequential identifier does not grant access by itself, but it lowers the cost of discovery. Instead of searching randomly, an attacker can increment or decrement a value and test whether adjacent records exist. That makes enumeration efficient, especially when responses differ for valid and invalid objects.
This is why the issue is usually discussed as an object access problem rather than just an identifier design problem. The identifier is visible, stable, and easy to manipulate, so the real security question is whether the application treats object ownership and authorization as separate checks rather than assuming the identifier is trustworthy.
Good design can still use sequential identifiers internally, but externally exposed references are safer when they are not the only control boundary. Many systems reduce exposure by separating business-visible references from backend record keys, or by using non-guessable reference values where object discovery would be damaging.
How Attackers Abuse Sequential IDs
Attackers commonly look for sequential identifiers in profile pages, order lookups, file downloads, support portals, and API endpoints. Once they find one predictable value, they test neighboring values to see whether the application returns different content, status codes, or error messages that reveal a valid record.
If the application also leaks timing differences, verbose errors, or partial metadata, enumeration becomes easier. In practice, the identifier is often only the starting point; the larger weakness is missing object-level authorization, where the server fails to verify that the caller is allowed to see or change the specific object being requested.
When that control gap exists, sequential IDs can enable account data exposure, order manipulation, record tampering, and broader unauthorized access across a large set of objects.
Design and Control Implications
Sequential identifiers are not automatically insecure, but they should be treated as sensitive when they expose business records to untrusted users. The right control is to make authorization independent of identifier guessability, so a predictable value cannot be used as a shortcut to access another principal’s data.
That usually means combining strong object-level access checks with careful response handling. Applications should avoid revealing whether an adjacent object exists unless the caller is entitled to know, and should ensure that access decisions are made on ownership, role, or policy, not on the obscurity of the identifier itself.
Where external visibility matters, a safer pattern is to expose opaque or unguessable references while keeping internal sequence values for operational use. The important point is not that sequential identifiers are forbidden, but that they must not be the mechanism that protects object access.
Risk and Threat Considerations
Sequential identifiers create a predictable enumeration path that attackers can use to discover valid objects, test access boundaries, and probe for weak authorization. The risk rises sharply when applications expose records directly through URLs or APIs and then trust the identifier as if it were proof of entitlement.
Failure mechanism: An attacker alters one visible object ID, submits nearby values, and watches for differences in content, status, or error handling that reveal another user’s record or a modifiable object.
Impact: The result can be unauthorized data disclosure, tampering, account abuse, or a broader object-level access control failure across multiple records.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Sequential IDs are exploitable when object-level authorization is weak. |
| Recommendation — Enforce object-level checks on every request before returning or mutating a record. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Predictable IDs still require enforced access decisions on the requested object. |
| AC-6 — Least Privilege | Reducing object visibility limits the blast radius of exposed sequential references. | |
| Recommendation — Apply AC-3 to verify the caller’s right to each specific object before disclosure. Limit user and service access to only the records and actions they genuinely need. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Sequential identifiers become risky when access paths are not managed consistently. |
| Recommendation — Manage access paths so predictable identifiers cannot expose unauthorized data. | ||
Practitioner Guidance
Why practitioners should care: Sequential identifiers are often harmless inside a trusted backend, but they become a security issue when exposed to untrusted users without object-level checks. Treat them as discoverable references, not as access controls.
What to watch for: Endpoints that return different responses for valid and invalid object IDs, especially when the same pattern appears across profiles, orders, documents, or API resources. Those differences often reveal whether enumeration is possible.
Practitioner takeaway: Use predictable identifiers for convenience only when every request independently proves the caller is allowed to access that specific object.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org