Skip to content

Add clarifying comments for potential security review false positives#208

Merged
joshuahannan merged 1 commit intomainfrom
clarify/security-review-false-positives
Apr 3, 2026
Merged

Add clarifying comments for potential security review false positives#208
joshuahannan merged 1 commit intomainfrom
clarify/security-review-false-positives

Conversation

@joshuahannan
Copy link
Copy Markdown
Contributor

@joshuahannan joshuahannan commented Mar 19, 2026

Summary

During a security audit, several code patterns were flagged as potential issues but were determined to be non-bugs. This PR adds inline comments and fixes a bad error message to make the intent and safety of each pattern clear to future reviewers.

Changes

File Change
FlowEVMBridge.cdc Explain why as! force-casts to CrossVMNFT.EVMNFT in handleUpdatedBridgedNFTToEVM are safe — all bridge-defined NFTs are deployed from the bridge's template contract, which unconditionally implements EVMNFT
FlowEVMBridge.cdc Document the routing invariant for handleEVMNativeCrossVMNFTFromEVM — this handler is only reached with a custom cross-VM type, so isCadenceNative is always true, _type is never reassigned, and isLocked/unlockNFT always use the same type
FlowEVMBridgeConfig.cdc Clarify that isTypePaused never actually returns nil despite its Bool? return type, and document the correct call-site idiom
FlowEVMBridgeUtils.cdc Explain that the post-state balance assertions in mustEscrowERC20 are the primary security guarantee and that there is no TOCTOU risk — all EVM calls within a single Cadence transaction execute in the same EVM block
FlowEVMBridgeUtils.cdc Document that overflow in ufix64ToUInt256 is not a practical concern for standard ERC20 decimals (≤18), and explain the bound
FlowEVMBridgeHandlers.cdc Explain that UInt(amount) truncation in the WFLOW handler is caught by the immediately following assert, and cannot trigger given total FLOW supply constraints
FlowEVMBridgeCustomAssociations.cdc Fix a pre-condition error message that force-unwrapped borrowNFTCustomConfig(forType: type) when looking up an already-registered EVM address — the lookup used the wrong key and would itself panic. Replaced with a direct lookup on associationsByEVMAddress

Test plan

  • Existing Cadence tests pass (make cdc-test)
  • No behavioral changes — all modifications are comments or an error message fix in a pre-condition that only fires on invalid input

Addresses items raised during a security audit that were determined to be
non-issues but lacked sufficient inline documentation:

- FlowEVMBridge.cdc: explain why force-casts to CrossVMNFT.EVMNFT in
  handleUpdatedBridgedNFTToEVM are safe (bridge-defined NFTs always
  implement EVMNFT by template contract construction)

- FlowEVMBridge.cdc: document the routing invariant for
  handleEVMNativeCrossVMNFTFromEVM — type is always the custom cross-VM
  type so isCadenceNative is always true and _type is never reassigned,
  meaning isLocked and unlockNFT always use the same type

- FlowEVMBridgeConfig.cdc: clarify that isTypePaused never actually
  returns nil despite its Bool? return type, and explain the correct
  call-site idiom

- FlowEVMBridgeUtils.cdc (mustEscrowERC20): explain that post-state
  balance assertions are the primary security guarantee and that there
  is no TOCTOU risk because all EVM calls in a Cadence transaction
  execute within the same EVM block

- FlowEVMBridgeUtils.cdc (ufix64ToUInt256): document that overflow is
  not a practical concern for standard ERC20 decimals and explain the
  bound

- FlowEVMBridgeHandlers.cdc: explain that UInt(amount) truncation is
  caught by the immediately following assert and cannot trigger in
  practice given total FLOW supply constraints

- FlowEVMBridgeCustomAssociations.cdc: fix pre-condition error message
  that force-unwrapped borrowNFTCustomConfig(forType: type) when looking
  up an already-registered EVM address (wrong key), replacing it with a
  direct lookup on associationsByEVMAddress

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@joshuahannan joshuahannan requested a review from a team as a code owner March 19, 2026 17:10
@github-project-automation github-project-automation bot moved this to 👀 In Review in 🌊 Flow 4D Mar 19, 2026
@joshuahannan joshuahannan requested a review from j1010001 March 19, 2026 17:42
@joshuahannan joshuahannan changed the title Add clarifying comments for security review false positives Add clarifying comments for potential security review false positives Mar 24, 2026
@joshuahannan joshuahannan requested a review from m-Peter March 24, 2026 14:49
Copy link
Copy Markdown
Collaborator

@m-Peter m-Peter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Very descriptive additions.

@joshuahannan joshuahannan merged commit 8a6ae2a into main Apr 3, 2026
2 checks passed
@joshuahannan joshuahannan deleted the clarify/security-review-false-positives branch April 3, 2026 15:03
@github-project-automation github-project-automation bot moved this from 👀 In Review to ✅ Done in 🌊 Flow 4D Apr 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done
Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

2 participants