Smart Contract Security Testing Guide (SCSTG) is a risk-based guide for smart contract security professionals and developers to use as a reference in the security testing of smart contracts. It describes the characteristics and processes for verifying smart contract security issues in different categories, together with examples of vulnerable contracts or functions, and solutions to resolving the risks from their root causes or mitigating their risks.
The risks are categorized into 9 categories. Each page includes the description of the risks, examples, and solution or mitigations for those risks.
The risks are categorized in 9 categories as follows:
- 1. Architecture and Design - Implementing smart contracts to be secure requires proper architecture and design. This testing category involves the use of compilers, the design of the smart contract calling architecture, and the design of roles and permissions.
- 2. Access Control - Access control is the imposing of policy by preventing users from acting beyond the scope of their authorized permissions. Improper access control can lead to unauthorized information disclosure, data manipulation or loss, or performing of business functions outside the user's capability.
- 3. Error Handling and Logging - Error handling and logging are the keys in making errors in smart contracts traceable, directing the execution flow to the proper path depending on the execution result, allowing the users to know where and how the contract fails, and making it possible to trance the past actions done on the smart contract.
- 4. Business Logic - Business logic flow in general should be sequential, processed in order, and cannot be bypassed. Business logic vulnerabilities can happen when the smart contract's legitimate processing flow can be used in a way that has an adverse effect on the users or the smart contract's owner.
- 5. Blockchain Data - The usage of data on the blockchain, including the storage, retrieval, and modification, should be done properly to keep the integrity, and sometimes confidentiality, of the data.
- 6. External Components - Smart contracts can be interconnected through the inheritance of the previously developed smart contracts or the calling of functions from other contracts. Usage of insecure external components can cause undesirable or harmful effects if not done properly.
- 7. Arithmetic - Mathematical operations on different programming languages and platforms may work differently. The arithmetic operations done in the smart contract should be able to safely handle the whole range of possible values.
- 8. Denial of Services - Improper contract logic can affect the availability of the contract. It should be made sure that the smart contract can function properly as designed without disruption from internal or external factors.
- 9. Best Practices - Smart contract can be implemented in various ways, depending on each developer’s style. However, complying with the best practices can improve the code quality of the smart contract, making it cleaner, more readable, or more efficient.
The following people have contributed to the creation of this document:
- ErbaZZ (Weerawat Pawanawiwat - weerawat.p@inspex.co)
- Rugsurely (Patipon Suwanbol - patipon.s@inspex.co)
- DeStinE21 (Natsasit Jirathammanuwat - natsasit.j@inspex.co)
- Jusmistic (Puttimet Thammasaeng - puttimet.t@inspex.co)
- x0r4w (Sorawish Laovakul - sorawish.l@inspex.co)
- ICQCQ (Darunphop Pengkumta - darunphop.p@inspex.co)
- jokopoppo (Wachirawit Kanpanluk - wachirawit.k@inspex.co)
We would like to thank the authors of the these amazing resources that were used in the creation of this document:
- Ethereum Smart Contract Security Best Practices
- Smart Contract Weakness Classification and Test Cases
- Solidity Patterns
- OpenZeppelin Contracts
- Solidity Documentation
- Solidity by Example
- Slither, the Solidity source analyzer
- Smart Contract Security Verification Standard
This document is for educational purposes. The smart contract source code in this document contains vulnerabilities, and does not guarantee the safety of the smart contract when used.
DO NOT USE any of the source code in this document on production.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.