Web3 Penetration Testing Explained: Scope and Methodology
Quick answer. Web3 penetration testing is a simulated attack on the systems around smart contracts: web apps, APIs, cloud, wallets, signers and keepers. An audit reads contract code; a pentest shows what those systems can be made to sign.
Video transcript
A smart contract audit reads the code that holds the money. Many of the largest crypto losses never touched that code.
Chainalysis found private key compromises were the largest share of crypto stolen in 2024, at 43.8 percent.
A web3 pentest is an authorized, simulated attack on anything that can hold a key, build a transaction or decide what gets signed.
Scope runs from the browser to the chain: web apps, APIs, cloud, wallets and extensions, keys and signers, and automated keepers.
Many engagements follow the Penetration Testing Execution Standard. After pre-engagement, threat modeling maps whatever can move funds. Testers exploit what they find, follow the foothold toward a signing key, and close with reporting.
An audit asks whether contract code can break its own rules. A pentest asks what an attacker can reach, sign or steal. Most teams that hold funds need both.
The gaps sit at the seams. Guardian's review of the GMX keeper returned 55 findings, eight of them High. Most Highs sat where the keeper disagreed with the contracts.
Guardian's offchain services are led by Carlos Polop, creator of HackTricks. On the Avantis V2 backend, two independent teams returned 68 findings, including two Criticals, both fixed mid-review. Every pentest closes with a retest.
Read the full guide, then talk to Guardian at guardian.security about pentesting the systems around your contracts.
A smart contract audit reads the code that holds the money. Many of the largest crypto losses never touched that code.
Chainalysis found that private key compromises were the largest share of crypto stolen in 2024, at 43.8%.
On October 29, 2026, about $6.36 billion left Binance wallets. TRM Labs says the evidence points to a compromise of Binance's hot wallet signing infrastructure.
Binance has yet to publish a root cause.
Those systems are what a web3 pentest attacks. This guide covers what it is, what it tests, how it runs and what you get.
What Web3 Pentesting Is
NIST defines penetration testing as security testing in which evaluators mimic real-world attacks to find ways around a system's security features.
Testers use the tools and techniques attackers use. They look for combinations of weaknesses that grant more access than any one alone.
A web3 pentest applies that to a crypto company. The target is every system that can hold a key, build a transaction or decide what gets signed.
It is authorized, scoped and time-boxed. The output is evidence: what the testers reached, how they reached it, and what an attacker could do from there.
Scope: Everything Around the Contract
A full scope follows the path from a user's browser to the chain. Most engagements cover some of these surfaces.
| Surface | What testers attack |
|---|---|
| Web app and frontend | Login, recovery, authorization, withdrawals, scripts in the bundle |
| APIs | Key scoping, per-object checks, rate limits, endpoints that send transactions |
| Cloud and CI/CD | IAM, secrets, pipelines, vendor consoles that can change production |
| Wallets and extensions | Key storage, signing flows, internal messaging, who can publish updates |
| SDKs | Transaction construction, trust in responses, repository versus published package |
| Keys and signers | Who can move funds, what signers see, custody and multisig setup |
| Keepers, relayers and bots | What each automated key can call, hostile inputs, failure behavior |
| Telegram Mini Apps | Server-side initData checks, authorization of value-moving actions, the bot token |
| AI agents and MCP servers | Auth, tool poisoning, transport and supply chain |
Several surfaces have their own guides: crypto wallet pentesting, Telegram Mini App security and the MCP pentesting checklist.
For what these tests turn up, read our report on offchain pentest findings in DeFi.
Methodology and Threat Modeling
Two public references shape many engagements. The Penetration Testing Execution Standard (PTES) sets out the phases.
OWASP's Web Security Testing Guide (WSTG, stable at v4.2) sets out the web tests.
The seven PTES phases, applied to web3
- Pre-engagement: scope, rules of engagement, test windows, emergency contacts, signed permission.
- Intelligence gathering: domains, repositories, cloud assets, people and deployed contracts.
- Threat modeling: the assets worth stealing and who could come for them.
- Vulnerability analysis: finding weaknesses by hand and with tools.
- Exploitation: proving them, on staging, a testnet or a fork where possible.
- Post exploitation: following the foothold. Does it reach a signing key?
- Reporting: evidence, impact and fixes.
Threat modeling starts from the funds
PTES models assets and attackers. It says business assets, business processes, threat communities and their capabilities should be documented in every test.
In web3, the assets are whatever can move funds: hot wallets, admin roles, multisig signers, keepers and signing services.
The model then traces who can reach each one: an outside attacker, a phished employee, a compromised vendor or an insider.
PTES says the model should be built with the organization where possible, and delivered in the final report.
Where OWASP fits
WSTG v4.2 includes a business logic chapter, with tests for process timing, usage limits and workflow circumvention.
Its introduction says this type of flaw "cannot be detected by a vulnerability scanner." That is why withdrawals and limits need human testers.
For APIs, OWASP's API Security Top 10 (2023) ranks broken object level authorization first.
What the Report Contains
PTES splits the report in two: an executive summary for leaders and a technical report for engineers.
A useful web3 pentest report includes:
- The scope, the test window, and the build or commit tested.
- The threat model: assets, attackers and paths to funds.
- Each finding with severity, location and reproduction steps.
- Evidence of impact, such as a proof of concept on a fork.
- A fix for each finding, and its retest result.
- A remediation roadmap, ordered by business impact.
PTES says the report's post exploitation section should "tie the ability of exploitation to the actual risk to the business." In web3, that means showing which funds or keys a finding reaches.
It also notes that "Root Cause is never a patch." A good report names the process that let the weakness ship.
Pentest vs Smart Contract Audit
The two answer different questions. Most teams that hold funds need both.
| Smart contract audit | Web3 pentest | |
|---|---|---|
| Target | Contract code at a pinned commit | Running systems around the contracts |
| Question | Can the code break its own rules? | What can an attacker reach, sign or steal? |
| Method | Manual review, fuzzing, invariants | Simulated attacks under rules of engagement |
| Access | Repository and commit | Environments, test accounts, ideally source |
| Typical findings | Logic, accounting, access control, oracle flaws | Broken auth, races, exposed secrets, cloud paths to keys |
The gaps sit at the seams. GMX's keeper re-derives much of the contracts' pricing and risk math in TypeScript, and each copy can drift from the original.
Guardian's GMX keeper review returned 55 findings, eight of them High. Most of the Highs sat where the keeper disagreed with the contracts.
For the contract side, see what a smart contract audit is.
How to Scope an Engagement
Send the facts a tester needs before the first call:
- Every surface in scope: apps, APIs, cloud accounts, extensions, SDKs, keepers.
- Each user role, with test credentials for each.
- Source repositories: the only way to be certain nothing reachable was missed.
- API documentation, such as a Swagger file or Postman collection.
- Environments and chains, and whether production is in or out.
- Rules of engagement: windows, emergency contacts, third-party permissions.
- The frameworks the report must map to, and the retest rounds you expect.
Hosting and cloud providers may need to grant their own permission, PTES notes, before their systems are tested.
Price follows scope. See what a web3 pentest costs and how the best web3 pentesting firms compare.
Running an exchange? Read crypto exchange pentesting.
How Guardian Pentests
Guardian's offchain services are led by Carlos Polop, Head of Offchain Services, who created HackTricks and the PEASS privilege escalation suite.
The offchain engagements cover infrastructure, web app, API, browser extension and offchain automation pentests, plus SDK and OpSec audits.
On the Avantis V2 backend, the offchain teams worked beside the researchers reviewing the V2 contracts. Two independent teams returned 68 findings, including two Critical and six High.
Both Criticals were fixed while the review was still running. Every Guardian pentest is closed out with a retest.
For onchain teams, Vanguard returns half the package cost as credits toward offchain assessments. See how pentests fit with audits and Managed Security on the onchain teams page.
Frequently Asked Questions
What is a web3 penetration test?
An authorized, simulated attack on the systems around a crypto company's smart contracts, such as web apps, APIs, cloud, wallets, signers and keepers. It shows what an attacker could reach, sign or steal, with evidence and fixes.
Is a web3 pentest the same as a smart contract audit?
No. An audit reviews contract code at a pinned commit. A pentest attacks the running systems around it: the ones that hold keys, build transactions and decide what gets signed. Most teams that hold funds need both.
What methodology does a web3 pentest follow?
Many follow the PTES phases, from pre-engagement and threat modeling to exploitation and reporting, with OWASP's guides for web apps and APIs. Crypto adds a threat model built around funds, keys and signers.
Does a web3 pentest need source code?
Not always, but it changes what the test can prove. Source lets testers confirm every reachable function was covered. Guardian requires it for keepers and other offchain automation, and treats it as effectively required for browser extensions.
Sources
- NIST CSRC: Glossary, penetration testing (definitions from NIST SP 800-115 and SP 800-53 Rev. 5)
- PTES: The Penetration Testing Execution Standard, main sections (mirror of pentest-standard.org)
- PTES: Pre-engagement Interactions
- PTES: Threat Modeling
- PTES: Reporting
- OWASP: Web Security Testing Guide (stable v4.2)
- OWASP WSTG v4.2: Business Logic Testing
- OWASP WSTG v4.2: Introduction to Business Logic
- OWASP: API Security Top 10 (2023)
- Chainalysis: $2.2 Billion Stolen from Crypto Platforms in 2024 (December 19, 2024)
- TRM Labs: North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History (October 29, 2026)
- Guardian: Audits and pentests
- Guardian: Offchain automation pentest
- Guardian: Browser extension pentest
- Guardian: GMX keeper review case study
- Guardian: Avantis offchain review case study
- Guardian: Regulatory compliance
- Guardian: Guardian Announces Vanguard
- Guardian: Team
Pentest the systems around your contracts
Guardian's offchain team tests your apps, APIs, cloud, signers and keepers, judges findings against your contracts, and retests every fix.