Signed short links: when a URL needs to prove it was issued by you

The problem signing solves

A URL is fully under the control of whoever holds it. If your link carries a user id, a discount amount or an expiry, the recipient can edit any of those and try again. A signature is a value computed from the parameters with a secret only you hold, so the server can detect any modification.

How the mechanism works

Take the parameters you want to protect, serialise them in a fixed, documented order, compute a keyed hash such as HMAC-SHA256 with a server-side secret, and append the result as a parameter. On receipt, recompute the hash from the received parameters and compare. If they differ, reject the request. The secret never appears in the URL.

Canonicalisation is where implementations go wrong

Both sides must build the string to be signed identically: the same parameter order, the same encoding, the same treatment of empty values, the same decision about whether the path is included. Sort parameters by name and document the exact format. Most signature mismatches are canonicalisation differences, not tampering, and they are maddening to debug without a documented spec.

Always include an expiry inside the signed data

A signature without a timestamp is valid forever, which turns a leaked URL into a permanent credential. Sign an expiry timestamp along with the payload and reject anything past it. Keep the window as short as the workflow tolerates — minutes for sensitive actions, hours at most for convenience links.

Compare in constant time and fail closed

Use a constant-time comparison function for the signature check; a naive string equality can leak information through timing. And when anything is wrong — missing signature, unparseable timestamp, unknown key version — reject. A default branch that lets an unsigned request through defeats the whole system.

Plan for key rotation from day one

Include a key identifier in the URL so the server knows which secret to verify with. That lets you introduce a new key, accept both for an overlap period, and retire the old one without invalidating links already in flight. Retrofitting a key id into a deployed scheme is much harder than including it at the start.

Signing is not encryption

Everything in the URL is still readable by the recipient. Signing guarantees integrity, not confidentiality. If the parameters themselves are sensitive, do not put them in the URL at all — put an opaque identifier there and keep the data server-side, where it also stays out of browser history, referrer headers and server logs.