我是个写代码的，不是什么安全专家。
曾经写过好几份合约，之后遭遇他人抹黑，在这种情况下，我不得不从最开始去学习如何审视自己所撰写的犹如堆积如山且较差的内容。
这篇文章，并非是那种教科书，又不是什么官方指南，它只是一个曾经踩过坑的人，所记录下来的34条血泪教训，是用于自己使用的，并且顺便也给你看一看。
先问你一个问题，你给你的合约做过审计吗？
钱不多那种?
花不起几万刀的审计费？我讲给你听，在2026年1月到3月这段时间，Web3因安全问题而损失的金额已然超过4亿美元了。
然而，在那些有着曾被黑客攻击情况的项目当中，有不少并非是压根就没有执行审计工作，反而是在实施了审计流程之后，上线运行依旧遭遇被黑客攻击的状况。就拿Port3那个项目来说，待审计结束并上线后的次日，仅仅是一个关于签名校验方面出现的微小差错，致使几百万资金就这样消失不见。
的确，你手上持有的那份审计报告，兴许仅仅是一张“参与考试得以通过的合格证”。
可惜现在整个行业的安全考试，及格线大概率等于0分。
重入攻击的变种
重入攻击这件事，大家都清楚知晓，对于–，熟悉背诵的程度，比乘法口诀还要熟练，是这样的情况。
但2026年的重入早就不一样了。
让我们来撰写一个简易的示例瞧一瞧，一个外观看上去较为正规的函数情况下来讲吧，要是在check这项以及这个环节之间插入了一个外部调用的话，并且还没有添加修饰符的话呢…就等着被全部提捞一空了吧。
A去调用 B，然后， B再去回调 A这种大模式，如今是很流行的。
审计当中呢，得对这个加以密切注视，特别是针对那些跨合约相互进行调用的部分，一旦稍有疏忽，便会读取到已然过时的状态。
更有甚者，存在这般情况，有人察觉到，某些合约于view函数之中发起重入调用，此乃近期方才被大规模曝光的手段。
你并未看错，view确实能够发起攻击，鉴于view函数从理论层面来讲不应当改变状态，因而众多合约针对它未进行防护，攻击者借此钻了这个空子。
核查自身代码里头，在所有外部调用的各个地方，不论其是还是，都去问这么一句：倘若它出现回调的情况该如何应对呢？
整数的坑
给你呈现一个示例， 0.6.10的过去代码，未曾进行算术安全检查，攻击者传入一极大数字，致v12加v9径直溢出至一较小值，最终计算公式分母增大，分子归为零，得以无偿获取。
于是，在2026年1月8日， 遭到一笔攻击，直接被人白白拿走了2644万美元。
仅仅是一个整数出现了溢出的情况，你认为这样的漏洞具备高级的特质吗？并非如此，它低级到足以令我内心破碎，产生极度的哀伤。
关键之处在于，那些看上去正常到了极点的加法、乘法，特别是在涉及到代币买卖时，价格的函数当中的计算。
此刻倘若运用 0.8+，那么其中默认是自身携带着溢出检查功能的。然而需要叮嘱留意的是，处于{}块里所进行的运算操作是不会予以检查的。
还有，要是你是从旧的代码转移过来的呀，外面调用的运算有没有进行检查呢？反编译得出的代码当中，旧版本的真的全都有了吗？
那次出现的漏洞，属于那种典型的，“计算本身不存在问题”，然而“计算得出的结果却超出了所规定范围”的灾难性情况。那么在你开展审计工作的时候，首先要做的那件事情是什么呢？那就是仔细地数清楚，究竟一共有多少个与算术相关联的函数，接着要对每一个函数，在面对极端输入情形时的表现进行验证。
权限的玄学
你可晓得噢，OWASP二零二六版本的智能合约漏洞排行榜里头，位居首位的并非重入情况，并非溢出状况，却是——访问控制漏洞呢。
这破事连续两年排第一了。
难道不是在讲，我们每一天都处于担忧各类花俏杂乱的高级攻击之境，然而，最大的风险竟然是我把给某个函数添加 这件事儿给忘掉了这般糟糕的情况。我自己曾经就犯了这样的错误，这和智商不存在关联关系，完全是脑子突然之间短路了。
认真细致地去检查每一条函数，再去检查每一条函数，然后向自己发问：究竟是谁切实真正应该能够去调用这个呢？
具有敏感性的操作借助进行拦截了吗，权限初始化函数是否会被重复调用两次呢？
又存在着一种全新的情形，不少具备多角色、多层权限的系统日益增多起来，角色的界限常常出现错乱状况。举例而言，唯有管理员才能够暂停合约，然而对于某个冷门的操作员地址，你赋予了其修改关键参数的权力。实际上这就等同于所有人均可绕过管理员了。
跨链桥的悖论
现在基本上是个大点的项目都有桥接逻辑。
在2025年之际，Poly 出现状况之时，10条公链之上的那些资产忽地一同遭受威胁，之后呢人家实施了回滚，然而话说回来倘若你具备着能够回滚的这般情形存在的时地条件，这般状态下这还能不能够称为是区块链范畴所指呢？
审计跨链桥时，难点究竟处于何处？链外所存在的验证节点，其安全性究竟如何？伪造而成的 proof，是否能够借此钻空子？原生资产以及映射资产的处理，是否正确无误？
并且，桥的出入口常常是调用外部合约的大户，一旦外部依赖出现问题，整个桥就好似被人从中间猛踹了一脚。
审计桥的时候需要大量的环境模拟攻击，而且速度要比黑客的快。
此外还需提醒一下，CVE编号的合约漏洞如今已然是能够公开去查询的了，就好比CVE – 2026 – 39987这个漏洞，其是允许远程代码执行的。故而你在进行审计之时，不但要留意自身的代码，对于外围所依赖的库以及框架同样是需要查看一番的。
依赖与版本
有一个道理挺简单的，你可千万不要打开自身的合约文件，结果却发现进行操作的全都是那种早就不再维护的库。
更为危险的是，存在这样一种情况，即同一个协议的依赖库版本产生了冲突，进而致使原本具备安全修复的版本被老旧版本给覆盖掉了。
我存在着一种属于自身的习惯，对每一个相关依赖库的源头进行自行且妥善治理。较理想的状况之下是将其创立副本并转移至自身项目范畴内存储借此躲避后续若出现他人删除此库的不利情形所生成的那些不良影响。在实施检查操作期间，务必严格验证在给定链条之上所进行部署的字节码以及在本地经由编译过程所产出的字节码二者处于完全等同的状态。
讲些更刺痛人心的情况，诸多大型项目被抹黑得那般严重，真不是审计报告中未表述清晰，而是项目方自身尚未完成修复便仓促上线了。
你存有审计付费过后的修复复核情形吗，你的最终部署版本当时所用的是审计之际那个提交记录吗，在版本与链上版本二者之间有过任何虽小却未重新审计的改动情况吗？
在2025 – 2026年所涉及的大案子当中，所有这些均为资金流失的隐患所在，其中涵盖Bybit、这些案子，它们的共通之处在于，审计获得了通过，不存在任何一个漏洞是源于代码层面的bug。
换句话而言，代码之中不存在漏洞，那么漏洞究竟处于何处呢？其处于业务逻辑自身的设计方面。
依照你所提供的白皮书来阐述的流程，与你在代码方面的实现，二者是否保持着一致呢？你所创作得代码，其内在逻辑是否能够将所有用户交互路径都涵盖在内呢？
有那种，单个的函数，单独去看的时候，没有问题，然而，当把它们组合起来，进行一次调用的时候，就会出现故障的例子，数量多得数不过来。
这就是复合逻辑漏洞，审计中最难被发现的杀人凶手。
是否存在恶意放大交易手续费的情况，在某些极端组合时提币条件有无被跳过的可能性，允许管理员无限增发的逻辑方面有没有对外部条件进行检查？
同样需要注意的是，绝对不要迷信自动化审计这种工具。、等这类静态分析工具，对于重入、算术溢出这类呈现模式化的漏洞，能够找得极为精准，并且要是配合去搞一搞，也能够发现一些边界条件。
然尔，却指望工具掌握你的业务逻辑，根本不可能。工具所能覆盖的量，大概是占实际高危漏洞的15%至20%罢了，其余的部分，仍旧得依靠人眼逐字逐行仔细地盯着查看才行。
如此一来，我的想法便是，先是去运行跟迅速走马观花一番清扫清扫表面，找出一些能明显察觉到的方面的失误残留的要点被放置于人工核查校验之上，将合约之中全部的外部以及公共函数都抄写下来，跟随追寻每个函数的调用线路途径，瞧瞧是不是存在有所遗漏的前置前提条件。
说两个容易被忽略的小细节：
有种情况是，没有对的签名有效性展开检查，进而导致签名无效，最终返回地址0，然而，在相关逻辑当中，尚未对地址0这种情形加以判断，如此一来，便使得攻击者有机可乘，钻到了空子，出现了问题。
一个瞬态存储的残留没清理，给了攻击者逆向提取资金的机会。
合约初始化失败，此合约乃为代理合约，然而却未出现任何情况，致使某些函数处于未初始化状态，这些函数能够被任何人调用。
其实没有终点
写智能合约累，审计更累。
然而，这可是一条单行道，合约一旦被上传到链上，即便察觉到存在问题了，也仅仅只能寄希望于没有其他人来针对你。
给你三个建议，也是我自己的铁律：
第一条，在踏入主网阶段之前，不但需要经历一轮审计流程，而且还得自行逐一核查上文所提及的全部检查要点。商业范畴的审计倘若暴露出重大问题，那可就已然触及最后的底线了。
第二条审计报告之中，所有的Tip以及中等风险项目，起码需要过一遍人工，高危漏洞无人敢放，然而中低危常常是组合攻击的垫脚石，切莫不当回事。
第三条，上线后持续监控，链上异常流量的分析不能停。
希望你这辈子永远不需要用到我的这些内容。
因为用到它意味着你的钱可能正在被转走。
但要是你身为一个比较严谨认真的开发者，我仍旧是建议你把合约源码开启，再度连贯地读取一遍。
并且问自己：
如果我是一个黑客，我会怎么把这个合约搞瘫？
你笑不出来就想哭。
