2026-09-22 · 6 min read · Rahul Chitturi
- http
- signatures
- security
HTTP message signatures protect selected request or response components rather than an abstract object. Verification fails when signer and verifier derive different component values, serialize the signature base differently, or apply incompatible key and algorithm policy.
A visually identical URL or field can still produce different bytes after proxy rewriting, normalization, or structured-field parsing.
Log safe intermediate structure
Record the ordered covered-component identifiers, component parameters, derived values, signature parameters, canonical signature base bytes, algorithm, and public key identifier. Do not log private keys, bearer tokens, cookies, or sensitive signed content.
- Preserve covered component order.
- Use a maintained structured-field implementation.
- Derive authority and target values at a documented hop.
- Allowlist algorithms and trusted keys.
Trace transformations by hop
Compare the client, gateway, proxy, service mesh, framework, and application views of the method, authority, target URI, fields, and body-related metadata. Decide where signing and verification occur so intermediaries cannot silently rewrite covered data between them.
Validate created, expires, nonce, key identifier, and replay policy separately from the cryptographic operation. A valid signature can still be too old, replayed, or attached to an untrusted key.
Verify with public vectors
Use Flashman's URL tool for harmless targets, Base64 and hash tools for published vectors, and diff for signature-base lines. Use reviewed libraries for real signing and verification.
Test repeated fields, whitespace, query ordering, empty values, proxy rewrites, content digests, multiple signatures, unsupported algorithms, clock windows, nonce replay, key rotation, and malformed structured fields.