网站代码安全检查方法的核心，不是只运行一次扫描工具，而是按照“确定范围—检查代码—核对依赖与配置—验证接口—复测闭环”的顺序，把可能影响数据、权限和业务流程的问题定位到具体文件、接口和修复动作。检查前应确认网站归属或已获得授权，优先在测试环境执行，避免扫描影响线上服务。

一、先确定检查范围和判断标准

先列出本次检查涉及的域名、前后端项目、管理后台、开放接口、定时任务、上传目录和第三方服务。同步记录使用的语言、框架、数据库、缓存、消息队列及部署方式。范围不清时，扫描结果容易遗漏实际运行的代码，也会把无关目录产生的大量告警混在一起。

然后建立一份基础清单，至少包括以下内容：

• 登录、注册、找回密码、退出登录等身份流程；
• 普通用户、管理员和不同业务角色的权限边界；
• 查询、搜索、导入、上传、导出和批量操作接口；
• 数据库、文件系统、外部网络和第三方 API 的访问位置；
• 生产配置、密钥、证书、日志以及错误页面的处理方式。

检查结果建议分为严重、高、中、低四级，同时记录是否可复现、影响范围、修复负责人和复测状态。这样可以把扫描报告转化为可执行的修复任务，而不是停留在告警数量上。

二、从代码入口开始排查高风险数据流

代码检查应优先从外部输入和敏感操作入手。沿着“输入从哪里来—经过哪些处理—最终影响什么资源”的路径阅读代码，比逐文件浏览更容易发现真实问题。重点查看请求参数、请求头、Cookie、上传文件、Webhook、消息队列内容和环境变量是否经过验证。

1. 检查数据库和命令调用

查询数据库时，应确认参数是否使用预编译语句或框架提供的参数绑定，不要通过字符串拼接生成 SQL。涉及排序字段、表名等无法直接绑定的内容，应使用固定白名单映射。调用系统命令时，优先使用不经过 Shell 的参数接口，并限制命令和参数范围。

2. 检查输出编码和跨站脚本

用户输入被放入 HTML、属性、JavaScript、CSS 或 URL 时，编码方式并不相同。应使用与输出上下文匹配的模板转义，避免用简单替换字符代替完整处理。富文本内容需要经过允许标签和属性的白名单过滤，不能仅依赖前端校验。

3. 检查权限而不只检查登录

登录成功只代表身份已经确认，不代表用户可以访问任意对象。对订单、文件、文章、报表等资源，应在服务端根据当前用户、角色和资源归属重新判断权限。修改、删除、导出和批量操作尤其要检查对象级授权，不能只隐藏前端按钮。

4. 检查文件、网络和反序列化功能

文件上传应限制大小、类型和存储位置，并使用服务端生成的文件名，避免将可执行文件直接放在可访问目录。文件读取功能要限制路径范围，防止通过特殊路径访问系统文件。服务端请求外部地址时，应限制协议、域名、端口和重定向目标。对不可信数据进行反序列化时，应优先使用安全的数据格式和明确的数据结构。

三、用自动化工具补充人工检查

自动化扫描适合发现重复性问题，但不能替代业务权限和流程验证。建议把工具分成四类，并分别处理结果：

静态分析可以使用适配项目语言的 SAST 工具；依赖检查可结合项目包管理器的审计功能；敏感信息检查应覆盖当前文件、Git 历史和 CI 构建目录；动态测试可在授权测试环境中使用代理或 Web 扫描工具。工具名称不是重点，关键是确认扫描版本、项目路径和规则配置正确，并排除测试数据造成的误报。

四、重点验证接口和业务流程

完成代码与依赖扫描后，应针对实际业务执行少量可控验证。为普通用户和管理员分别准备测试账号，比较同一接口在不同身份下的响应；再改变资源编号、分页参数或请求方式，确认服务端没有只依赖前端传值。对新增、修改、删除、导出等操作，还要检查是否存在越权、重复提交和跨站请求伪造问题。

验证输入处理时，可使用无害的边界值，例如超长文本、空值、特殊字符、异常数字和不符合格式的文件，观察系统是否稳定拒绝并返回适当提示。不要在生产系统中提交会改变真实数据的测试内容。对于登录和找回密码流程，应检查失败次数控制、验证码逻辑、令牌有效期、退出后的会话状态以及敏感信息是否出现在 URL 和日志中。

接口响应还应检查是否泄露调试堆栈、内部路径、数据库错误、用户隐私或不必要的字段。错误信息可以帮助开发定位问题，但对外响应应保持必要的抽象，详细信息应写入受控日志，并避免记录密码、完整令牌和身份证明材料。

五、把告警整理成可修复的问题

每条有效问题至少记录以下信息：问题标题、受影响模块、文件或接口位置、触发条件、复现步骤、实际影响、严重程度、建议修复方式和验证标准。相同根因造成的多个告警可以合并，但必须保留所有受影响路径，避免只修复其中一个入口。

优先处理能够绕过权限、执行外部命令、访问敏感数据或影响大量用户的问题。对于依赖漏洞，应结合实际调用路径、运行版本和暴露面判断优先级，不要仅按工具分数机械排序。无法立即修复时，应记录临时控制措施、责任人和计划完成时间。

六、修复后复测并接入开发流程

修复完成后，先验证原来的复现步骤已经失效，再确认正常业务仍能运行，并检查同类代码是否存在相同缺陷。依赖升级后要执行单元测试、接口测试和构建测试；权限问题要使用不同角色重新验证；配置问题要在实际部署环境确认，而不能只看本地文件。

稳定后可将检查纳入开发流程：提交代码时进行敏感信息扫描和基础静态分析，合并代码前检查高严重度规则，发布前扫描依赖和部署配置，定期在测试环境进行接口验证。规则应从已确认的问题中持续补充，误报则通过精确配置或人工复核收敛。

一套完整的网站代码安全检查方法，最终应产出三项结果：已经确认的风险清单、每项问题对应的修复与复测记录，以及能够在后续提交和发布中持续执行的检查规则。这样才能从一次性排查，转变为可重复的网站安全管理流程。