Web3 Smart Contract Security Auditor Interview Questions

Option B is strongest. It explains the attack with a step-by-step operation order (check → send → update state), making the race condition precise. The DAO context (2016, $60M) anchors the severity. The code example for CEI shows the pattern in actual Solidity syntax — most candidates describe CEI without demonstrating it in code. The three fixes are presented in order of preference with specific implementation details: CEI with code, OpenZeppelin ReentrancyGuard with gas cost (~2200 gas for SSTORE — showing EVM-level awareness), and pull payments with the security rationale. The cross-function reentrancy section is the crucial advanced point: CEI alone does not protect against attacks that span two functions, requiring ReentrancyGuard on all affected functions. Reentrancy vocabulary: Checks-Effects-Interactions (CEI) — the pattern of checking conditions, updating state, then making external calls. Mutex (ReentrancyGuard) — a boolean lock preventing re-entry into protected functions. Fallback / receive function — the Solidity function called when a contract receives ETH. Cross-function reentrancy — a reentrancy attack that exploits two functions sharing state. Pull payments pattern — letting users withdraw funds themselves rather than pushing ETH to them. Options C and D are accurate but lack the code-level CEI example and the cross-function reentrancy nuance.

Option B is strongest. The flash loan definition precisely captures the key property: atomicity — if not repaid, the entire transaction reverts, making them risk-free to offer. The oracle attack mechanism is explained step-by-step (5 steps) with the constant product formula reference (x*y=k) explaining WHY the AMM price moves dramatically from a large swap. The bZx hack is the correct reference (2020, $350K, two transactions) — a real example demonstrating real impact. The three defences are presented with the exact protection mechanism: TWAP uses a 30-minute window, and a flash loan only affects one block (12 seconds), so manipulating the TWAP requires sustained capital across many blocks (quantified economic infeasibility). Chainlink's defence is explained as architectural (off-chain aggregation), not just "use a better oracle." Flash loan vocabulary: Atomic transaction — a transaction where all operations succeed or all revert. AMM (Automated Market Maker) — a smart contract that maintains liquidity using a mathematical formula (x*y=k). Spot price — the current instantaneous price from an AMM based on current pool reserves. TWAP (Time-Weighted Average Price) — an oracle price computed as the average over a time window. bZx — a DeFi lending protocol exploited in the first major flash loan attack in 2020. Options C and D are accurate but lack the step-by-step attack mechanism and the TWAP economic infeasibility explanation.

Option B is strongest. It presents four categories with detection methods for each — the correct audit workflow framing. The missing modifiers section gives specific admin function examples (pause, mint, upgrade, setFee) and names the specific Slither detectors. The unprotected initialisation section uses the Parity Multisig Wallet hack as a real example ($280M frozen in 2017) — one of the most important Ethereum history events for a security auditor to know. The delegatecall section explains the storage slot 0 mechanism precisely (delegatecall runs in the calling contract's storage context, so malicious code can overwrite the owner variable which is typically at slot 0). The tx.origin section explains the phishing path (victim → malicious contract → victim contract) step-by-step. The audit workflow closes with the correct three-phase approach: Slither automated → manual matrix → Echidna fuzzing. Smart contract access control vocabulary: onlyOwner modifier — an access control restriction limiting calls to the contract owner. UUPS (Universal Upgradeable Proxy Standard) — a proxy pattern for upgradeable contracts using an initializer. delegatecall — a low-level call that executes code in the calling contract's storage context. tx.origin — the original transaction signer, as opposed to msg.sender (the immediate caller). Echidna — a smart contract fuzzer for property-based testing. Options C and D name the categories correctly but lack the Parity example and the delegatecall storage slot mechanism.

Option B is strongest. The opening definition distinguishes formal verification from testing precisely: ALL inputs vs. tested inputs only. The two-approach section correctly distinguishes Certora (model checking, complete for specified properties) from Echidna (fuzzing, not complete but practical), with an example CVL property showing what specifications look like. The "when worth the cost" section is the most operationally valuable part: it gives the $100M TVL threshold as a rule of thumb and explains the insurance logic (Certora engagement < $100M potential loss), which is how actual security teams make the ROI calculation. The post-audit hardening use case is a practical scenario many candidates miss. The limitations section is important: formal verification only proves specified properties — it cannot catch oracle manipulation (an economic attack that is formally valid) or business logic that is unspecified. Formal verification vocabulary: Certora Prover — a model checker for smart contracts using Certora Verification Language. CVL (Certora Verification Language) — the specification language for writing properties verified by Certora. Invariant — a property that must always hold true across all contract states. Echidna — a property-based fuzzer for Solidity smart contracts. TVL (Total Value Locked) — the total value of assets deposited in a DeFi protocol, used as a risk proxy. Options C and D are accurate but lack the example CVL property and the ROI insurance framing.

Option B is strongest. The report structure section is specific: commit hash (a detail many candidates omit, but critical because the audit applies to a specific code version), four sections with their contents, and the exact fields in each finding. The PoC requirement is the most important professional standard: "an attacker could..." without code is insufficient — working PoC code in Foundry proves exploitability and justifies Critical/High severity. This is a real standard at top firms (Spearbit, Trail of Bits) that separates professional reports from amateur ones. The severity classification maps to CVSS criteria (impact severity × exploitability), which is the correct framing. The Informational level is often omitted by candidates. The firm names (Trail of Bits, OpenZeppelin, Spearbit) show industry knowledge. Audit report vocabulary: Commit hash — the exact git revision to which the audit findings apply. Proof of Concept (PoC) — working exploit code demonstrating that a finding is genuinely exploitable. CVSS (Common Vulnerability Scoring System) — a framework for classifying vulnerability severity. Scope — the exact set of contracts and files covered by the audit. Informational finding — a code quality or gas optimisation note with no direct security impact. Options C and D are accurate but lack the PoC requirement rationale and the commit hash importance.

Alice's comment focuses on a critical vulnerability: unchecked external calls. This allows an attacker to repeatedly call functions on the contract, potentially exhausting its gas limit or manipulating its state in ways that weren't intended. Input validation is essential for mitigating this risk by verifying data before executing external function calls; reentrancy is a separate concern related to how contracts interact with each other.

Ben's message highlights a key indicator of frontrunning: unusually high gas usage. Frontrunners monitor the mempool for pending transactions and execute their own transaction slightly before the target to gain an advantage (e.g., buying low before a large order executes). Examining timestamps and block explorer data will reveal if this is happening.

While Chainlink VRF provides randomness, it introduces a single point of failure. If the oracle is compromised, attackers could manipulate the random attributes generated for NFTs. Directly using `msg.value` as the minting amount creates an attack vector where an attacker can drain funds by sending large transactions.

Severity classification is a core component of a robust audit report. It's not sufficient to simply label everything 'Critical.' A proper assessment considers the potential impact (financial loss, reputational damage), the likelihood of exploitation, and the criticality of the affected business functions. This allows for prioritization of remediation efforts.

Daniel's comment highlights a critical security weakness: lack of authorization checks. While approving tokens is common, failing to limit the amount approved creates an opportunity for malicious actors to borrow excessive amounts and potentially drain liquidity. The correct answer focuses on the core risk – over-collateralization – which is frequently exploited in smart contract vulnerabilities. Options A, B, and C are all factually incorrect regarding the function's purpose or general security principles.

Sarah is describing a classic flash loan attack. Attackers use flash loans to borrow funds rapidly, manipulate oracle prices, and then repay the loan – all without depositing any collateral. The absence of a fallback mechanism allows this manipulation to be highly effective. Options A, B, and C represent alternative attack vectors or issues that don't align with Sarah's description of exploiting oracle dependencies.

While all options represent potential issues, the primary concern is the reliance on an external oracle (Chainlink). Oracles are susceptible to manipulation and compromise, allowing attackers to influence the election outcome. Using `msg.value` as a direct input source *could* lead to integer overflows but isn't the core vulnerability here; the oracle dependency is far more critical in this scenario. Options B, C, and D represent secondary concerns or incomplete aspects of security.

Given that the potential loss is 10% of total funds held, this vulnerability constitutes a 'Medium' severity. While a single fraudulent claim might be 'Low,' the scale of the risk – affecting a substantial portion of the protocol's assets – warrants a higher classification. 'High' would be reserved for truly existential threats; 'Informational' is entirely inappropriate given the financial implications. The key factor is the *magnitude* of potential loss.

The best mitigation is to utilize a decentralized oracle for block time estimation rather than relying on the potentially manipulatable `block.timestamp`. Decentralized oracles provide an independent and trustworthy source of information, preventing attackers from influencing the outcome by manipulating the timestamp. Options A, B, and C are either insufficient or introduce new vulnerabilities; attempting to randomize the result directly addresses the problem but doesn't eliminate the underlying attack surface.