Catalog enumeration

What we check

This probe is part of the safety test you request as the verified owner. Starting from a real product URL, we take the last integer in its path and request the next 50 sequential IDs with our crawler user-agent. The IDs follow your own numbering; we do not invent a scheme. We measure how many resolve before anything throttles us.

Why it matters

If /products/1001 leads to 1002, 1003 and on with no limit, a script that counts upward can scrape your entire catalogue, including unlisted or not-yet-launched items. Throttling or non-guessable identifiers prevent this.

How we check

We stop at the first challenge and never count our own budget or timeout as a throttle.

WARN: 40 or more of the 50 sequential IDs resolved with no throttle, so the catalogue is easy to enumerate. PASS: a throttle or challenge appeared mid-walk (you do limit enumeration), or too few IDs resolved (your live catalogue does not follow the guessed sequence). SKIPPED: no product URL to start from, the URL carries no numeric id to walk, or nothing was answered. This probe never FAILs, because the spec defines only the WARN condition as its scored negative outcome. All requests are read-only GETs.

How to fix it

1. Rate-limit sequential access to product URLs per client, as you would for search.
2. Prefer non-sequential, non-guessable product identifiers (handles or opaque slugs) over plain incrementing integers.
3. Return a challenge or a 404 for out-of-range or not-yet-published IDs rather than serving them.

What good looks like

Starting from /products/1001, a shop that guards enumeration:

GET /products/1002 -> 200
GET /products/1003 -> 200
...
GET /products/1020 -> HTTP 429 / managed challenge

The walk is throttled long before the whole catalogue can be counted out.

Sources

• OWASP Automated Threats to Web Applications (OAT handbook)
• RFC 6585 §4: HTTP 429 Too Many Requests