2026-07-17 · 5 min read · Rahul Chitturi
- url
- security
- debugging
Signed URLs fail with 403 responses when the server, CDN, or object store cannot reproduce the signature it expects. The bug might be an expired timestamp, a double-encoded path, reordered query parameters, or a redirect that changes the canonical URL.
Before rotating keys, capture a failing URL and a known-good URL with secrets removed. Preserve path characters, query parameter names, timestamp formats, and signature length so the comparison still explains the failure.
Rebuild the canonical input
Most signed URL systems hash or sign a canonical string. If the application signs one version and the CDN verifies another, even one slash, plus sign, or decoded space can invalidate the request.
- Compare raw URL, decoded path, and encoded path separately
- Confirm query parameter order if the signing algorithm requires it
- Convert expiry timestamps in the same timezone as CDN logs
- Check whether redirects change host, scheme, path, or query string
Use fixtures before changing keys
A safe reproduction should include a fake signing key, a canonical string, the generated signature, and the final URL. That lets reviewers prove whether the mismatch comes from encoding, expiry, hashing, or infrastructure behavior.
If the URL includes user IDs, object names, or temporary access tokens, replace them with stable placeholders while keeping the same reserved characters. Removing those characters can hide the encoding bug you need to fix.
A Flashman workflow
Use the URL encoder/decoder to inspect path and query transformations, the timestamp converter to check expiry windows, the hash tool for local signature experiments, and the diff tool to compare canonical strings.
Treat live signed URLs like credentials. Debug with expired or synthetic examples whenever possible, and avoid posting usable download links in tickets or chat threads.