Security-first UI Components

Keythings Wallet treats the user interface as a security boundary. The custom component library is designed to detect tampering, block unsafe input, and make critical actions auditable — not just to look consistent.

Why a Custom UI Library?

Many applications can safely use generic UI kits. A browser extension wallet cannot. Keythings Wallet shares a page with arbitrary websites and other extensions, so we assume that scripts can modify the DOM or draw overlays after React has rendered.

For that reason, high-risk actions, inputs, and forms run through security-aware primitives instead of raw<button> and <input> elements. This section explains how those components protect you while you use the wallet.

Secure Action Buttons

Sensitive actions — such as approving transactions, exporting secrets, or deleting wallets — are surfaced through a dedicated ActionButton component inside the extension UI. Under the hood, these buttons are monitored by a security helper called enforceActionButtonSecurity.

DOM Tampering Detection

The wallet continuously checks that what you see on screen still matches what the code intended:

  • A MutationObserver watches the underlying button element for changes.
  • It re-reads the button label, description, and type attribute from the DOM.
  • If any of these differ from the original values (for example, if "Reject" were silently changed to "Approve"), the button is immediately disabled and a high-severity security event is logged.

This makes it much harder for injected scripts or compromised extensions to trick you by rewriting the text on a critical confirmation button.

Overlay & Clickjacking Detection

The wallet also defends against overlays that try to capture or misdirect clicks:

  • On a short interval, the extension checks which DOM element sits at the centre of each secure action button using document.elementFromPoint.
  • If a different element is found on top of the button (and it is not a child of the button), the wallet marks that button as overlayed.
  • A suspicious_activity event is recorded with details about the overlay element.

This is a defence against clickjacking-style attacks where an attacker draws a fake UI over the real wallet controls.

Development-mode Safety

In development builds, these aggressive checks are disabled to avoid false positives from React Fast Refresh and hot reloading. In production (the version users install from the store), the protections are fully enabled.

Input Sanitisation & Suspicious Input Logging

User-controlled text that flows into critical operations — such as addresses, token amounts, and memo fields — is sanitised at the UI layer before it ever reaches the wallet core.

  • Helper functions such as sanitizeUserInput and sanitizeAndReportInput remove null bytes, script tags, inline event handlers, javascript: URLs, template delimiters, backticks, and raw </> characters.
  • Inputs can be restricted to specific modes (for example address, numeric, ornote) so that unexpected characters are blocked at the source.
  • When the sanitizer has to strip out unsafe content or detects suspicious patterns, the wallet logs amalicious_input event via the internal security monitor.

These checks help reduce the impact of copy-paste attacks, invisible control characters, and other tricks that can influence how data is interpreted downstream.

Form Integrity & Tamper Checks

For multi-step flows like sending tokens, the wallet verifies that the transaction you submit still matches what you reviewed on the confirmation screen.

  • When you review a transaction, the wallet takes an "integrity snapshot" of key fields such as the recipient address, selected token, and amount.
  • Just before submission, the extension recomputes those values from the current UI state and compares them to the snapshot.
  • If anything has changed unexpectedly (for example due to a script trying to race the UI), the wallet rejects the submission, forces a re-review, and logs a high-severity unauthorized_access event.

This protects against last-moment mutations of transaction details between the review and the final approval.

How This Compares to Generic UI Kits

Popular UI libraries (such as shadcn/ui, MUI, or Chakra) focus on visual consistency and accessibility. They are excellent building blocks for many applications, but they generally assume that the DOM is honest and that scripts will not attempt to tamper with rendered elements.

Keythings Wallet adds a layer of security on top of the visual design:

  • High-risk confirmation buttons are monitored for label, description, and behaviour changes.
  • Overlays on top of those buttons are actively detected and recorded.
  • Inputs feeding into sensitive operations are sanitised and tracked for suspicious content.
  • Multi-step forms take integrity snapshots and will not submit if transaction details drift from what you saw.

Together, these measures make the wallet more resilient to UI-level attacks than applications that rely exclusively on generic component libraries.

Who Benefits from These Protections?

These protections are active for everyone using the production extension — they are not just developer tools.

  • Everyday users gain stronger guarantees that the actions they approve in the UI match what the wallet actually submits.
  • dApp users benefit whenever a site triggers wallet flows, because the same secure components are used for those approvals.
  • Auditors and developers can inspect and rely on these primitives when reviewing the extension or building on top of it.

The goal is simple: make UI manipulation attacks harder to pull off, easier to detect, and safer to recover from, without requiring users to change how they interact with the wallet.

15 of 33