Secure transaction signing: Trezor integration into a web application

Trezor integration: where transaction signing breaks

Trezor integration into a web app looks like one button: the user clicks "Confirm," data goes to the hardware wallet, a signature comes back, the transaction is sent to the network.

The private key does not leave the device — that is the point of hardware transaction signing. The scheme usually breaks not in the cryptography, but at the interfaces: where the wallet state and the interface state diverge.

The first failure is losing connection to the device mid-operation. The user got distracted, the device went to sleep, the cable came loose after the signature was already generated.

The transaction goes to the network, while the web app remains in a "waiting" state and suggests repeating the operation.

The second is loss of confirmation status. The tab was reloaded, the session expired, the response from the device never reached the server, and the app does not know whether the operation happened.

Without a state journal and transaction hash, there is nothing to show the user, and re-signing risks creating a duplicate.

The third and most expensive is a mismatch between what was signed and what was actually sent. If the recipient address or amount is substituted after signing, the signature remains valid, but someone else's operation goes to the network.

Below we examine how these three spots are closed: where parameter verification is placed, how status is stored, and what happens on disconnection.

What changes after implementing hardware signing

While the private key lives on the operator workstation or in the service's environment variables, every signature is a manual verification of the recipient address and amount.

An error in one address character or a substituted browser extension leads to signing an operation that can no longer be canceled.

With hardware signing on Trezor, the key does not leave the device: the app forms the operation, the device shows the address and amount on its screen, and the operator confirms physically.

Operation confirmation time becomes predictable — seconds for initialization and details verification, without waiting for an external service response and without copying keys between machines.

The share of rejected operations intentionally grows: attempts to sign a modified address or amount are cut off on the device before sending to the network.

The class of incidents involving "details substitution via an infected workstation" stops reproducing in principle — only what the operator saw with their own eyes and confirmed goes to the signature.

A separate effect is process resilience during failures.

Loss or reinstallation of the workstation no longer blocks payouts: access is restored by the recovery phrase on a new device, the integration scheme and rights in the service remain the same, and the operation queue continues processing without reissuing keys.

Trezor integration: options and connection modes

The device connects to the web app in more than one way, and the chosen channel directly determines what share of the audience reaches signing. In Chromium-based browsers, signing goes directly; on other platforms, either a bridge app or a mobile client is needed. Below are the modes actually chosen between at project start.

There is no universal mode, so in the project we do environment capability detection and degradation: first try the direct channel, and if refused, show a clear path — bridge or mobile client. That way the user does not hit "device not found" without explanation.

Environment compatibility is checked separately: browser versions, corporate machine policies, local service blockers, device access permissions in different operating systems.

Each of these items becomes a separate test scenario — otherwise in prod there is a user whose signing does not work for reasons unrelated to code.

Implementation order: from audit to handover

Work goes sequentially, and the order here is not a formality: each next stage relies on the recorded result of the previous one.

If implementation starts before the current signing flow is analyzed, the scheme will still have to be changed — but already on staging, when part of the code is written and tested.

1. Signing audit. We analyze where the transaction is formed, at what point the key is applied to it, and which parts of the flow see the private part. We record places where signing goes through the server side, a browser extension, or a third-party service — they determine the scope of rework.
2. Scheme design. We determine what goes to the hardware device and what remains in the app, and how data exchange between them is described. Separately, we work through failures: device disconnected, operation rejected, recipient address did not match expected.
3. Implementation. We assemble the signing flow in code: data preparation, confirmation on the device, return of the result, and its verification before sending to the network. Each step is logged so a failure can be analyzed by journal, not reproduced blindly.
4. Staging verification. We run scenarios on the test network: normal operation, rejection, connection loss, retry, address substitution. Separately, we verify that the app cannot sign an operation without owner confirmation.
5. Implementation acceptance. We repeat key scenarios on real operations with a small sample, compare the result before and after, and record system behavior in logs. Acceptance closes with a report listing tested paths and known limitations.
6. Handover. We give documentation on the signing flow, failure handling scheme, and support instructions — so further changes go without us.

What stays with you: schemes, policies, regulations

After handover of the Trezor integration, you have not only a working signing module, but also a set of documents by which the team develops and operates it without us.

Each artifact is tested on a live scenario: it can onboard a new engineer, pass an internal security review, or change contractor without losing context.

• Signing scheme — the transaction path from assembly to sending to the network, with marks where the private key does not leave the device and the app receives only confirmation.
• Access policies — roles, scope of operations for each, limits per individual signature, and the approval procedure for large transfers.
• Recovery regulation — the procedure for device loss or key compromise: who restores access, within what timeframes, what is checked afterward.
• Operations documentation — connection, firmware update, key rotation, troubleshooting typical failures with cause and solution.
• Failure map — loss of connection, rejected signature, recipient address mismatch: what the system does in each case and where it is visible in logs.
• Responsibility matrix — who holds backups, who approves release of a new version, who responds to an incident.
• Audit regulation — which events are recorded, in what form stored, and how to export them for internal review.

Documents lie in the repository next to the code and are versioned with it: on the next change to the signing scheme, it is immediately clear which sections are outdated and need editing.

Case: hardware signing in a service personal account

What was before implementation

The service personal account signed operations with a software key: it lay in browser storage or came from an external service. Up to 12% of operations users rejected at the confirmation stage, and support handled each dispute manually — hours per review.

In signing incidents, three causes mixed: recipient address substitution by extension, key leak during copying, and network failure that looked like user refusal.

What was changed

Signing moved to Trezor hardware.

The account forms an unsigned operation and passes it to the device; the owner sees the recipient address and amount on the device screen and confirms with a button — the private key does not leave the device and does not get into browser memory even during signing.

Refusal is handled explicitly: if the device is removed or confirmation is rejected, the draft is saved and the operation returns to the queue instead of being lost.

What became

The share of rejected operations dropped below 1%, and average signing time reduced from over one hundred seconds to twenty.

Two classes completely disappeared from signing incidents: address substitution and key leak — the address is now verified on the device screen, and there is nothing to copy. Only network and user work remained.

How is hardware signing different from software signing?

Software signing keeps the private key where the code executes: in process memory, a config file, an environment variable, or secret storage.

While the perimeter is intact, the scheme is convenient — the signature is formed in the same request processing loop, without external devices and extra steps for the user.

But the threat model here is built around the environment: a malicious dependency, server access, or memory dump gives the key entirely, and then it lives outside your control.

Hardware signing moves the key to an isolated device — e.g., Trezor. The transaction is sent to the device, the owner sees its details on their own screen and confirms the action physically; only the ready signature returns.

Host compromise no longer means key compromise: the attacker needs access to the device itself and PIN knowledge, and recipient substitution runs into confirmation on the screen.

The difference shows in the cost of error. With software signing, one incident means complete loss of control over the address and urgent migration; with hardware signing, an attack more often runs into the need to confirm the operation by hand.

For server scenarios without a human nearby, software signing is used, but with key isolation and separate permissions; where the owner confirms operations, the hardware option removes a whole class of failures.

Technical doubts before connecting a device

At the approval stage, the same set of questions surfaces: can hardware signing be connected not for everyone at once, what happens if the device is lost, will the server side need rework, and which environments must be supported. Below are short answers to remove these doubts before work starts.

What happens if the device is lost?

Keys do not leave the device and are not stored on the server, so recovery goes by backup phrase on a new instance: the binding is reconfirmed, and operation history is preserved.

The scenario of losing the phrase itself is described in advance — key reissue and asset transfer go by regulation, not in emergency mode.

Is server-side rework needed?

Yes, it is not only the interface. The server side receives a new signature format and set of public keys, recipient address verification, and protection against reuse of one signature.

The scope of edits depends on the architecture: if work with the signature is already moved to a separate layer, changes are local and do not affect business logic.

Which environments will need support?

Desktop browsers work through the bridge app; mobile scenarios are built differently and have limitations by connection type.

The matrix of supported environments and behavior when the device is absent we fix before development — the user gets a clear alternative path instead of a dead end.

Let's discuss the task and come back with an estimate and plan

For analysis of Trezor integration into a web app to start from facts, not guesses, it is enough to send what already exists in the project. The closer the materials are to real code and credentials, the fewer clarifying iterations before the implementation plan.

• Signing scenarios: transfer, withdrawal, owner change, smart contract work — and where keys are currently stored.
• Flow diagram: frontend, backend, network nodes, address and limit storage — as a description or diagram.
• Account model: how the user, device, and set of addresses are linked, and how access recovery is solved.
• Limitations: supported browsers and platforms, requirements for offline signing and security policy.
• Current checks: what is already logged and which actions require confirmation on the device.
• Test environment: access to the development network, test keys, example transactions for the run.

In response come clarifications on disputed points, a work scheme with responsibility boundaries, and a stage-by-stage implementation plan: device connection, unsigned transaction assembly, address and amount verification on screen, signature return to the network.

Separately we agree on team composition: who is responsible for frontend, who for the server side and network, and at which points your engineer is needed. After that we fix the work order and the criteria by which you accept the result.