Lack of Input Validation

Why this rank in 2026

Held mid-list. Severity is high - Cetus lost $223M partly because liquidity parameters were unvalidated - but mature lint rules and clearer audit checklists kept this from climbing higher.

Vulnerable vs secure code

// Vulnerable: protocol fee accepted as raw input with no bounds
function setProtocolFee(uint256 newFee) external onlyOwner {
    protocolFee = newFee;       // can be set above 100% - drains all swap output
}

// Secure: bounded with a documented invariant
uint256 public constant MAX_FEE_BPS = 1000;     // 10%

function setProtocolFee(uint256 newFeeBps) external onlyOwner {
    require(newFeeBps <= MAX_FEE_BPS, "fee too high");
    emit FeeChanged(protocolFeeBps, newFeeBps);
    protocolFeeBps = newFeeBps;
}

Prevention checklist

• Validate all external inputs: function parameters, signed data, cross-chain payloads.
• Enforce tight invariants on fees, rates, limits, and addresses.
• Require non-zero values for any critical parameter.
• Treat admin and governance inputs as untrusted until explicitly verified.
• Add negative test cases (fuzzing, property tests) for every external entry point.
• Use custom errors for clarity and gas savings.

Deep dive: related SCH attack pages

Sources & methodology

Every claim on this page traces back to a primary, citable source. Open the originals if you want to verify the numbers or read the underlying methodology.

Quoted OWASP descriptions are used under CC BY-NC-SA 4.0. SCH editorial content (analysis, code, prevention prose, FAQ, AI-vs-human rates) is © Smart Contract Hacking.