Security

Audit checklist

0xjarix

• 3 min read
Audit checklist
  • understanding the project as a whole (docs + code)
  • doc/code discrepancy (compare them carefully)
  • read previous reports (devs commit the same vulnerabilities even though it’s a different codebase, learnt it the hard way when decided against participating in midas second contest:
    https://github.com/sherlock-audit/2024-08-midas-minter-redeemer-judging/issues and https://github.com/sherlock-audit/2024-05-midas-judging/issues)
  • read the deployment scripts and tests to better understand control flow of certain functionalities
  • bad logic implementation
  • rounding directions (always in favor of the protocol)
  • unsafe cast especially with nested parenthesis could revert due to over/underflow
  • self-transfers(from != to)
  • reentrancies and CEI
  • oracle price manipulation attack
  • flash loan attack
  • delegatecall issues check solodit
  • vault inflation attack / first depositor
  • lack of slippage tolerance on swaps and dynamic pricing
  • DoS attack
  • funds locked
  • gas grieffing 63/64 rule, especially in functions containing try catches
  • check carefully try catches some may not revert when intended
  • lack of low-level calls check
  • signature malleability
  • signature replay attack
  • check pause/unpause wrappers exist
  • the 5 upgradeability issue for proxy patterns (giraffe tweet bookmarked)
  • check previous audits and make sure the issues were fixed
  • price assumptions such as (stETH = WETH) are wrong
  • sequencer down
  • make sure the opcodes are supported in the layer 2
  • stale price (chainlink price feed)
  • check out-of-gas scenarios especially when the gas used to call a function exceeds the block limit of a certain chain
  • Admin can add or remove any address as CCIP counterpart for his personal benefit
  • admin grants himself a role that is supposed to be occupied by a contract
  • check access controls on external and public functions
  • check the assembly
  • maliciously passing wrong CCIP inputs
  • Insufficient Gas Limit Specification for Cross-Chain Transfers
  • check for or equal signs ( why > and not >=, what if it was >= instead, there could be some edge cases there)
  • confusions between i and j indices inside nested loops
  • incorrect contract call (function might not exist) and call ends up reverting or calling a fallback if present, watch out for inherited contracts’ functions
  • incompatibility with fee-on-transfer and rebasing tokens
  • check the decimals (should be 6 for usdc for example)
  • chainlink check if the roundId falls in the current epoch
  • abi.encodePacked hash collisions
  • ERC compliance
  • approval front-running
  • calculation mismatch
  • can users renounceRole() if they are blacklisted for example
  • weak random number generation 
  • bypass limit due to broken invariant
  • centralization risks
  • use block.timestamp insted of block.number for certain L2s such as optimism and arbitrum
  • domain separator
  • data exposure (secrets should be hashed, priv is not enough)
  • check if loan is collateralized
  • check if loan is payed back WITH the fees
  • check the voting power in DAOs is updated proparly
  • check dust amounts in particular dust amount can be sent by attacker to front-run loan repay
  • beware of migrations
  • sandwich attack
  • make sure functions and especially sub-called functions (very often for cross-chain transfers )are payable if intended to receive eth
  • locked NFT in case onReceiveERC721 or such is not implemented
  • watch out for tokens that have a blacklisting mechanism like USDC(if usdc was a country it would be using inches and feets for sure)
  • missing logic and missing checks for these, before even reading the function, try implementing it just from reading the name of the function
  • make sure they provide a refund mechanism if msg.value and expected amount are not sync, it’s pretty much input validation since user will have to send a bigger amount of ETH by mistake, used to be a med, I think it’s a low nowadays
  • check if lack of withdraw pattern causes an issue
  • check if they’re using latestAnswer instead of latestRoundData
  • check if they're using SafeERC20 especially for tokens that do not revert on failed transfers, some just return true or false that you have to handle in your code like for USDT
  • check functions don't break REGARDLESS OF THE NETWORK, if the project is intended to be deployed on several networks
  • keep an eye for unused parameters
  • Merkle trees' Second preimage attack
  • state variables that are supposed to be updated together are not
  • check nested for's indices are not mixed up