MetaMask(メタマスク) Security: A Guide to Protecting Yourself from Scams

Almost nobody loses assets from a browser wallet because someone defeated its cryptography. They lose them because they approved something. A prompt appeared, it fitted the task they were already in the middle of, and they pressed the confirming button.

That is the whole shape of the problem — and it is also why the defence is learnable. If value can only leave a self-custodial account through an authorisation you gave, then reading authorisations carefully is not one security habit among many. It is the habit.

This guide covers four things. First, what a browser wallet such as MetaMask actually protects and the specific things it cannot protect you from. Second, why the approval step is the target, including the three different kinds of request that can move assets — and the one that surprises people most, a signature with no transaction attached. Third, the seven scam patterns that recur, and the single tell that gives each of them away. Fourth, the checks on a site, an extension or a person claiming to be support that take seconds and settle the question.

Nothing in this guide asks you to connect a wallet, approve anything, install anything, or send us any information.

What a browser wallet protects, and what it does not

A browser wallet does two jobs. It keeps a private key encrypted on your own device, and it shows you a prompt before that key signs anything. It protects the key well. It cannot protect the decision you make once the prompt is on screen.

Self-custodial wallets derive their accounts from a single secret — in MetaMask's terminology, a Secret Recovery Phrase. The vendor's own support documentation is explicit that this phrase controls the accounts and that anyone holding it can use them.^[10] Three consequences follow, and they are worth stating plainly because most scams depend on at least one of them being misunderstood:

• There is no account to lock. The phrase is not a password on a server. It can be used from any device, at any time, without notifying you and without any check that you are the person who created it.
• There is no reset path. Nobody at the vendor can revoke a phrase that has leaked, because nobody at the vendor holds it or knows which accounts it belongs to.
• There is no undo. A transaction confirmed on a public chain is final by design. That is a property of the system, not a support failure.

The local password you set is a different thing entirely. It decrypts the wallet's storage on that one browser profile. It is a good lock on one door; it is not an account credential, and it does nothing for a key that has already been copied elsewhere.

Why scams target the approval, not the cryptography

Attackers do not attack signature schemes. They attack the moment a person who is mid-task, mildly hurried and reasonably trusting is shown a request and decides to confirm it. That moment is cheap to attack and expensive to defend, which is exactly why it is where the effort goes.

How a site talks to a wallet at all

A website communicates with a browser wallet through a provider object the extension injects into the page. The interface is standardised as EIP-1193, which defines the request method, the events and the error semantics.^[1] When more than one wallet is installed, EIP-6963 defines how a page discovers each of them rather than fighting over a single global variable.^[2]

What matters for security is what “connecting” does and does not do. Connecting lets a site learn your account addresses and lets it ask you for things. It does not hand the site the ability to move anything. Every movement still needs a separate, specific authorisation from you. This is why treating the connect step as the dangerous one is a mistake that leaves people relaxed at precisely the wrong moment — the approval that follows.

The request types you will be shown

Four request types account for nearly everything you will ever be asked to confirm. Knowing which one you are looking at tells you what is at stake.

The row that catches people is the third. A request that shows no amount, charges no network fee and says something reassuring about “verifying” is still capable of granting a permission. Fee-free does not mean consequence-free.

Allowances: the permission that outlives the moment

The ERC-20 token standard separates the act of granting permission from the act of using it. A holder calls approve to set an allowance for a spender address; that spender may then call transferFrom to move up to the approved amount — at any later time, with no further prompt to you.^[3]

This design is what makes decentralised applications usable, and it is also the single most exploited primitive in wallet fraud. Two properties do the damage. The amount is frequently set to the maximum the type allows rather than the amount actually needed, and the permission persists indefinitely until it is changed. A grant made months ago on a page you have forgotten remains exactly as valid as one made a minute ago.

Collectible standards concentrate this further. ERC-721 and ERC-1155 both define setApprovalForAll, a single call that authorises an operator to manage every token you hold in that contract.^[4][5] One confirmation, whole collection, indefinite duration.

Signatures that grant permissions

ERC-2612 adds a permit function to the token pattern: an allowance can be granted by an EIP-712 signature rather than by a transaction.^[7] The holder signs; someone else submits it and pays the fee.

The legitimate purpose is convenience — a new user can act without first holding the network's fee token. The consequence for a reader of prompts is that the boundary between “a signature is harmless” and “a transaction is serious” simply does not hold. A signature can be the permission. This is the mechanism behind the pages that ask you to “sign to verify ownership” and nothing visibly happens, until later.

Three routes by which value leaves an account

1. Route 1
   You confirm a transaction Assets move now

   Visible, immediate, and the one everyone expects.

2. Route 2
   You confirm an allowance Permission persists Spender pulls assets later

   The second step needs no further prompt and can happen any time.

3. Route 3
   You sign typed data Signature becomes a permission Spender pulls assets later

   No fee, no transaction in your history, same eventual effect.

Seven scam patterns you will actually meet

Campaigns change constantly; the structures underneath do not. Every pattern below needs one of exactly two things from you: a secret you should never share, or an approval you did not understand. Learning seven shapes is faster, and lasts longer, than learning every campaign.

1. The support impostor

You post a problem in a public forum, a Discord server or a social thread. Replies arrive within minutes — sometimes seconds — from accounts using the product's name and logo. The conversation moves to a private channel, and you are directed to a “validation”, “synchronisation” or “restoration” form.

The tell: support that came to you. Vendor help desks answer tickets you opened; they do not monitor the internet for your complaint and message you first. MetaMask's own safety documentation states that its support will never ask for a Secret Recovery Phrase.^[9]

What to do instead: close the conversation, and reach support only through the vendor's own site, opened from a bookmark you made earlier.

2. The lookalike site

A domain that differs from the real one by a swapped letter, an added hyphen, a different top-level domain, or a character from another script that renders almost identically. The page is often a byte-accurate copy, because copying a public front end is trivial. The only reliable difference is in the address bar.

The tell: how you arrived. A link in a message, a search result, or a promoted placement are all routes an attacker can buy or plant. Browser-level blocklists such as Google Safe Browsing catch known-bad pages,^[20] but a domain registered this morning is not yet known-bad.

What to do instead: arrive by your own bookmark, or by typing the domain you already know. Treat every other route as unverified.

3. The counterfeit extension

A store listing with the expected name, the expected icon, plausible screenshots and a small number of positive reviews. Both major extension stores publish policies prohibiting deceptive listings and impersonation, and both act on reports,^[21][22] but review happens on their timetable, not yours.

The tell: the publisher field and the permission list, neither of which most people read. A wallet-adjacent extension asking to read and change data on every site you visit is asking for a great deal.

What to do instead: reach a store listing only by following the link from the vendor's own website, never by searching the store. Audit what is already installed and remove anything you cannot account for.

4. The drainer page

A page whose visible purpose is a claim, a mint, an eligibility check or an airdrop, and whose actual purpose is to produce approval prompts. The sequence is often deliberate: a harmless-looking signature first, to establish that pressing the button produces no visible harm, and then the request that matters.

The tell: a mismatch between the stated action and the requested permission. “Check whether you are eligible” does not require authority over your tokens. If the prompt grants more than the button promised, the promise was the lie.

What to do instead: close the prompt. Rejecting costs nothing and is always reversible; confirming may be neither.

5. Address poisoning and clipboard tampering

Two techniques with the same target: the moment you copy a destination address. In address poisoning, an attacker sends a zero-value or negligible transfer from an address generated to match the first and last characters of one you genuinely use, so that a plausible-looking entry sits in your history waiting to be copied. In clipboard tampering, malware on the device simply replaces what you copied.

The tell: both defeat the habit of checking only the beginning and the end of an address — the exact part they are built to match.

What to do instead: never copy a destination from transaction history. Use a source you control, and verify characters from the middle of the string as well as the ends.

6. The long-game funnel

A recruiter with a role that fits you well. A mentor offering to explain a strategy. A new acquaintance who is easy to talk to. Days or weeks of entirely ordinary conversation, then a task: run this assessment file, complete this onboarding, try the platform with a small amount first. The United States Federal Trade Commission's consumer guidance describes this family of approaches and the pressure tactics that accompany it.^[16]

The tell: the request always arrives after trust is established, and it always carries a reason it cannot wait.

What to do instead: separate the relationship from the transaction. Any proposal that survives a week of delay and an outside opinion loses nothing by waiting; one that does not survive them was the point of the relationship.

7. The infostealer and the “remote support” session

A fix that requires running an installer, opening a document that asks to enable content, or letting a helpful stranger view or control your screen. Once code runs with your privileges, or a third party is watching, the wallet's local encryption is no longer the deciding factor.

The tell: the proposed remedy needs more access than the reported problem could possibly justify. The UK National Cyber Security Centre's public guidance repeats the same principle across contexts: unexpected requests to run or install something are the warning.^[14]

What to do instead: refuse screen sharing and remote control for anything involving accounts or wallets, without exception. No genuine diagnosis of a wallet problem requires either.

How to read a request before you approve it

Five questions settle almost every case: what am I actually authorising, who is the counterparty, does this match what I just did, does it need to be permanent, and what happens if I simply wait? If any answer is unclear, the correct action is to close the prompt and lose nothing.

1. What is being authorised, in plain terms?

   Decide first whether you are being asked for a transaction or a signature, then what that object actually does. “Approve”, “permit” and “set approval for all” grant standing permission over your holdings; a transfer moves a specific amount once. These are categorically different and should feel different.

2. Who is the counterparty?

   The prompt shows the requesting origin. Read it as a domain, character by character, not as a logo. For typed data, the EIP-712 domain identifies the contract the signature is scoped to^[6] — a field worth looking at precisely because it is the one a copied front end cannot fake without changing what the signature does.

3. Does it match the action I just took?

   You pressed a button with a stated purpose. If the prompt asks for authority that purpose does not need, the mismatch is the finding. Checking eligibility does not require spending authority; connecting to view a page does not require permission over a collection.

4. Does it need to be permanent?

   An unlimited, indefinite allowance is a convenience decision with a security cost, and it is often presented as the default rather than as a choice. Treat “unlimited” as a claim that needs justifying.

5. What happens if I simply wait?

   Genuine operations tolerate delay. Countdown timers, vanishing allocations and “last chance” framing are engineered pressure, not information. If a minute of delay destroys the opportunity, the opportunity was the bait.

Verifying a site, an extension and a “support” contact

Verification is mostly a habit of arriving rather than a habit of inspecting. If you always reach a service by a route you established when nothing was urgent, most impersonation fails before you ever have to spot it.

One general point about the padlock in the address bar: transport security proves the connection is encrypted and the certificate matches the domain. It says nothing about whether the domain's owner is honest. A phishing site can hold a perfectly valid certificate, and most do. The Ethereum Foundation's own security material makes the same distinction between securing a channel and trusting a counterparty.^[11]

Hardening the layer attackers actually break

Most wallet compromises begin somewhere other than the wallet: a reused password, an email account without strong authentication, an unpatched browser, or an extension with far more permission than its function requires. Raising the cost at those points raises it for every pattern above at once.

Start with the email account

The mailbox is the reset path for nearly everything else, which makes it the highest-value target in the chain. NIST's authentication guidance in SP 800-63B sets out why authenticator strength and resistance to interception matter more than password composition rules,^[12] and the phishing-resistant approach it points toward is now widely available to consumers as passkeys and hardware security keys.^[13] A one-time code typed into a page can be relayed by an attacker in real time; a bound credential cannot be, because it will not present itself to the wrong origin.

Then the ordinary, unglamorous things

• Unique credentials everywhere. Reuse converts any single breach into access to everything sharing that password.
• Current software. Browser, operating system and extensions. Public exploitation usually follows a patch, not a discovery.
• An extension audit you actually perform. Remove what you no longer use and what you cannot account for. Permissions granted once persist silently.
• Separation. Using a distinct browser profile for sensitive activity limits what a compromised page or extension in your everyday profile can observe.
• Scepticism about files. Unexpected attachments, “assessment tasks” and installers offered in support of a fix are the common delivery route for credential stealers.^[15]

None of this makes anyone immune, and it would be dishonest to present it that way. What it does is shift you out of the population that a scaled, opportunistic campaign can convert cheaply — which is the population those campaigns are built for.

If you think you have been targeted

Slow down, then work in a fixed order: stop ongoing access, preserve evidence, report. And treat every offer of recovery that arrives afterwards as part of the attack until it is proven otherwise, because that is what it usually is.

1. Stop what is still running

   If you ran a file or allowed a remote session, disconnect the device from the network. Do not carry on using it for anything sensitive, and do not enter a recovery phrase on it — or on any device — while you work out what happened.

2. Work from a device you trust

   Change passwords and review authentication settings from a different, known-clean device, beginning with the email account, because it controls recovery for the rest.

3. Write it down while it is fresh

   Times and dates, the exact addresses of pages you visited, account names that contacted you, transaction identifiers, and screenshots of the messages. Contemporaneous notes are worth far more to any subsequent report than a reconstruction a week later.

4. Report to the authority that covers you

   In the United States, the FBI's Internet Crime Complaint Center takes reports^[17] and publishes aggregate findings annually.^[19] The Federal Trade Commission publishes consumer guidance on the same category.^[16] In the United Kingdom, the NCSC provides reporting routes for phishing and fraud.^[14] Elsewhere, report to your national police service or computer emergency response team.

Six claims that sound right and are not

Some widespread beliefs are close enough to true that they survive scrutiny while still leaving a gap. These six are worth correcting precisely because the people repeating them are usually trying to help.

A checklist you can keep

Nothing below is exotic. It is the same small set of behaviours applied consistently, which is what separates people who get caught once from people who get caught repeatedly.

Before you confirm anything

• I arrived here by my own bookmark or by typing the domain myself.
• I have read the full domain in the prompt, character by character.
• I know whether this is a transaction or a signature, and what it grants.
• The authority requested matches the action I actually took.
• Nothing about this is time-pressured, or I have accepted losing the opportunity.
• If I am unsure of any of the above, I am closing the prompt.

As standing habits

• My recovery phrase has never been typed into any website, form, chat or file.
• My email account uses phishing-resistant authentication.^[13]
• My passwords are unique per service.
• My browser, operating system and extensions are current.
• I have reviewed my installed extensions and their permissions in the last three months.
• I never copy a destination address from transaction history.
• I do not accept screen sharing or remote sessions for anything involving accounts.
• I treat anyone who contacts me first about a wallet problem as a stranger, regardless of the name on the account.

Terms used in this guide

Secret Recovery Phrase

The word sequence from which a wallet derives its accounts. Whoever holds it controls those accounts on any device, permanently.^[10]

Provider

The JavaScript object a wallet extension injects into a web page so the page can make requests. Standardised as EIP-1193.^[1]

Allowance

A standing permission letting a named spender move up to a set amount of your tokens without prompting you again. Defined by ERC-20.^[3]

Approval for all

A single authorisation covering every token you hold in a collectible contract, defined by ERC-721 and ERC-1155.^[4][5]

Typed data signature

A signature over structured, labelled fields scoped to a domain, defined by EIP-712. More readable than raw data, and capable of carrying a permission.^[6]

Permit

An allowance granted by signature rather than by transaction, defined by ERC-2612. The reason a fee-free signature is not automatically harmless.^[7]

Drainer page

A site whose visible purpose is a claim, mint or check, and whose actual purpose is to produce approval prompts that transfer authority.

Address poisoning

Planting a negligible transfer from an address matching the first and last characters of one you use, so a wrong address sits in your history ready to be copied.

References

Every technical claim above is traceable to one of the following. Vendor documentation is cited so you can verify what the vendor itself states; those links are informational and are not a recommendation to use, install or buy anything. All sources were checked on 25 July 2026.

1. EIP-1193: Ethereum Provider JavaScript API. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-1193
2. EIP-6963: Multi Injected Provider Discovery. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-6963
3. ERC-20: Token Standard. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-20
4. ERC-721: Non-Fungible Token Standard. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-721
5. ERC-1155: Multi Token Standard. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-1155
6. EIP-712: Typed structured data hashing and signing. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-712
7. ERC-2612: Permit Extension for EIP-20 Signed Approvals. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-2612
8. Sign data. MetaMask developer documentation (informational). https://docs.metamask.io/metamask-connect/evm/guides/sign-data/
9. Staying safe in web3. MetaMask user support (informational). https://support.metamask.io/privacy-and-security/staying-safe-in-web3/
10. What is a Secret Recovery Phrase and how to keep your crypto wallet secure. MetaMask user support (informational). https://support.metamask.io/privacy-and-security/what-is-a-secret-recovery-phrase-and-how-to-keep-your-crypto-wallet-secure/
11. Security. Ethereum Foundation. https://ethereum.org/security/
12. Grassi, P. A. et al. NIST Special Publication 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management. National Institute of Standards and Technology. https://pages.nist.gov/800-63-3/sp800-63b.html
13. Passkeys. FIDO Alliance. https://fidoalliance.org/passkeys/
14. Phishing scams. National Cyber Security Centre (United Kingdom). https://www.ncsc.gov.uk/collection/phishing-scams
15. Top tips for staying secure online. National Cyber Security Centre (United Kingdom). https://www.ncsc.gov.uk/collection/top-tips-for-staying-secure-online
16. What to know about cryptocurrency and scams. Federal Trade Commission (United States). https://consumer.ftc.gov/articles/what-know-about-cryptocurrency-scams
17. Internet Crime Complaint Center. Federal Bureau of Investigation (United States). https://www.ic3.gov/
18. FBI Warns of Scammers Impersonating the IC3, PSA 250418. Internet Crime Complaint Center. https://www.ic3.gov/PSA/2025/PSA250418
19. Annual Reports. Internet Crime Complaint Center. https://www.ic3.gov/AnnualReport/Reports
20. Google Safe Browsing. Google. https://safebrowsing.google.com/
21. Chrome Web Store program policies. Google. https://developer.chrome.com/docs/webstore/program-policies
22. Add-on Policies. Mozilla Extension Workshop. https://extensionworkshop.com/documentation/publish/add-on-policies/