网站代码安全检查应按“确定范围、自动扫描、人工复核、修复问题、回归验证”的顺序进行。先准备测试环境和代码版本，再检查依赖组件、敏感信息、输入输出、登录权限、文件操作及接口逻辑，最后通过复现和重新测试确认问题已经关闭。这样既能发现常见漏洞，也能避免只看扫描报告、却无法判断实际影响。
网站代码安全检查应该从哪里开始？
第一步不是立即运行扫描工具，而是确定检查对象。列出网站前端、后端、管理后台、接口服务、定时任务、上传目录、数据库连接和第三方组件，并记录当前代码分支、部署环境和构建版本。生产环境不适合直接进行可能产生大量请求、写入数据或上传文件的测试，优先复制到隔离的测试环境。
如果检查范围已经确定，就为代码和数据库准备可恢复的版本。保留本次检查的提交编号、配置文件模板和依赖清单。这样发现问题后可以准确定位修改位置，修复后也能用同一版本重新验证，而不是把不同版本的结果混在一起。
先检查依赖组件和项目配置
打开项目的依赖清单，检查运行时、框架、插件和前端包是否存在已知安全更新。重点关注长期未维护、版本过旧、来源不明或被项目间接引入的组件。检查结果应记录组件名称、当前版本、受影响功能、建议升级版本和升级后的兼容性。
随后检查配置文件和部署脚本。搜索数据库密码、接口密钥、云服务令牌、私钥、默认管理员账号、调试开关和测试域名。密钥不应直接写入源码，也不应随前端资源发送给浏览器。发现敏感信息时，应从代码中移除，改用环境变量或安全配置中心，并根据实际情况更换已经暴露的凭据。
检查配置后，启动测试环境确认应用是否仍能正常连接数据库、调用必要服务和完成登录。若程序启动失败，先修正配置注入方式，再继续后面的代码检查，否则扫描结果可能只反映环境故障。
再做自动化代码扫描
自动化扫描适合先覆盖全项目。静态分析应关注危险函数、未过滤的用户输入、拼接 SQL、命令执行、文件路径拼接、反序列化、弱加密和异常信息泄露。依赖扫描关注组件版本和传递依赖，敏感信息扫描关注密钥、令牌、私钥和连接字符串。
扫描报告不能直接等同于漏洞清单。逐条确认报告中的文件、代码行、调用路径和实际输入来源。若输入确实能从请求、表单、接口参数或上传文件到达危险操作，就提升处理优先级；若经过统一校验、参数化查询或固定枚举限制，应记录复核依据，并将误报关闭。
例如，发现代码把请求参数拼接到数据库语句中，应改用参数化查询或安全的查询接口。修改后重新运行同一条扫描规则，并使用测试数据调用相关功能。如果扫描不再报告该位置，接口仍能返回预期数据，且数据库中没有出现异常查询结果，才算完成一轮验证。
发现扫描结果后，怎样检查网站的关键业务代码？
自动扫描覆盖的是代码模式，业务漏洞还需要按照实际功能手动检查。建议从用户能直接操作的入口开始，沿着“请求进入、权限判断、业务处理、数据写入、响应输出”的路径阅读代码。
检查输入验证和输出编码
为每个表单和接口列出参数类型、长度、允许值和是否必填。服务端必须重新验证，不能只依赖浏览器端校验。数字字段应限制为数字和合理范围，枚举字段应只接受预设值，文件名、路径和排序字段应使用白名单。
如果输入会进入 SQL、系统命令、模板、HTML、脚本、文件路径或网络请求，就要检查对应的安全处理方式。数据库使用参数化查询，HTML 输出进行上下文相关编码，文件路径使用固定目录和规范化后的文件名，网络请求限制协议、目标地址和跳转行为。验证动作完成后，再用边界值、空值、超长值和特殊字符测试，确认程序拒绝非法输入或按安全方式处理。
检查登录、会话和权限
先建立至少两个权限不同的测试账号，再逐个访问页面和接口。检查未登录用户能否调用需要登录的功能，普通用户能否访问管理员功能，用户甲能否通过修改编号读取用户乙的数据。每个接口都应在服务端重新判断身份和资源归属，不能只依赖前端隐藏按钮。
检查登录失败次数、密码重置、验证码、会话失效和退出登录逻辑。确认退出后旧会话不能继续访问受保护资源，修改密码后旧会话是否按设计失效。对于涉及支付、账号、权限和数据删除的操作，还应确认是否有二次确认、幂等控制和操作记录。
检查上传、下载和接口边界
上传功能要同时检查文件大小、扩展名、真实类型、保存位置和访问方式。上传文件不应直接放在可执行目录，也不应允许用户控制最终路径。下载功能应限制可访问目录，避免通过路径参数读取配置文件或其他用户文件。
接口检查不能只看返回状态码。分别测试缺少认证、权限不足、参数错误、重复提交和资源不存在的情况，确认响应内容不会泄露堆栈、数据库结构、服务器路径或内部令牌。对于开放接口，还要检查请求频率、分页上限和大请求体，避免单个请求消耗过多资源。
完成初步检查后，怎样确认漏洞真的修好了？
修复时不要只删除报告中的一行代码，而要确认数据流和业务规则已经改变。每个问题至少保留四项记录：原始现象、影响范围、修复提交、验证结果。这样可以区分“已修改”“待验证”和“已关闭”。
复测应先重现原问题，再验证修复后的行为。比如原来未登录请求可以读取数据，修复后使用相同请求访问时，应返回拒绝结果；使用有权限账号访问时，功能仍应正常。若只是扫描规则不再报警，却没有测试真实请求，不能单独作为关闭依据。
完成单点复测后，再做回归检查。重新运行静态扫描、依赖扫描和敏感信息扫描，确认没有新问题；重新测试相关登录、查询、保存、上传和删除流程，确认修复没有绕过权限或破坏正常业务。对共享函数、公共中间件和统一鉴权模块，还要抽查调用它们的其他接口。
用检查记录形成可重复的结果
| 检查项目 | 执行动作 | 合格结果 |
|---|---|---|
| 依赖组件 | 读取依赖清单并核对版本 | 高风险组件已升级、替换或有明确处置记录 |
| 敏感信息 | 扫描源码、配置和提交记录 | 源码无可用密钥，暴露凭据已更换 |
| 输入处理 | 测试边界值和特殊字符 | 非法输入被拒绝，合法请求仍可完成 |
| 权限控制 | 使用不同账号访问同一资源 | 服务端按身份和资源归属拦截越权请求 |
| 文件功能 | 测试上传、下载和路径参数 | 文件类型、目录和访问范围均受限制 |
| 修复验证 | 重现原请求并执行回归测试 | 原问题无法复现，相关业务没有异常 |
最终报告应包含检查时间、代码版本、环境范围、使用的扫描规则、已确认问题、误报依据、修复状态和复测结论。对于暂时不能修复的问题，写明影响功能、临时限制、责任人和下次复查时间。以后每次发布新版本，都可以按照这份记录重复检查，让网站代码安全检查从一次性排查变成持续的开发流程。
