Caught on testnet, before the relay went live

A transaction replay attack: the same signed payment could be accepted and broadcast to the chain multiple times, risking double-spend and relayer fund drain.

Denial-of-service risk via unrestricted payload size: oversized requests were processed without limits, enabling resource exhaustion attacks.

Weak TLS and cipher configuration, exposing transaction data in transit to interception.

Missing HTTP security headers, leaving the API surface exposed to cross-origin and injection-type attacks.

API-first payment platforms and payment relay services.

Fintech companies processing high-frequency signed transactions.

Platforms building gasless or abstracted payment infrastructure.

Why does replay protection matter more in a gasless relay?

The relay itself pays the gas cost of every transaction it broadcasts, so a replay attack does not just risk double-spending a user’s funds, it can also drain the relayer’s own operating balance.

Why test this on testnet instead of waiting for mainnet?

Findings on testnet cost nothing to fix. The same findings on mainnet risk real user funds and a public incident, so testing before launch is the point of a pre-launch assessment.

Is four findings a small result for an API assessment?

It reflects a tightly scoped, single-purpose API. A focused surface with a clear specification typically produces a shorter, more precise findings list than a broad, general-purpose backend.

What is the risk of missing security headers on an API, specifically?

APIs are not just consumed by browsers, but where they are, missing headers remove a layer of defense against cross-origin misuse and certain injection classes at effectively no engineering cost to add.