A predictable identifier is a resource ID whose value follows a pattern that can be inferred from other IDs. For example, an API might expose payments as /payments/1, /payments/2, and /payments/3. section 6.2
The danger begins when an attacker changes the identifier in a resource URI and tests whether the server returns someone else’s resource. This practice, called resource enumeration, becomes especially serious when authorization or access controls are weak, potentially causing broken object-level authorization and data breaches. section 6.2
Sequential payment IDs
A user receives payment ID 1 and then payment ID 2. An attacker can try /payments/3, /payments/4, and other values to discover resources that should not belong to them. The sequence is not itself a database problem; exposing it directly through the API creates a scanning guide. section 6.2
Figure 6.4 When an API uses a predictable pattern to identify resources, such as incremental integer IDs, threat actors will play with those values to try to access resources that don’t belong to them.
Shows how attackers manipulate predictable resource identifiers to try to access unrelated resources. section 6.2
Mitigate the design risk by masking identifiers or using a different identifier type in the data source. Continue enforcing authorization and access controls for every requested resource; obscurity alone is not a substitute for authorization. section 6.7 section 6.2
