home / skills / multiversx / mx-ai-skills / mvx_dapp_audit

mvx_dapp_audit skill

needs review

This skill helps audit MultiversX dApp frontend flows, focusing on transaction construction, signing security, and data handling to prevent exploits.

npx playbooks add skill multiversx/mx-ai-skills --skill mvx_dapp_audit

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.0 KB

---
name: mvx_dapp_audit
description: Auditing dApps and standard Frontend flows.
---

# MultiversX dApp Auditor

This skill helps you audit the frontend components of a MultiversX application (`sdk-dapp`).

## 1. Transaction Construction
- **Critical Logic**: The frontend constructs the payload.
- **Attack**: Can a malicious frontend user change the payload before signing?
    - Example: `func@args` -> `func@evil_args`.
- **Mitigation**: The Smart Contract MUST validate everything. Do not trust the frontend to validate inputs.

## 2. Signing Security
- **Blind Signing**: Does the dApp verify what it asks the user to sign?
- **Hash Signing**: Is the user signing a hash (opaque) or a clear message?

## 3. Sensitive Data
- **Local Storage**: Is the private key or mnemonic ever stored in `localStorage`? (Should NEVER be).
- **XSS**: Can an attacker extract the `accessToken`?

## 4. Tools
- **Burp Suite**: Proxy traffic to see what the dApp sends to the API or Blockchain Proxy.
- **Inspect Element**: Check network tab for `POST /transactions` payloads.

Overview

This skill audits frontend components of MultiversX dApps built with sdk-dapp, focusing on transaction safety, signing flows, and client-side data handling. It surfaces frontend attack vectors and practical checks so teams can fix issues before users are exposed. The goal is faster, safer dApp releases with clear mitigation steps.

How this skill works

The skill inspects transaction construction, signing flows, and sensitive client storage. It looks at network traffic, DOM/network request payloads, and local storage to detect mutable payloads, blind or opaque signing, and secrets stored insecurely. It recommends verifications the smart contract must enforce and tools to reproduce issues.

When to use it

Before a dApp launch or major frontend release that introduces new transactions.
When integrating a new wallet or signing method into the frontend.
After security reports or suspicious user reports about unexpected on-chain calls.
During regular security reviews to validate that frontend checks are not relied on for safety.

Best practices

Never trust the frontend for authorization: enforce all input validation and business rules in the smart contract.
Avoid blind or hash-only signing: present readable intent to the user and include context in signed messages.
Never store private keys, mnemonics, or long-lived secrets in localStorage or other client-side storage.
Assume XSS is possible: minimize sensitive data exposure and require short-lived tokens with strict scopes.
Inspect POST /transactions payloads via a proxy or browser devtools to verify constructed calldata matches expected arguments.

Example use cases

Detecting a mutated transaction payload where func@args becomes func@evil_args prior to signing.
Verifying that the dApp displays a clear, human-readable summary before signing instead of an opaque hash.
Confirming no private key, mnemonic, or access token is persisted in localStorage or exposed to page scripts.
Using Burp Suite or browser network tab to reproduce an attacker flow that tampers with API requests to the blockchain proxy.
Validating that smart contract enforcements reject malformed or unauthorized inputs regardless of frontend checks.

FAQ

Can the frontend be trusted to validate transaction inputs?

No. Frontend validation helps UX but must not be relied on for security; the smart contract must validate all inputs.

What tools should I use to inspect transactions?

Use browser devtools network tab and a proxy like Burp Suite to capture POST /transactions payloads and replay modified requests.