Distributed applications (DApps) are designed to take advantage of the decentralization offered by blockchain systems.  Instead of relying on a traditional web hosting platform – with its associated concerns about centralization and resiliency – DApps host their backend code on the blockchain as smart contracts.

For DApp developers, security can be a significant concern.  Blockchain’s immutable ledger means that a poorly-designed smart contract can be difficult to repair and that any successful attack against a vulnerable contract is irreversible.

However, many DApp developers are not doing enough to ensure the security of their applications.  While a smart contract code audit is an important first step in securing a DApp, it is not enough to guarantee the application’s security.

Smart Contract Audits Are Not Enough for DApp Security

Many DApps are deployed with only a smart contract audit for security (if any security testing is performed at all).  However, this type of security assessment misses a number of potential risks to the security of the DApp.

Infrastructure Considerations

Smart contract security audits are designed to identify common vulnerabilities within the DApp’s smart contract code.  Common things that auditors look for include access control issues, integer overflows and underflows, reentrancy vulnerabilities (for Solidity smart contracts), and similar issues.  These issues often have known patterns that can be easily identified within an application’s code.

However, smart contracts can also contain vulnerabilities that are not visible in the code.  These applications run on top of a distributed ledger platform, which is a very different environment from a traditional computer.  These differences create the potential for attacks at the platform-level that exploit assumptions made within a smart contract.

For example, decentralized finance (DeFi) smart contracts can be vulnerable to frontrunning attacks, where an attacker observes a transaction and creates a competing transaction that is processed first (due to a higher transaction fee or sympathetic miner).  These attacks are possible due to the transaction-based nature of blockchain and enable an attacker to cheat the system and make a guaranteed profit.

Ethereum’s vulnerability to frontrunning was “discovered” in August 2020.  However, similar attacks were performed over three years earlier in the Bancor smart contract.  This vulnerability exists because smart contracts run on Ethereum, not because of an issue in a code.  As a result, a smart contract audit is unlikely to discover this issue even if the potential vulnerability hadn’t been “forgotten” for three years.

Web Application Security

DApps are implemented in two parts, just like any other web application.  The DApp backend is implemented as a smart contract, while the frontend is implemented as a web application that makes calls to the smart contract backend.

Smart contract audits only assess the security of the DApp’s smart contract backend, meaning that they overlook any potential vulnerabilities in the web application code and its connections to the smart contract.  Unless an assessment includes vulnerability testing for the frontend as well, it only covers less than half of the potential attack surface.

Effectively Securing Distributed Applications

Smart contract audits cover only one layer of the blockchain ecosystem and entirely ignore external applications that the contract may interface with.  This means that they are woefully inadequate at assessing the true vulnerability of a DApp to exploitation.

An accurate DApp security assessment requires a comprehensive penetration test as well as a smart contract security audit.  This enables the auditors to identify all potential attack vectors against the DApp, not just the ones that are visible in the DApp’s smart contract backend code.