Request Signing

Overview

Request signing uses a cryptographic key to create a verifiable signature over selected request data so a server can authenticate integrity and origin. Ambiguous canonicalization, unsigned critical fields, weak key storage, long timestamp windows, nonce reuse, and inconsistent proxy rewriting can enable tampering or replay. Testing Request Signing should cover malformed input, denied access, rate limits, timeouts, duplicates, asynchronous completion, and version changes.

Secure use of Request Signing keeps secrets outside client code and logs, applies least privilege, prevents replay where needed, monitors anomalies, and separates authentication from authorization. A signing scheme may cover method, path, query, headers, body digest, timestamp, and nonce. Test vectors should cover encoding, duplicate parameters, empty bodies, and Unicode. Changes to Request Signing should be checked against older clients, stored payloads, enum growth, default behavior, and retry assumptions.

For Request Signing, metrics should separate transport success from business success. The server reconstructs the canonical representation and verifies the signature with a shared secret or public key. TLS, key rotation, revocation, and audit logging remain necessary. Implementers should follow the provider’s documented algorithm byte for byte, use protected keys, constant-time verification where relevant, and strict timestamp and nonce controls. For Request Signing, the application should preserve a correlation path from request construction through response, asynchronous completion, and final business state.

A successful transport result from Request Signing should not be interpreted beyond the exact API state documented by the provider.

Observability for Request Signing should record operation, version, principal, request ID, latency, retry count, error code, and final state without exposing secrets.