Most teams commission a penetration test for a clear reason: a launch, a funding round, an exchange listing, or a regulator asking for evidence. What they don’t always know is what the engagement will actually ask of them. For example, how much access do the testers need? Will testing disrupt production? What happens when a critical issue turns up on day three?
The answers matter more than they might seem. A pentest’s value depends heavily on what happens before testing starts and after the report lands. A tightly scoped engagement with the right access and a clear remediation plan produces findings a team can act on. A rushed one produces a PDF that sits in a folder.
This guide walks through a Web3 penetration test from the client’s side: how scoping works, how to prepare your team and environment, what testers are doing while they work, how findings are rated, and what the remediation and retest process looks like.
What Happens Before a Penetration Test Starts?
Before anyone sends a single request, the testing team and the client agree on what the engagement is meant to achieve and exactly what is in scope. At CertiK, this starts with a detailed scoping questionnaire covering every in-scope system, application, and critical component.
Scope in Web3 is rarely a single application. A typical engagement might include a web front end, backend APIs, a mobile wallet, a browser extension, cloud infrastructure, and the integrations that connect all of them to on-chain contracts. The questionnaire helps map these pieces so the team can refine the engagement's goals, tailor the testing methodology, and understand the architecture well enough to test it without disrupting operations.
Scoping is also where you decide how much the testers will know going in. In a black-box test, testers work from the outside with little or no internal knowledge, much like an external attacker. In a white-box engagement, they have access to source code and documentation, which lets them find issues dynamic testing alone would miss. Many engagements blend the two.
Who You’ll Work With
A CertiK engagement is staffed by three roles:
- Delivery Manager: your primary point of contact, responsible for keeping the project on schedule, maintaining quality standards, and managing communication between your stakeholders and the technical team.
- Lead Penetration Tester: plans and oversees the testing, coordinates the team's work, prepares the deliverables, and validates the results.
- Penetration Tester: carries out testing against the agreed scope and methodology, documents each finding with a proof of concept (PoC), and helps validate your fixes during retesting.
The preparation phase ends with the lead tester setting up a secure communication channel with your stakeholders and confirming the testing schedule.
How Should You Prepare Your Team and Environment?
The more time testers spend waiting for credentials or working around a broken staging build, the less time they spend finding vulnerabilities. A few steps ahead of kickoff make a real difference:
- Choose and stabilize the test environment. Decide whether testing will run against production, staging, or both, and freeze deployments to in-scope systems where you can. A moving target makes findings harder to reproduce.
- Provision dedicated test accounts. Create accounts at each privilege level in scope (standard user, admin, API client) so testers can probe for horizontal and vertical privilege escalation. For wallets and dApps, fund test wallets on the relevant testnets.
- Gather your documentation. Architecture diagrams, API specifications, and data flow descriptions help testers focus on high-value targets instead of reverse engineering basics. For white-box engagements, confirm repository access in advance.
- Map your trust boundaries. Know where your signing infrastructure lives, which services hold privileged keys, and how your backend learns about on-chain events. These are the areas Web3 attackers care about most.
- Name a responsive point of contact. Someone on your side should be able to answer questions, unblock access, and receive urgent findings during testing hours.
- Brief the right people. Let your operations and security teams know testing is scheduled so alerts aren't mistaken for a live incident, and check whether your cloud or hosting providers have testing policies you need to follow.
- Plan remediation capacity. Findings are only valuable once they're fixed. Reserve engineering time after the report arrives rather than hoping to squeeze fixes into an already full roadmap.
What Happens During a Penetration Test?
Once testing begins, the engagement moves through three phases that mirror how a real attacker would approach your systems.
Reconnaissance and application mapping
Testers start by building a picture of your attack surface. Passive reconnaissance gathers publicly available information, such as exposed services and public certificates, using tools like Shodan and Censys. Active reconnaissance then identifies live hosts, open ports, and running services. At the same time, testers manually walk through your applications to document every input, parameter, and process. The result is a detailed map of where an attacker could get in, which often turns up assets the client didn't know were exposed.
Vulnerability discovery
With the map in hand, testers prioritize high-value targets and begin probing them. Testing follows established methodologies like the OWASP Testing Guide and PTES, supplemented by Web3-specific test cases built from CertiK's experience. These cover how your application interacts with the blockchain, such as how your backend handles deposits, validates tokens, and stays consistent with on-chain state. When testers encounter advanced controls like end-to-end encryption, they reverse engineer the application to understand and work around them, just as a determined attacker would.
Vulnerability confirmation
Finding a potential issue isn't the same as proving it matters. In this phase, testers confirm that each vulnerability is exploitable and assess its real impact. They also chain issues together to show business risk. For example, a client-side flaw paired with a server misconfiguration might combine to allow a full account takeover, even if neither looks severe alone. Each attack chain is documented with reproduction steps, the tools used, and a concise PoC so your team can verify and prioritize it.
What if a critical issue turns up mid-engagement?
You shouldn't have to wait for the final report to learn about a serious, exploitable risk. Agree with your Delivery Manager during scoping on how urgent findings will be escalated, and who on your side receives them.
How Are Penetration Test Findings Rated?
Every finding in a CertiK report receives a severity rating that reflects its potential impact and how hard it is to exploit. These ratings tell you what to fix first.
| Severity | What it Means | Examples |
|---|---|---|
| Critical | Can lead to wallet secret compromise, account takeover, or direct financial loss | Remote code execution, SQL injection enabling data exfiltration, race conditions allowing unauthorized financial gain |
| High | Serious impact, often requiring multiple steps to exploit | Privilege escalation, unauthorized API access, unpatched software components |
| Medium | Impactful but less likely to cause immediate, significant damage | Hardcoded sensitive information, bypassed account lockouts, logic errors in pricing calculations |
| Low | Hard to exploit without specific access or multiple preconditions | APIs revealing limited information, missing root or jailbreak detection |
| Informational | Deviations from best practice with no immediate risk | Disclosed server versions, missing rate limiting |
| Discussion | Suspected issues that couldn't be fully validated during testing | A possible backend flaw observed during black-box testing |
The Discussion category deserves a closer look. Testing constraints sometimes prevent a tester from fully confirming an issue, especially in black-box engagements where backend access is limited. Rather than dropping these observations or overstating them, they're flagged for follow-up with your team. Treat them as leads worth investigating, not noise.
What Happens After You Receive the Report?
The report is the start of the most important phase, not the end of the engagement. Each finding comes with a clear description, an impact analysis, a PoC, and recommended remediation steps, giving your engineers what they need to reproduce and fix the issue. From there, the process looks like this:
- Triage and plan. Review findings with your team and the Delivery Manager, starting with Critical and High issues. Ask questions early, since it's easier to clarify a finding while it's fresh.
- Remediate. CertiK clients have a three-month window to address findings, and can update the remediation status of each issue through CertiK's platform as work progresses.
- Retest. Testers verify each fix across multiple retest rounds. This catches partial fixes, which are common when a patch closes one path to a vulnerability but leaves another open.
- Receive the final report. Once retesting is complete, CertiK issues a final report documenting the results, giving you evidence of remediation to share with stakeholders, partners, or regulators.
Teams that plan remediation capacity before the engagement tend to move through this phase much faster. Teams that don't often find the three-month window closing with critical items still open.
How CertiK Helps
CertiK's penetration testing team combines traditional application and infrastructure testing with blockchain-specific threat analysis, covering web applications and APIs, mobile wallets, browser extensions, cloud and network infrastructure, and source code. Our testers hold industry-recognized certifications including OSCP, OSEP, OSWE, CREST, and CISSP, and bring hands-on experience across both Web2 and Web3 environments.
Every engagement is structured to make preparation straightforward and results actionable, from a guided scoping process and a dedicated Delivery Manager to detailed findings with PoCs, a three-month remediation window, and iterative retesting until fixes are verified. Learn more about our penetration testing services here.
FAQs
How do I prepare for a Web3 penetration test?
Start by completing a thorough scoping process that identifies every in-scope system, including applications, APIs, wallets, and infrastructure. Then provision test accounts at each privilege level, stabilize the test environment, share architecture documentation, and name a point of contact who can respond quickly during testing.
What is the difference between black-box and white-box penetration testing?
In a black-box test, testers have little or no internal knowledge of the system and approach it as an external attacker would. In a white-box test, they have access to source code and documentation, which helps uncover issues that dynamic testing alone might miss. Many engagements combine both approaches.
Will a penetration test disrupt my production systems?
A well-run engagement is designed to be non-disruptive. During scoping, the testing team learns your architecture and agrees on which environments, systems, and techniques are in scope, so testing can proceed without interrupting normal operations.
How long does a Web3 penetration test take?
It depends on the scope. An engagement covering a single web application takes far less time than one spanning mobile wallets, browser extensions, APIs, and cloud infrastructure. The timeline is agreed during the preparation phase, and remediation and retesting continue after testing ends.
What happens after vulnerabilities are found?
You receive a report detailing each finding with its severity, impact, proof of concept, and recommended fix. CertiK clients then have a three-month window to remediate, with multiple rounds of retesting to verify fixes and a final report documenting the results.