Skip to main content

Enumeration-sensitive data

Some tables should not tell a visitor how many rows they hold or in what order they were created. A sequential id in the URL gives all of that away, and the default Sqids token still leaks approximate count and growth — it is obfuscation, not privacy.

// config/polyslug.php
'encoder' => Polyslug\Encoders\RandomTokenEncoder::class, // token reveals no id, count, or order

Each key maps to an unguessable random token stored in polyslug_tokens. The token is stable per key, so every record keeps a single canonical URL — you get opacity without giving up the self-healing behavior.

If the table can be re-keyed, UuidEncoder with a random UUIDv4 achieves the same with no lookup table. Avoid UlidEncoder and ordered UUIDs here: both embed creation time.

An encoder is not authorization

An opaque token raises the cost of guessing a URL; it does not decide who may open one. A link that leaks — a forwarded email, a browser history on a shared machine — still carries a valid token. Pair this with polyslugResolveQuery() wherever the data is actually confidential.

Migrating an existing table

Switching encoders re-encodes every URL. List the previous one in polyslug.legacy_decoders so published links keep resolving and self-heal to the new format on the next visit:

'encoder' => RandomTokenEncoder::class,
'legacy_decoders' => [SqidsEncoder::class],

See also