Verify HTTP Message Signatures Across a Reverse-Proxy Boundary

Define the authenticated message at one hop

HTTP Message Signatures protect selected components, not an abstract request independent of its route. Start with one integration: an external system sends a state-changing request through a managed reverse proxy to an application verifier. Record signer, verifier, request method, target authority and path, query meaning, selected headers, body representation, proxy transformations, key identifier, algorithm, and business authorization. State which hop the signature authenticates and which components can change afterward.

Use a harmless synthetic command with an independent state observation. The valid fixture should change one seeded record once. Negative fixtures must leave it untouched. A successful cryptographic check proves that the selected signature base matches a trusted key; it does not by itself prove the caller may perform the action, the body is fresh, or the operation is safe to repeat.

Choose covered components from threats

List what an attacker or intermediary must not alter: method, scheme, authority, path, query parameters, content type, content digest, timestamp, nonce, and an application account or tenant header where appropriate. Cover derived components according to the standard rather than inventing a concatenated string. If query order, repeated fields, encoding, or normalization carry meaning, create explicit fixtures and confirm signer and verifier construct the same base.

Do not sign volatile transport headers merely because they exist. Proxies may add forwarding, tracing, connection, or compression metadata. Conversely, omitting the target authority or path can let a valid signed body move to another endpoint. The security owner approves the component set and residual risks; the developer implements the declared base and produces evidence for each mutation.

Locate verification relative to the proxy

Draw the exact request seen at the public edge and the exact request exposed to the verifier. Test host rewriting, TLS termination, path prefix removal, percent encoding, query normalization, header combination, whitespace handling, and body decompression if applicable. Decide whether the edge verifies the external form, the application reconstructs trusted external components from controlled forwarding metadata, or both hops use separate signatures.

Never trust client-supplied Forwarded or X-Forwarded fields simply because the application sits behind a proxy. Define which proxy removes untrusted values, writes authoritative metadata, and connects through an authenticated boundary. A mismatch should fail with a safe response and no side effect. Broad fallback that retries verification against several guessed host or path forms creates ambiguity an attacker may exploit.

Bind the body without parser ambiguity

For requests with content, use a reviewed digest mechanism and cover the relevant digest and content-type components. Compute against the bytes at the declared hop before parsing or transforming them. Then validate syntax and business fields separately. Re-serializing JSON can change whitespace, number formatting, property order, or Unicode representation, while two syntactically different bodies may parse into similar data.

Test a changed byte, changed digest header, valid digest over a disallowed media type, duplicate or conflicting headers, empty body, oversized body, and body altered by middleware. Limit buffering and parsing so authentication cannot be used for memory exhaustion. Streaming designs need a declared digest and commit boundary; no irreversible business action should occur before the full authenticated content is accepted.

Add freshness and replay state

Require created time and an expiration or bounded age appropriate to the integration, and define clock skew explicitly. Include a nonce or stable request identifier when replay would cause harm. Store replay state atomically for at least the accepted window, scoped to signer and identifier. A timestamp alone allows the same signed request to repeat throughout its validity.

Run the same valid request concurrently against multiple application replicas and assert one accepted business effect. Test reuse after success, reuse after a temporary internal failure, an expired signature, future timestamp, unknown nonce, and verifier clock offset. Decide whether a failed business operation consumes the replay identifier. That choice affects safe retry and must be visible to the client and service owner.

Resolve keys through a bounded trust policy

A key identifier is a lookup input, not proof of authority. Map it to an approved signer, algorithm, public key or shared-secret reference, allowed operations, tenant scope, validity window, and revocation status. Reject unknown algorithms and identifiers before expensive work where possible. Prevent a caller from selecting an arbitrary URL or filesystem path for key retrieval.

Cache remote key material only under authenticated retrieval, bounded freshness, and failure rules. Rehearse rotation with old and new keys, queued requests, revocation, retrieval outage, and rollback. Logs can contain key identifiers and decision reasons but not shared secrets, reusable signatures, complete sensitive bodies, or private keys. Security owners control trust changes; developers receive safe fixtures or public material.

Separate verification from authorization

After signature verification, authenticate the signer’s application identity and authorize the requested resource, tenant, and action using current policy. Test a correctly signed request for another tenant, an excessive operation, a deleted account, and permission revoked after signing. Each must leave state unchanged. Do not let an integration key become implicit administrator authority.

Return stable response categories without disclosing which signature bytes nearly matched or which protected resource exists. Internally distinguish malformed signature input, unsupported algorithm, unknown key, cryptographic mismatch, stale request, replay, digest mismatch, authentication failure, authorization denial, validation error, and business conflict. Those classes have different owners and recovery actions.

Deliver a byte-level verification packet

The handoff includes topology, trust owners, covered-component rationale, signature parameters, proxy transformations, canonical fixture requests, expected signature-base hashes, body-digest tests, freshness and replay rules, multi-replica results, authorization negatives, key rotation, bounded logs, rollback, and exact code and configuration revisions. Preserve literal non-secret fixtures so another working window can reproduce the base without guessing.

Acceptance requires one unambiguous message form at the verification hop, mutation failures for every covered component, unchanged state on all denied cases, bounded replay, scoped keys, and a tested rotation path. Developer Offshore can implement parsing, fixtures, verifier integration and evidence while the client security, platform and product owners retain proxy trust, key authority, business permissions, and release approval.

Questions about assessing Philippine developers