网站代码安全检查方法不能只靠一次漏洞扫描完成。更可靠的做法是先明确检查范围，再结合源码审计、依赖检查、配置检查和运行时验证，最后对修复结果进行复测。检查结果应能回答三个问题：哪里存在问题、问题可能造成什么影响、修复后是否已经关闭。
先确定检查对象、权限和检查结果
开始前先确认网站是否包含后端服务、前端页面、管理后台、开放接口、文件上传、定时任务和第三方服务。不同对象的检查重点并不相同：前端主要关注敏感信息暴露和接口调用方式，后端重点关注输入处理、身份认证、权限控制及数据访问，依赖和服务器配置则影响整个运行环境。
- 有源码：可以进行静态代码分析、依赖版本检查、密钥扫描和人工审计。
- 只有已部署的网站：以页面、接口、登录流程和错误响应为主要检查对象，不能直接替代源码审计。
- 有测试环境：优先在测试环境验证登录、上传、支付、管理操作等功能，避免影响真实数据。
- 有接口文档：将每个接口的访问身份、参数、返回数据和权限要求登记下来，便于逐项验证。
建议提前建立一张检查记录表，至少包含文件或接口位置、问题描述、影响范围、严重程度、复现条件、修复负责人、修复版本和复测结果。这样可以避免扫描报告堆积后无法判断哪些问题已经处理。
有源码和构建权限时：按“源码、依赖、配置、运行”四层检查
这是最完整的网站代码安全检查方法。不要只运行一个扫描工具，而要把自动检查与人工判断结合起来。
第一步：建立代码和功能清单
先固定本次检查使用的代码分支、提交版本和构建方式，列出登录注册、找回密码、后台管理、文件上传、订单或支付、搜索、导入导出等功能。随后标记所有接收外部输入的位置，例如查询参数、表单、JSON 请求体、请求头、Cookie、上传文件名以及第三方回调。
这一步的结果不是一份漏洞报告，而是一份“入口地图”。后续每个输入点都要能对应到校验、业务处理、数据库操作、模板输出或文件操作，避免只检查首页和几个常用页面。
第二步：进行静态代码检查
静态检查用于寻找代码中可能被外部输入触发的危险路径。可以使用适配语言的静态分析工具，也可以在代码评审中重点查看以下位置：
- 数据库查询是否使用参数化方式，是否存在将用户输入直接拼接进查询语句的逻辑。
- HTML、模板、富文本或邮件内容输出前，是否根据输出场景进行了合适的编码或过滤。
- 文件路径、压缩包解压路径和下载路径是否限制在预期目录内，是否校验文件类型、大小和名称。
- 反序列化、表达式执行、命令调用和脚本执行是否接收了未经严格限制的外部参数。
- 异常处理是否把堆栈、数据库结构、内部路径、令牌或配置内容直接返回给用户。
- 密码、访问令牌、数据库连接信息和第三方密钥是否被写入源码、日志、前端打包文件或测试配置。
静态工具的提示需要人工复核。一个“可能存在注入”的结果，只有在确认输入可以到达危险操作、且中间没有有效校验时，才应判定为真实问题；反之则记录为误报或需要进一步确认，不能机械地全部修改。
第三步：检查第三方依赖和构建产物
网站自身代码没有明显问题，也可能因为框架、插件或组件版本过旧而产生风险。根据项目使用的包管理器运行依赖审计，例如 Node.js 项目可使用 npm audit，Python 项目可使用 pip-audit，PHP 项目可使用 composer audit，其他语言则使用对应的依赖扫描工具。
检查时要区分直接依赖和间接依赖，确认报告中的受影响组件是否真的被构建进当前版本，以及是否存在可用的升级版本。升级前应在测试环境运行登录、上传、支付和接口回归测试；不能为了消除一条报告而盲目升级，导致业务功能失效。
同时检查前端构建目录和发布包，搜索不应公开的调试信息、源映射文件、测试账号、内部接口地址和密钥。前端代码本来就会下发到浏览器，不能把真正的秘密放在变量名混淆或打包压缩之后。
第四步：核对配置与权限边界
检查生产配置是否关闭调试模式，错误页面是否隐藏内部细节，Cookie 是否根据业务需要设置安全属性，跨域规则是否只允许必要来源，管理端和内部接口是否要求身份认证。还要核对不同角色能访问哪些菜单、接口和数据，不能只依据前端按钮是否隐藏来判断权限。
权限检查应从服务端实际响应出发：普通用户访问管理接口时是否被拒绝，一个用户修改另一个用户的资源编号后是否仍能读取或修改数据，已退出登录的会话是否还能继续调用需要认证的接口。权限控制应放在后端业务入口，前端隐藏只能改善操作体验，不能承担真正的授权职责。
第五步：在测试环境进行动态验证
动态检查是在网站实际运行时观察请求和响应。可以使用代理调试工具或网站动态扫描工具，先爬取公开页面，再补充登录后的页面和接口。测试重点包括：
- 登录失败次数、会话失效、退出登录和密码重置流程是否符合预期。
- 修改参数类型、长度、边界值和空值后，服务器是否稳定处理，而不是返回详细错误。
- 上传非预期格式、过大文件或重复文件名时，系统是否拒绝或安全存储。
- 不同角色访问同一资源时，是否同时校验登录身份和资源归属。
- 接口是否暴露不必要的字段，例如密码摘要、内部编号、令牌、调试字段或其他用户数据。
- 高频提交、重复提交和异常顺序操作是否会造成重复创建、越权修改或业务状态错乱。
动态测试应使用专门的测试账号和测试数据，避免发送可能改变真实订单、删除数据或触发外部通知的请求。发现问题后先保存请求条件、响应结果和时间，再在隔离环境中确认影响范围。
只有线上网站或接口访问权限时：从外部行为反推检查重点
如果拿不到源码，网站代码安全检查方法需要调整为黑盒检查。此时可以检查页面、公开资源、登录流程、接口响应、错误处理和权限差异，但无法确认某个内部函数是否安全，也不能把“没有观察到问题”理解为代码完全安全。
- 整理可访问入口：记录主域名下的页面、登录入口、后台入口、接口路径、上传入口和公开下载文件。
- 建立身份矩阵：至少准备未登录、普通用户和管理测试账号，分别记录每个页面和接口的预期权限。
- 比较响应差异：检查未登录、低权限身份和目标资源所属用户访问同一功能时，状态码、返回字段和实际操作结果是否符合设计。
- 检查错误和缓存：使用无效参数、缺失参数和过长参数进行温和验证，观察是否泄露框架版本、路径、SQL 错误或内部服务名称。
- 回到源码层确认：如果发现越权、敏感字段暴露或上传控制异常，应要求开发人员定位服务端代码，而不是只在前端屏蔽入口。
外部检查的有效结果应是“可验证的问题和触发条件”，而不是大量无法复核的扫描告警。对没有授权的站点不要进行高频探测、破坏性测试或真实数据操作。
后端和开放 API 较多时：把权限与数据范围作为主线
如果网站主要由后端服务或开放 API 驱动，检查顺序应从认证和授权开始。先为每类角色列出允许执行的动作，再逐个验证读取、创建、修改和删除是否都经过服务端判断。尤其要检查资源编号、用户编号、订单编号等参数是否只被当作数据查询条件，而没有同时验证资源归属。
接着核对返回数据是否遵循最小化原则。接口不应因为前端暂时不用某字段，就把完整用户资料、内部状态、权限标记或密钥相关信息全部返回。对于批量接口、导出接口和回调接口，还要确认分页、数量上限、签名验证、重复请求处理和状态流转是否明确。
前端页面或内容管理系统较多时：关注公开资源与插件边界
以静态前端、内容管理系统或插件为主的网站，应重点检查构建产物、后台登录、插件版本、上传目录和公开配置。确认后台文件不会被匿名访问，测试账号和演示页面已经移除，上传后的文件不会被当作可执行脚本处理，主题和插件升级不会覆盖自定义的安全配置。
对内容发布功能，还要检查富文本过滤是否覆盖链接、图片、样式和嵌入内容等不同位置；对评论、搜索和站内消息，应分别验证输入保存、页面展示和管理后台展示，而不是只测试一个页面。
修复、复测和输出结论
修复时先处理能够造成未授权访问、敏感数据泄露、远程执行或大范围业务影响的问题，再处理信息暴露、弱配置和低影响问题。每项修复都应回到原始触发条件验证，并增加反向测试：确认合法用户仍能正常完成业务，同时非法身份、异常参数和越权路径被拒绝。
| 记录项目 | 应填写内容 |
|---|---|
| 问题位置 | 文件、函数、接口或页面路径 |
| 触发条件 | 所需身份、参数、操作顺序和环境 |
| 影响说明 | 可能读取、修改、执行或泄露的内容 |
| 处理方式 | 代码修复、依赖升级、配置调整或权限收紧 |
| 复测结果 | 原问题关闭情况及相关回归测试结果 |
最终交付的检查结果应包括检查版本、覆盖范围、使用的检查方式、已确认问题、暂不处理事项及复测结论。将静态扫描、依赖审计和关键接口测试纳入每次发布前流程，才能把网站代码安全检查从一次性排查变成持续可执行的工程动作。
