Fansoso
Like.tg
CommunityOnline ServiceOfficial ChannelFraud CheckCurrency Tool
cardking自助刷粉

Advanced Smart Contract Development - Solidity Common Vulnerabilities and Security Development Practices-web3 Series Section 20

Advanced Smart Contract Development - Solidity Common Vulnerabilities and Security Development Practices-web3 Series Section 20
2025-09-0211 Minute
like.tglike.tglike.tglike.tg
www.like.tg

In the world of Web3, smart contracts are like an "automated bank vault."

It can help us automatically enforce rules, but once a loophole occurs, hackers can directly transfer the assets in the vault.

As a developer, I'm often asked:

  • What are the most common security issues with Solidity?
  • Are there any practical development habits that can reduce the risk of contracts being attacked?

In today’s article, I want to talk to you about common vulnerabilities in Solidity contracts, security development practices, and some real cases.

Why is safety so important?

Let me give you two numbers first:

  • according toChainalysis 2024 Report, in 2024 alone, losses due to smart contract vulnerabilities will exceed$3.2 billion.
  • The cross-chain bridge Ronin (the chain behind Axie Infinity) alone was stolen due to loopholes.$600 million.

Compared with traditional software development, smart contracts have two key features:

  1. Immutability——Once a contract is deployed on the chain, it is almost impossible to fix bugs.
  2. Direct custody of high value assets——The contract contains real money, not ordinary data.

Therefore, security is a higher priority than functionality for smart contract development.

Solidity Common Vulnerabilities

Below I have selected the 5 most common and harmful vulnerabilities and dismantled them one by one.

  1. Reentrancy
  • principle: When a contract transfers funds to an external address, if the status is not updated first, it may be "recursively called" by a malicious contract and withdraw assets repeatedly.
  • Case: 2016The DAO attack, because of the reentrancy vulnerability, the loss$60 million.
  1. Integer Overflow/Underflow
  • principle: Early Solidity will automatically "wrap around" when the numerical addition or subtraction exceeds the range. Attackers use this feature to manipulate the number of tokens.
  • Case: In 2018, some ERC20 tokens were attacked, and attackers used overflow to create unlimited tokens.
  1. Improper access control
  • principle: The function was not added correctlyonlyOwnerOr permission verification, anyone can call it.
  • Case: Parity wallet library contract in 2017 becauseinitWalletThere are no restrictions, allowing attackers to obtain administrator privileges and cause losses$150 million.
  1. Timestamp Dependency
  • principle: Used for some contractsblock.timestampTo make random numbers or judgments, miners can artificially manipulate the block time and affect the results.
  • Case: Some gambling contracts are manipulated by miners to draw prizes and make profits.
  1. Random numbers are not safe
  • principle:useblockhash,block.timestampGenerating random numbers is actually not random and is easy to predict.
  • Case: A hacker predicted the results of a certain NFT lottery project in advance and snatched away rare NFTs at a low price.

Secure Development Practices

When I was doing contract development, I summarized some "safety habits" and shared them with you:

  1. Follow Checks-Effects-Interactions

Before calling the external contract, update the status first and then transfer the money to avoid re-entrancy attacks.

function withdraw(uint _amount) public { require(balances[msg.sender] >= _amount, "Insufficient balance"); balances[msg.sender] -= _amount; // ✅ Update the status first payable(msg.sender).transfer(_amount); // Then transfer }

  1. Use safe libraries
  • Using OpenZeppelinSafeMath(Check has been built in since Solidity 0.8).
  • Using OpenZeppelinOwnablePerform permission management.
  1. Don’t write random numbers yourself
  • It is recommended to use trusted oracles such as Chainlink VRF.
  1. Small amount of funds first verification
  • Use a small amount of money to test the contract logic before deployment.
  • It is recommended that key contracts be launched on the testnet first and code audited.
  1. Regular security audits
  • Get an audit from a professional security company (such as CertiK, Trail of Bits).
  • Internal unit testing + simulated attack testing.

Real case sharing

  1. The DAO (2016)
  • Type: Reentrancy attack
  • Loss: $60 million
  • Takeaway: Never transfer money before modifying the status.
  1. Parity Wallet (2017)
  • Type: Access control defect
  • Loss: $150 million
  • Enlightenment: Public functions must be controlled by permissions.
  1. Beanstalk (2022)
  • Type: Governance attack + flash loan
  • Loss: $180 million
  • Implications: Governance mechanisms need to prevent malicious large-amount voting.

Comparison table: common vulnerabilities and defense methods

Vulnerability type

Attack method

Typical cases

defense method

Reentrancy attack

External contract recursive call

The DAO

Checks-Effects-Interactions, using ReentrancyGuard

integer overflow

Addition and subtraction exceed limit wraparound

ERC20 Bug

Use SafeMath or Solidity 0.8+

Improper access control

Unlimited function calls

Parity

onlyOwner, AccessControl

time dependence

Manipulate block time

betting contract

Avoid using timestamp as a logical key condition

Random numbers are not safe

Predict pseudo-random numbers

NFT lottery

Use oracles such as Chainlink VRF

Frequently Asked Questions (FAQ)

Q1: I use the latest Solidity version (0.8+), is it safe?

A1: No. Although 0.8 has built-in overflow checking, other vulnerabilities still exist, such as reentrancy and permission issues.

Q2: Will there be no problems as long as I use the OpenZeppelin library?

A2: OpenZeppelin is a good tool, but security also depends on contract logic. Libraries can help you avoid some low-level errors, but you have to rely on yourself to ensure safety at the design level.

Q3: Do small projects also need to undergo safety audits?

A3: It is recommended to do it. Do at least one third-party audit, or ask the developer community to help review. Hackers will not let you go just because your project is small.

Q4: How to quickly improve Solidity’s security development capabilities?

A4: Read more real attack cases (such as Rekt News Station), write more tests, and run more vulnerability ranges (such as Damn Vulnerable DeFi).

Conclusion

In smart contract development, security is always the first priority.

We all want to write "perfect" code, but the reality is that as long as there is funding, someone will try to attack it.

So, the best way is:Follow best practices + use mature libraries + continue learning security cases + regular audits. In this way, even if absolute safety cannot be guaranteed, risks can be significantly reduced.

I often say:Writing smart contracts is like building an airplane. It must not only fly fast, but also fly stably.I hope this article can help you avoid pitfalls on your way to Solidity.


💼 LIKE.TGThe official overseas marketing tool is now available for free trial!It integrates multiple powerful functions: residential agent IP, fan promotion, number segment screening, customer acquisition system, translator, counter, etc. to efficiently expand overseas markets!

📞 Contact official customer service to obtain trial rights:

🎁 Join【LIKE.TGecological chain】Global resource interconnection community, unlock exclusive benefits, industry tips and real-time support!

Contact Us

Official Rep@LIKETGLi
官方代表
Community@LIKETG group
资源群
Partnerships@LIKETGAngel
资源洽谈
Ads@LIKETGLi
广告合作
Support Hours9:00 AM – 4:00 AM

Currency Toolbox

Failed to fetch exchange rate, please try again later
Line云控拓客平台Telegram云控拓客平台Twitter云控拓客平台叮当助手cardking

Today's Hot