后端开发的安全自查不是等到上线前才做的事，很多漏洞在编码阶段就已经埋下。与其依赖渗透测试团队事后补救，不如在开发过程中就建立一套可执行的自查清单。下面直接进入正题，从身份认证、接口安全、数据存储、依赖管理、日志审计和配置安全六个维度，把后端开发阶段需要重点核查的问题和具体做法讲清楚。

身份认证与会话管理

认证环节最容易出现的问题不是加密算法不够强，而是逻辑设计存在绕过可能。第一要检查的是密码存储方式，绝对不能使用明文或可逆加密，必须采用bcrypt、argon2或scrypt这类专门设计用于密码哈希的算法。bcrypt的工作因子建议设置为10以上，argon2则需要根据服务器性能调整内存和迭代参数。如果系统里还存有历史用户数据，要确认老密码是否使用了弱哈希算法，比如MD5或SHA1，这类数据需要在下一次用户登录时强制升级哈希。

会话令牌的生成必须使用密码学安全的随机数生成器，不要使用Math.random()或时间戳拼接。令牌在服务端存储时只需要保存其哈希值，防止数据库泄露后攻击者直接使用令牌冒充用户。同时要检查会话是否有明确的过期时间，以及用户修改密码、退出登录后旧的令牌是否全部失效。对于高权限操作，比如修改手机号、绑定邮箱、转账，必须要求二次验证，不能仅凭当前会话就放行。

JWT的使用需要特别谨慎。如果项目采用了JWT，要确认签名算法不是none，密钥长度足够且没有硬编码在代码仓库中。JWT中不要存放敏感信息，因为payload只是base64编码，任何人都可以解码查看。另外JWT一旦签发就无法主动失效，所以过期时间要设置得尽量短，并配合刷新令牌机制来平衡用户体验。

接口访问控制与输入校验

越权漏洞是后端自查的重灾区。很多开发人员只在前端隐藏了按钮，后端接口却没有做权限校验。自查时要逐个接口确认：当前登录用户是否有权限访问这个资源？比如用户A是否可以通过修改URL中的ID参数来查看用户B的订单详情。对于水平越权，需要在查询条件中强制带上当前用户身份标识，而不是完全信任客户端传入的资源ID。对于垂直越权，则需要明确区分普通用户和管理员接口，并在中间件或路由层面统一做角色校验。

输入校验不能只依赖前端。所有来自客户端的数据，包括请求头、Cookie、URL参数、表单字段、JSON body和上传文件，都必须视为不可信。后端要做白名单校验，明确每个字段的类型、长度、格式和取值范围。对于手机号、邮箱、身份证号这类有固定格式的数据，使用正则表达式严格匹配。对于数字类型的参数，要检查是否为负数、是否超出合理范围，比如分页参数page和size要限制最大值，防止攻击者通过超大分页拖垮数据库。

SQL注入的防护原则很明确：使用参数化查询或ORM框架提供的安全方法，禁止字符串拼接SQL。自查时要搜索代码中所有执行原生SQL的地方，确认没有直接拼接用户输入。对于动态排序字段或动态表名这类无法参数化的场景，必须使用白名单映射，从预定义的合法值中选择，绝不能直接使用客户端传入的字符串。

文件上传功能需要单独检查。要限制文件类型，不能只依赖文件扩展名，还要检查文件的MIME类型和文件头魔数。上传的文件要重命名为随机字符串，不要保留原始文件名。文件存储目录要禁止脚本执行权限，如果使用云存储，要设置私有读权限，通过后端接口生成临时访问链接。文件大小必须有限制，防止上传超大文件耗尽磁盘空间。

数据存储与敏感信息保护

数据库层面的安全自查首先要看连接配置。数据库账号是否使用了最小权限原则，应用连接数据库的账号是否只有增删改查权限，而没有DDL权限。数据库端口是否暴露在公网，生产环境的数据库应该只允许应用服务器通过内网访问。连接字符串中是否包含明文密码，这类配置必须通过环境变量或密钥管理服务注入。

敏感数据的存储需要分类处理。身份证号、银行卡号、手机号、家庭住址这类个人信息，在数据库中应该加密存储。加密方式建议使用AES-256-GCM这类带认证的加密算法，密钥通过KMS管理，不要硬编码在代码中。对于需要模糊查询的字段，比如手机号，可以采用确定性加密或单独的哈希索引列来支持查询，同时保证原始数据不可逆。

日志中绝对不能记录敏感信息。要检查代码中所有打印日志的地方，确认不会输出密码、令牌、身份证号、银行卡号、完整的请求体等。很多开发人员在调试时会打印整个请求对象，上线前忘记删除，这会导致敏感数据泄露到日志系统。日志脱敏可以写一个统一的工具函数，在记录前自动对手机号、身份证号等字段进行掩码处理。

数据备份和恢复也需要纳入自查范围。备份文件是否加密存储，备份的访问权限是否受限，恢复流程是否经过演练。很多数据泄露事件不是因为数据库被入侵，而是因为备份文件放在公开可访问的对象存储桶里。

依赖管理与漏洞扫描

现代后端开发几乎离不开第三方库和框架，但依赖引入的安全风险常常被低估。自查的第一步是生成完整的依赖清单，包括直接依赖和传递依赖。使用依赖扫描工具检查是否存在已知漏洞，重点关注那些有远程代码执行、SQL注入、反序列化漏洞的组件。对于扫描出的高危漏洞，要评估是否被当前代码路径实际调用，如果确实存在风险，需要立即升级版本或寻找替代方案。

依赖的版本管理要规范。不要在pom.xml、package.json或requirements.txt中使用模糊版本号，比如latest或通配符，这会导致构建结果不确定，可能引入未经测试的新版本。锁定依赖版本，定期更新并记录变更日志。对于不再维护的库，要制定替换计划，因为这类库即使当前没有已知漏洞，后续也不会再有安全补丁。

反序列化漏洞在Java和Python后端中尤其需要关注。如果代码中有反序列化用户输入的场景，要确认数据来源是否可信。对于不可信数据，禁止使用Java原生序列化、Python的pickle等危险机制。如果必须使用，要采用白名单方式限制可反序列化的类，或者改用JSON、Protobuf这类安全的序列化格式。

日志审计与异常监控

安全日志的目的是在攻击发生后能够追溯攻击路径。自查时要确认关键操作是否都有日志记录，包括登录成功和失败、密码修改、权限变更、敏感数据导出、支付操作、管理员操作等。日志内容要包含用户标识、操作类型、操作时间、来源IP、操作结果和操作对象。日志格式要结构化，方便后续检索和分析。

日志的存储和保护同样重要。日志文件或日志服务的访问权限要严格控制，防止攻击者在入侵后删除日志掩盖痕迹。日志要设置合理的保留期限，既要满足安全审计和合规要求，又要控制存储成本。对于高安全要求的系统，可以考虑将日志实时同步到独立的日志服务器，与业务系统隔离。

异常监控要覆盖安全事件。比如短时间内大量登录失败、同一账号在多个地理位置同时登录、接口请求频率异常、响应体中包含敏感字段等。这些异常模式需要提前定义告警规则，接入监控系统，确保安全事件发生时能够第一时间通知到负责人。

配置安全与部署环境

生产环境的配置错误是导致安全事故的常见原因。自查时要检查所有配置文件，确认没有硬编码的密钥、密码和API令牌。这些敏感配置应该通过环境变量、密钥管理服务或配置中心注入，并且不同的环境使用不同的配置值。开发环境和测试环境的密钥不能用于生产环境。

HTTP安全响应头需要正确设置。包括Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security等。这些响应头可以防止点击劫持、MIME类型嗅探、XSS等攻击。自查时可以用curl命令查看实际返回的响应头，确认配置已经生效，而不是只写在文档里。

跨域配置要严格限制。CORS策略中Access-Control-Allow-Origin不能设置为*，特别是涉及身份认证的接口。要明确列出允许的域名，并且Access-Control-Allow-Credentials为true时，Allow-Origin不能使用通配符。同时要检查预检请求的缓存时间设置，避免过长的缓存导致策略更新不及时。

服务器和中间件的默认配置也需要排查。比如Tomcat、Nginx、Redis、MySQL等组件是否修改了默认密码，是否关闭了不必要的管理端口，是否暴露了版本信息。Redis如果未设置密码且暴露在公网，攻击者可以直接写入计划任务获取服务器权限。Nginx的目录浏览功能要关闭，防止源代码或配置文件被下载。

最后要检查的是错误处理机制。生产环境不能向客户端返回详细的堆栈信息，这会给攻击者提供框架版本、代码路径、数据库结构等敏感信息。全局异常处理器要统一捕获未处理异常，返回通用的错误提示，同时将详细错误记录到服务端日志中。对于404和500错误页面，也不要暴露服务器类型和版本号。

后端安全自查不是一次性的任务，而是需要融入日常开发流程的持续实践。建议将以上检查项整理成checklist，在代码评审时逐项确认，在CI/CD流水线中集成自动化安全扫描，定期对生产环境进行配置核查。安全问题的修复成本随着开发阶段的推进呈指数级增长，编码阶段多花十分钟检查，可能避免上线后数十小时的应急响应。