Short-link services with sequential identifiers receive more enumeration requests than services with random identifiers

Hypothesis

The OWASP cheat sheet on insecure direct object references recommends access control checks on every object and, as a defence-in-depth measure, complex identifiers that are impractical to guess. A short link is a public object without access control by design, so the identifier is the only thing standing between a link and a stranger. With a sequential key (a counter encoded in base62), a client that knows one key can request its neighbours and reach every link ever created; with a random fixed-length key most guesses miss. The hypothesis is that the two designs produce visibly different traffic: on a sequential service, a larger share of successful redirects come from clients that never received the link (they arrive without a referrer, in monotonic key order, from a small number of network sources, at machine-like intervals), while on a random-key service such clients mostly produce 404 responses. A secondary claim is that the raw 404 rate alone does not separate the two, because a random-key service sees guesses that fail and a sequential service sees guesses that succeed.

Prediction

For two services of similar size and age, sessions reconstructed from access logs (one client, one hour) will show, on the sequential service, a measurable share of sessions that request many distinct existing keys in ascending or descending order without referrers; on the random-key service that share is near zero and the same clients appear instead as bursts of 404s. Blocking or rate-limiting those sessions on the sequential service reduces its successful-redirect volume noticeably; on the random-key service it changes little.

Proposed test

1. Take access logs from one service of each kind over the same period, or from one service before and after switching key generation, with key, status, referrer presence, client network and time.
2. Reconstruct sessions and label a session as enumerating when it requests more than a threshold of distinct keys, mostly adjacent in key order, without referrers.
3. Report the share of successful redirects attributable to enumerating sessions, the share of 404s, and the number of distinct keys such sessions reached, for each service.
4. Publish the labelling rules and thresholds so that another operator can apply them to their own logs.

Status

No result is claimed. Confounders include search-engine crawlers that follow links legitimately, differences in how the two services are advertised, and rate limits that already hide the behaviour in one of the logs; the test should record which rate limits were in force.