说明：本文重新整理为上线前检查清单。它不能替代代码审计或授权范围内的安全测试，但可以减少常见的开发疏漏。
Web 安全不能等第三方测试报告出来以后再补。更合适的做法，是在设计、编码、发布和运维各阶段设置检查项，并把安全要求放进日常开发流程。
一、输入验证和数据库访问
- 数据库查询使用参数化语句，不拼接用户输入。
- 输入验证采用允许列表，并同时检查类型、长度、格式和业务含义。
- 表名、排序字段等不能绑定参数的位置，只能从程序预定义的允许值中选择。
- 应用数据库账号按最小权限配置，不使用数据库管理员账号运行普通业务。
用正则表达式拦截“危险关键词”不能替代参数化查询。关键词容易绕过，也可能误伤合法数据。
二、输出编码和浏览器侧安全
- 根据 HTML、属性、URL、JavaScript 等不同上下文做正确的输出编码。
- 避免把未经处理的数据写入
innerHTML，优先使用安全的文本和模板接口。 - 表单和状态变更请求启用 CSRF 防护。
- 设置合理的 Content-Security-Policy 等响应头，作为纵深防御，而不是代替正确编码。
三、身份认证和权限控制
- 登录及登录后的页面全部使用 HTTPS。
- 后台管理和敏感操作启用多因素认证，并在修改密码、邮箱或支付信息前重新验证身份。
- 每个请求都在服务端检查对象权限，不能因为用户知道记录 ID 就允许读取或修改。
- 会话 Cookie 设置
Secure、HttpOnly和合适的SameSite属性，并在登录、提权后更新会话标识。
四、文件、错误信息和配置
- 上传文件同时校验类型、大小和实际内容，重命名后存放在不可直接执行的位置。
- 生产环境关闭调试信息，不向用户显示堆栈、物理路径、SQL 或密钥。
- 密钥和密码不写入代码仓库，使用专门的配置或密钥管理方式。
- 删除测试页面、默认账号、备份文件和不再使用的组件，及时安装安全更新。
五、日志和发布门槛
应记录登录失败、权限拒绝、重要配置变更和敏感操作，但不能把密码、完整令牌等秘密写入日志。正式上线前至少完成依赖组件检查、静态检查、关键接口测试、备份恢复验证和回滚演练。第三方测试发现问题后，还要追溯同类代码，而不是只修复报告中的单个地址。