网站代码安全检查方法：怎么做、检查步骤与结果判断

检查自有或已获授权的网站代码，可按“明确范围、准备代码与测试环境、运行自动化检查、人工复核关键逻辑、修复后复测”的顺序进行。静态扫描能帮助发现常见风险，但不能单独证明网站绝对安全；最终应以问题已定位、修复并通过复测为完成标志。

一、先确定检查范围并准备环境

检查前先明确要覆盖的代码仓库、分支和组件，例如前端、后端接口、管理后台、依赖包及部署配置。若涉及第三方代码或线上系统，应先取得书面授权；不要对不属于自己的站点运行扫描器。

准备代码：在本地或隔离的检查环境中拉取待检查分支，确认代码与依赖锁定文件齐全，例如 package-lock.json、composer.lock 或 requirements.txt。记录分支名和提交号，便于复现结果。
准备测试环境：优先使用测试或预发布环境，并使用虚构账号和测试数据。不要把生产数据库、真实用户资料或有效密钥复制到扫描环境。
确定检查边界：列出主要入口，如登录、注册、支付、搜索、文件上传、管理接口和数据导出；同时确定哪些扫描可能产生写入或高负载，未经确认不要在生产环境执行。

开始前可用 git status --short 检查本地是否有未提交改动。若代码不是当前要交付的版本，先切换到正确分支或保存改动，避免把扫描结论对应到错误代码。

自动化检查应覆盖源代码、凭据和第三方依赖。可在仓库根目录执行适合项目技术栈的工具，并保存工具名称、运行范围和报告；不同工具的规则集与扫描结果可能不同，告警需要进一步确认。

检查源代码：使用静态分析工具扫描当前仓库，例如执行 semgrep scan --config auto .。重点查看报告标出的文件、行号和触发条件，优先处理可能导致注入、越权、敏感信息泄露或不安全反序列化的问题。
检查密钥误提交：可先对当前工作树做简单搜索：git grep -nE 'password|secret|api[_-]?key|token' -- .。逐项判断是否为真实凭据；若发现有效密钥，应立即撤销或轮换，不能只从当前文件删除。此命令主要检查当前代码，历史提交还需使用专门的密钥扫描工具。
检查依赖风险：按项目类型运行依赖审计，例如 Node.js 项目执行 npm audit，PHP Composer 项目执行 composer audit，Python 项目可执行 pip-audit -r requirements.txt。结合锁定文件确认受影响的依赖版本、调用位置和修复版本，再安排升级与兼容性测试。

查看报告时不要只看“发现数量”。应记录每项告警对应的文件和代码路径，区分真实风险、误报与暂时无法确认的问题；报告中涉及密钥或个人数据时，应遮盖敏感值并限制访问。

打开扫描报告指出的文件，再沿调用路径检查输入从哪里进入、经过哪些校验、最终被如何使用。即使自动扫描没有告警，登录、数据查询和文件处理等关键逻辑也应人工检查。

路由、控制器与数据库访问：检查查询语句是否使用参数化接口，避免把用户输入拼接进 SQL；检查每个接口是否同时验证身份和资源权限，不能只因用户已登录就允许访问任意记录。
模板与前端输出：检查用户提交的文本是否经过与输出位置相匹配的转义或安全处理。对 HTML、属性、脚本等不同上下文，不能用同一种简单替换代替上下文编码；富文本功能还要限制允许的标签和属性。
上传与配置：检查上传类型、大小和文件名是否受限制，文件是否存放在不能直接执行脚本的位置；检查配置文件、日志和错误响应是否泄露密码、令牌、内部路径或调试信息。
身份验证与状态变更：在测试环境用普通账号尝试访问仅管理员可用的功能，并检查修改资料、删除记录等操作是否验证权限和请求来源。使用专门测试数据，不对真实用户账户执行操作。

如需做动态扫描，应将目标限定为获授权的测试站点，先采用低影响的被动检查；主动探测只在隔离环境和明确测试范围内进行。验证结果应能说明风险是否实际存在，例如未授权请求被拒绝、输入无法改变数据库查询逻辑、错误响应不包含敏感配置，而不是只记录“扫描器已运行”。