Skip to main content
[AVAILABLE], all three runs below are real output from this session, commit 651497a.

Goal

Confirm three different kinds of tampering are actually caught, not just documented as caught: a changed parameter, a forged signature, and a replayed nonce.

Prerequisites

Steps

examples/tutorials/ 35 through 46 are a dedicated negative-path suite: each one generates something valid, mutates exactly one thing, re-verifies, and asserts the mutation is caught. They run in CI on every change (npm run examples), so “the tests are always green” and “the guide’s claims are true” are the same fact. Three representative ones:

1. Parameter tampering

Adding a paymentAmount field to the executable content’s parameters changes the recomputed businessTransactionHash, this is the exact mechanism The gateway runs on every real request, exercised directly here instead of through HTTP because the REST API generates and checks the authorization within one call, giving an external client no tamper point to observe.

2. Forged signature

Note which check failed and which didn’t: Version Supported and Not Expired both stayed true, only Signature Verified flipped. EnvelopeVerifier reports each check independently, a caller can distinguish “this is forged” from “this is expired” rather than getting one opaque false.

3. Nonce reuse

The exact same, unmodified authorization is verified twice. The first call marks the nonce seen; the second call, identical envelope, identical signature, is rejected solely because the nonce was already consumed, single-use enforced by the NonceStore, not by anything in the signature itself.

Verify

All three runs above completed with their respective ✓ ... detected. line and a non-zero distinguishing signal (hashMatches: false, Signature Verified: false, Nonce Unseen: false), confirmed in this session. None of the three silently passed, none threw an unrelated error instead of the expected rejection.

Troubleshoot

  • You expected an HTTP 4xx from the REST API and got something else. These three scenarios operate on the authorization envelope directly, at the library level, they don’t go through POST /execute. The REST API’s gateway rejection looks like a generic 500 with a message naming the failed check (ExecutionGateway.ts’s describeFailure, see The gateway), not a per-check breakdown like EnvelopeVerifier gives you here.
  • Want to see more variants? examples/tutorials/ also covers action substitution (37), target substitution (38), policy substitution (39), expired authorization (41), stolen authorization (43), direct API bypass (44), connector bypass (45), and TOCTOU protection end to end (46), same pattern each time: generate, mutate one thing, re-verify, confirm rejection.

Next

Verify a trust record independently

The same tamper-then-fail pattern, applied to a trust record’s own hash.

Content Binding & TOCTOU

The mechanism behind the parameter-tampering check above.