Get the Crypto Payment Security & Compliance Playbook
Back to Blog

Web3 Attack Surfaces: A Penetration Testing Overview

Code Auditing
September 10, 2026
8 min read
Key Insights

  • Web3 institutions retain traditional attack surfaces, while their integration with digital-asset control and movement introduces distinct potential paths and validation points that require specialist web3 security judgment.

  • Effective penetration testing requires a clear understanding of how a web3 institution is assembled and operated. The four-component model provides a practical abstraction of the running system, helping testers identify attack paths, trust boundaries, and testing priorities more efficiently.

  • Mastery of traditional attack surfaces is necessary but insufficient for web3 institutions. Specialist web3 security judgment is required to understand money-handling logic and validate where off-chain controls can produce on-chain financial consequences. The five web3 attack surfaces provide a structure for this web3-specific assessment.

The first three articles in this series established why crypto institutions need blockchain penetration testing (Part 1), what the discipline validates (Part 2), and how an institutional engagement can be prepared and run safely (Part 3).

This article provides an overview of the attack surfaces relevant to penetration testing a web3 institution, with particular attention to how the required coverage extends beyond traditional penetration-testing surfaces [1]. Specifically, it first defines a four-component model for web3 institutions, together with each component's responsibility, representatives, and primary attack surfaces. Building on that model, it then examines five attack-surface areas that connect inherited application and infrastructure exposures to web3-specific validation points in signing intent, approval and signing workflows, fund logic, and on-chain runtime behavior.

Blockchain Penetration Testing

Find the path in — across contracts, nodes, APIs, and cloud

Read ReportsRequest a Pentest

The components of web3 institutions

Web3 institutions, including centralized exchanges, payment providers, and DeFi projects, connect conventional application and infrastructure environments to an off-chain-to-on-chain money-handling chain [2]. They retain traditional penetration-testing surfaces while introducing additional validation points around transaction intent, signing authority, fund accounting, and on-chain execution. Identifying how these surfaces interact and which conditions may form a path to value requires specialist web3 security judgment.

To examine this expanded attack surface systematically, this section defines a four-component model: Application, Authorization and Signing, Blockchain Interaction, and Infrastructure. For each component, it describes the component's responsibility, identifies representative implementations, and summarizes its primary attack surfaces. Note that different web3 institutions may combine or outsource these components in different ways.

Component 1: Application

The Application component processes requests from users or internal operators under defined business and authorization logic, translating authorized intent into the intended business action, such as an asset transfer or recovery operation. Common representatives in web3 institutions include web and mobile applications, browser extensions, and backend APIs.

Common testing types.

  • Web Application Penetration Testing

  • Mobile Application Penetration Testing

  • Browser Extension Penetration Testing

  • API Penetration Testing

The Application component inherits traditional attack surfaces such as identity and session management, authorization and isolation, and business workflow and state-transition integrity. In a web3 institution, the business action or transaction intent prepared at this stage may subsequently be authorized by the Authorization and Signing component and executed through the Blockchain Interaction component. Failures in these controls can therefore interrupt service or propagate into direct asset loss.

Component 2: Authorization and Signing

The Authorization and Signing component receives transaction requests prepared by the Application component and produces the cryptographic signatures required for on-chain submission. Some implementations may additionally perform policy or approval checks within the signing system before producing a signature. Common representatives in web3 institutions include wallet and signing systems or services.

Common testing types.

  • Identity and Privileged Access Testing

  • Signing and Approval Workflow Testing

Traditional attack surfaces inherited by the Authorization and Signing component include privileged identity and access management, API authorization and separation of duties, and approval, recovery, and administrative workflow integrity. In web3 institutions, failures in this component can have especially severe consequences because a valid signature may directly authorize an irreversible state change or asset transfer. As the final cryptographic authorization step before on-chain submission, the Authorization and Signing component should be treated as a critical assurance priority wherever it is used.

Component 3: Blockchain Interaction

The Blockchain Interaction component submits transactions authorized by users or internal operators, confirms their execution status, and tracks the resulting on-chain state. Common representatives in web3 institutions include node or RPC gateways, indexers, and relayers.

Common testing types.

  • API and RPC Penetration Testing

  • Transaction-Submission and Relayer Abuse Testing

Although Blockchain Interaction performs a role specific to web3 operations, penetration testing of this component centers on adversarial exploitability of its inherited attack surfaces: service credentials and endpoint security, RPC and API authorization, and message and event-processing integrity—for example, whether RPC or relayer behavior can be abused, transaction submission manipulated, or chain events misinterpreted. For institutions that operate customized or self-hosted blockchain nodes, node and cluster correctness and large-scale RPC resilience—synchronization, transaction propagation, failover, and availability—are complementary concerns addressed by Blockchain Security Testing rather than penetration testing [2].

Component 4: Infrastructure

The Infrastructure component covers institution-specific infrastructure and operational systems that support or influence the other three components. Common representatives in web3 institutions include cloud platforms, network infrastructure, IAM and secret-management systems, source control and CI/CD systems, and monitoring platforms.

Common testing types.

  • External and Internal Network Penetration Testing

  • Cloud Infrastructure Penetration Testing

  • CI/CD and Software Supply Chain Testing

Infrastructure primarily inherits traditional attack surfaces, including network and service exposure, identity, privilege, and secret management, and software-delivery and supply-chain integrity. Although Infrastructure does not typically perform money-handling actions directly, its failure or compromise can lead to substantial asset loss. The Bybit and TrustWallet incidents discussed in Part 1 illustrate how compromises in software delivery and distribution channels can propagate into the money-handling chain [1].

Web3 attack surfaces

The four-component model indicates that penetration testing of web3 institutions retains much of the traditional application and infrastructure attack surface. The distinction lies in the money-handling context: weaknesses can propagate across components and affect transaction intent, signing, fund state, or on-chain execution. Identifying these paths and selecting appropriate validation points therefore requires specialist web3 security judgment.

To structure this coverage, this section groups web3 attack surfaces into five principal attack-surface areas derived from the money-handling chain and the testing scope introduced in Part 2 [2]:

  • Production environment and automation operations

  • Web and dApp frontends, authorization, and signing intent

  • Signing, approval, and withdrawal authorization chains

  • Fund business logic

  • On-chain transactions and deployed contracts

Production environment and automation operations

The production environment supports every stage of the money-handling chain. A conventional infrastructure, identity, or software-delivery foothold may not move funds directly, but it may alter Application behavior, reach Authorization and Signing, or influence Blockchain Interaction. Blockchain penetration testing therefore evaluates the foothold's reachable impact on the money-handling chain rather than treating the infrastructure finding as an isolated endpoint [2].

Testing focus. Testers validate whether access, deployment, secrets, or operational controls can be chained toward a money-handling action. A scenario may begin with an exposed service, compromised identity, workload credential, build token, dependency, or vendor integration, then assess whether IAM, segmentation, secret handling, change control, and service authorization prevent further reach. The resulting evidence should link the operational foothold to the components and value-moving actions it can influence.

The detailed analysis [3] examines how compromise of the production environment can propagate through deployment and operational controls into money-handling components.

Web and dApp frontends, authorization, and signing intent

Web and dApp frontends are the primary interaction layer where users and operators initiate and review money-handling actions and participate in the authorization and signing flows through which those actions are approved. This position makes them attractive targets for phishing and frontend hijacking, since control of the interface can manipulate the context or content of a transaction request before it reaches a wallet or signing system [1].

Testing focus. Testers validate whether the transaction presented to a user or operator can diverge from the action ultimately authorized. The assessment follows the request from application authentication and authorization through transaction construction, wallet presentation, signature, and submission, considering whether session state, wallet permissions, simulation, chain context, contract context, or display logic can alter meaning. Evidence should preserve the presented action, actual payload, resulting signature, and submitted behavior.

The detailed analysis [4] follows transaction intent from application presentation through wallet authorization to the signed or submitted result, focusing on where the meaning of the action can diverge.

Signing, approval, and withdrawal authorization chains

Signing is often a money-moving action, but cryptographic validity alone does not establish correct business authority. The security outcome also depends on who initiated the request, which policy was applied, what the approvers reviewed, and whether the payload remained unchanged. A weakness in this control chain can cause a legitimate signer to authorize an unintended action [2].

Testing focus. Testers validate whether identities, roles, policy checks, or approval steps can be bypassed or combined. Scenarios may assess whether one identity can initiate and approve an action, whether a destination or limit change becomes effective without independent review, whether policy is enforced at the signer or only in an interface, or whether a payload can change after approval. Evidence should document the tested sequence, the controls crossed, and the unauthorized action enabled.

The detailed analysis [5] examines whether institutional approval and signing workflows preserve business authority from transaction initiation through signing and withdrawal execution.

Fund business logic

Custodial institutions rely on off-chain state to determine balances, obligations, and whether value may be released. An unintended credit or state transition can therefore become a direct financial loss even when no signing key or smart contract is compromised. Testing must consider the economic invariant and reconciliation path, not only whether an individual API behaves as implemented [2].

Testing focus. Testers validate whether balances, limits, reconciliation, withdrawal rules, or state transitions accept unintended conditions. Scenarios may examine whether a deposit is credited without the expected value, whether one event produces multiple credits, whether precision or concurrency changes a balance, or whether an invalid state becomes withdrawable. Evidence should capture the resulting state transitions and a reproducible business-impact path rather than only a technical defect.

The detailed analysis [6] examines how unintended off-chain fund state can be created, propagated, and converted into withdrawable value across institutional workflows.

On-chain transactions and deployed contracts

The on-chain handoff is where off-chain intent becomes public runtime behavior. Transactions may be irreversible, and deployed contracts are publicly callable and composable with systems outside the institution's direct control. The assessment must therefore preserve the relationship between the intended action, submitted transaction, observed execution, and state interpreted by the institution [2].

Testing focus. Testers validate how the institution's on-chain interactions behave under adversarial runtime conditions. Scenarios may examine whether transaction fields can change across construction, signing, and submission. They may also assess whether RPC or relayer behavior affects the action, whether chain events are interpreted correctly, and whether deployed permissions, upgrades, or protocol composition alter the expected result. Evidence should preserve the submitted transaction, relevant chain context, and observed runtime outcome.

For this area, penetration testing remains focused on adversarial runtime interaction and transaction-level evidence. Code-level contract assurance remains within Code Audit, while node or cluster correctness and large-scale RPC resilience remain within Blockchain Security Testing [2].

Best Security Auditor for Web3

Validate design, code, and business logic before launch

Read Audit ReportsRequest an Audit

Conclusion

Blockchain penetration testing retains the traditional application and infrastructure attack surfaces examined in conventional assessments. What distinguishes it is the need to trace weaknesses beyond those entry points through the institution's money-handling chain, where failures in request processing, authorization, software delivery, or infrastructure can affect cryptographic signing, fund state, or on-chain execution.

To make these relationships explicit, this article uses a four-component model: Application prepares business actions, Authorization and Signing produces signatures, Blockchain Interaction submits transactions and interprets outcomes, and Infrastructure supports or influences the other components. Additionally, five attack-surface areas identify where specialist web3 security judgment is most important, particularly at the boundaries between transaction intent, signing authority, fund logic, and on-chain runtime behavior.

Four follow-up guides extend this overview into dedicated analyses of application authorization and signing intent, cloud and CI/CD security, treasury control, and exchange ledger logic. On-chain transactions and deployed contracts remain covered in this overview.

BlockSec helps institutions turn the four-component model and five attack-surface areas into a testable scope by mapping components, owners, fund flows, and trust boundaries, selecting attacker perspectives, defining safe evidence, and validating the potential paths that matter. To scope the attack surface for your next engagement, request a scoping conversation. More information is available upon request.

Also in this series, publishing soon:

  • Part 5: Authorization and Signing Security: Web, dApps, and Mobile
  • Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
  • Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
  • Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic

The Blockchain Penetration Testing pillar page provides the engagement-level view.

References

Numbered in order of first appearance.

  1. BlockSec, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing.
  2. BlockSec, What Is Blockchain Penetration Testing? Definitions and Boundaries.
  3. BlockSec, publishing soon.
  4. BlockSec, publishing soon.
  5. BlockSec, publishing soon.
  6. BlockSec, publishing soon.
Sign up for the latest updates
~$320M Lost: Liquid Network, Symbiosis Exploits | BlockSec
Security Insights

~$320M Lost: Liquid Network, Symbiosis Exploits | BlockSec

This report, covering 2026/09/07 - 2026/09/13, examines two security incidents that caused approximately $320M in losses, including the Liquid Network exploit of 2026/09/06 that the previous report did not cover. The larger was that Liquid Network exploit, where the rangeproof validation cache in Elements derived its key by hashing four fields — two of them variable in length — concatenated with nothing marking the boundaries between them, so a verdict recorded for one output was returned for another whose proof was never examined, letting the attacker create 4,000 unbacked L-BTC and peg out nearly all of them as bitcoin. On the Bitcoin route of the Symbiosis cross-chain bridge, spanning BNB Smart Chain, Ethereum and Rootstock, off-chain code that reads Bitcoin deposits took the depositor's identity from a field the depositor controls and then subtracted its fee from the deposit without checking whether the fee itself was negative, letting a 330-satoshi deposit mint `46,116,860,184.27388234 syBTC`; the pools it had to be sold through held only 11.26 syBTC, so the loss to liquidity providers and users came to an estimated 9.97 BTC (~$770K).

~$9.4M Lost: Injective, Aquifer Exploits | BlockSec Weekly
Security Insights

~$9.4M Lost: Injective, Aquifer Exploits | BlockSec Weekly

During the past week (2026/08/31 - 2026/09/06), four security incidents caused approximately $9.4M in losses across Injective, Solana, Ethereum, and Flow EVM. The largest was the Injective exploit, where an insurance fund identifier collided with a binary options market identifier and the settlement path never compared their denominations, draining about $4.8M; Aquifer on Solana lost about $2.47M because its swap path invoked an unvalidated caller-supplied Token Program, and Notional Finance V1 on Ethereum lost about $1.73M to an unchecked `uint128` cast that valued a debt at zero. Ankr FLOW on Flow EVM closed out the week with about $410K drained through a staking entry point that skipped its pause guard and minted against a stale ratio.

From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing
Security Services

From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing

Exchanges, payment firms, custodians, and wallet providers now lose the most money beyond the smart contract—in signing, custody, keys, people, and supply chains. Code-level audit and transaction-level monitoring each leave a gap, and traditional penetration tests may miss crypto's signing and fund semantics. This article opens our blockchain penetration testing series with the two legs of the case for institutions in scope: where the risk actually comes from, and how NYDFS, DORA, VARA, SFC, and MAS treat adversarial testing across five jurisdictions.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit