一天一个 vibe coding 小技巧，今天继续讲后端安全。
上一篇《后端安全：接口与系统权限设计》讲的是接口与系统权限设计。
也就是用户请求进来以后，后端怎么判断这个请求该不该处理。
这一篇讲另一条线：配置、框架和数据库。
这条线不像接口那么直观，但对项目安全同样重要。
因为后端的很多风险，不会摆在页面上。
它可能藏在配置文件里，藏在你用的第三方库里，也可能藏在数据库操作里。
页面看着一切正常，问题其实已经埋下了。
所以这一篇盯五件事：密钥不能乱放，日志不能泄露敏感信息，依赖要盯着漏洞及时更新，数据库不能随便查、改、删，最后靠测试和证据验收。
一、配置文件安全：不要把秘密写进代码里
后端安全最先要看的，是配置文件。
很多项目一开始只在本地跑。
AI 为了图方便，会把数据库地址、各种密钥、第三方接口的 token、管理员初始密码，直接写死在代码里。
本地测试时一切正常，看不出问题。
但只要代码被提交、被分享、被部署，这些写死的秘密就跟着暴露了。
别人拿到数据库密码，就能直接连上你的库，把数据导走。
拿到支付密钥，就可能冒用你的身份扣钱。
而这些，你很可能毫不知情。
所以这一步，你要让 AI 专门检查配置文件安全。
可以这样要求：
“请检查当前后端项目是否存在敏感配置写死在代码里的情况。重点检查数据库地址、数据库密码、登录令牌密钥（如 JWT）、第三方接口密钥、管理员初始密码、支付或通知相关密钥。请输出：配置名称、当前所在位置、是否来自环境变量、是否出现在代码或仓库中、是否登记在对应的配置示例文件（如 .env.example，具体按所用框架而定）、是否需要更换。”
你不用搞懂每个配置项是什么意思。
你只要盯住几件事。
第一，真正的密钥，绝不能出现在代码里。
第二，示例配置可以放进一个示例文件，常见的比如 .env.example，但里面只写占位说明，不写真实值。
它的作用是告诉别人“这里该填什么”，而不是把真东西交出去。
第三，代码读配置时，应该从环境变量或框架推荐的方式里取，而不是直接写在代码里。
环境变量，就是把密钥放在代码之外，运行的时候再读进来。
第四，如果 AI 之前已经把真实密钥写进过代码，要让它明确回答：这个密钥还要不要换掉。
这算不上什么高深的安全功能。
但它是后端能不能放心往下迭代的底线。
二、日志安全：别把敏感信息原样记下来
配置不能乱写，日志也不能乱记。
日志，就是后端运行时留下的记录，本来是用来排查问题的。
但很多人只盯着接口能不能跑，没注意到日志里可能混进了敏感信息。
比如密码、token、手机号、身份证号、支付回调内容、第三方密钥，这些都不该原样写进日志。
日志一旦被人看到或泄露，等于又开了一个口子。
记住，日志是为了排查问题，不是把每条请求都原样存下来。
可以这样要求：
“请审查当前后端日志安全。请说明请求日志、错误日志、数据库日志分别记录哪些内容，是否会记录密码、token、密钥、手机号、身份证号、支付信息等敏感数据。如果会记录，请说明如何脱敏或移除。请给出一条正常请求日志和一条错误日志示例。”
你不需要看懂日志系统。
你只要看它有没有说清楚三件事：哪些能记，哪些不能记，敏感内容有没有脱敏。
脱敏，就是把关键信息打码或替换掉，比如手机号只留前三位。
三、依赖安全：你用的框架和 SDK，本身也会爆漏洞
vibe coding 写后端，几乎都会用现成的框架、第三方库和 SDK。
这是好事，不用什么都自己造。
但你要知道一件事：这些别人写的代码，本身也可能藏着安全漏洞。
这类风险有个说法，叫依赖风险。
意思是：漏洞不是你写错了，而是你用的那个库出了问题，结果连累了你的项目。
举个例子，Log4j 是一个被海量后端项目用来记录日志的工具。
几年前它爆出过一个严重漏洞，攻击者甚至能借此直接在你的服务器上运行命令。
当时全世界大量项目连夜升级。
而那些没及时更新、还停在旧版本的，就一直暴露在风险里。
而这种漏洞，光看你自己的代码是看不出来的，因为问题不在你这。
更麻烦的是，AI 帮你写代码时，用的往往是它知道的某个版本。
它不会主动帮你盯：这个库后来有没有爆新漏洞，该不该升级。
你不管，它就一直停在那个旧版本。
所以你要定期让 AI 检查一遍依赖。
可以这样要求：
“请列出当前后端项目用到的所有框架、第三方库和 SDK，以及各自的版本。请逐项说明：有没有已知的安全漏洞或安全公告，当前版本是不是官方建议升级的版本，如果需要升级，会影响哪些现有功能。请重点标出那些负责网络请求、登录认证、加密、文件上传、数据库连接的依赖。”
但升级也不能让 AI 随便来。
你要让它先说清楚：这次升级解决什么问题，会不会影响现在能用的功能。
确认清楚了再升，别为了消掉一个漏洞，把好好的功能改坏了。
四、数据库安全：重要数据不能随便查、随便改、随便删
数据库安全，远不止“能不能连上数据库”这一步。
更要紧的是：谁能查，谁能改，谁能删，哪些操作必须卡着业务规则来。
像锁、索引这些偏性能的概念，你暂时可以不深究。
但有一个东西，你最好早点懂一点，叫事务，它直接决定你的数据会不会变乱，下面会专门讲。
先盯住一个最朴素的问题：重要数据，有没有被随便地查、改、删。
可以这样要求：
“请审查当前后端数据库操作安全。请按数据表或数据模型列出：哪些是重要数据，哪些接口会读取它，哪些接口会修改它，哪些接口会删除它；每个操作是否经过身份校验、权限校验、数据归属校验和业务规则校验；是否存在直接根据前端传入 ID 修改或删除数据的情况；是否有软删除、事务或审计日志要求。”
这里有三个重点。
第一，删除要谨慎。
像用户、订单、支付记录、文章、评论、权限配置这类重要数据，很多时候不该一上来就物理删除。
物理删除，就是真的从数据库里抹掉。
更稳妥的是软删除，只把数据标记成“已删除”，它其实还在，需要时还能找回来。
而且软删除不用你自己操心怎么实现。
很多框架本身就支持，会自动维护一个叫 deleted_at 的时间戳字段，专门记这条数据是什么时候被删的。
这一块，我在之前讲数据库设计的那一期里专门说过，可以结合着一起看。
要注意，软删除之后，这条数据对普通用户就看不见了，但它还躺在数据库里。
如果你有管理后台，可以让 AI 单独做一个管理员接口，把这些已删除的数据查出来、管起来。
第二，多张表一起变动时，必须用事务。
什么是事务？
很多操作不是只动一张表。比如下单，可能同时牵动订单表、库存表、优惠券表、支付记录。
这几步得捆成一个整体：要么全部成功，要么全部不算，不允许只做一半。
这种“全做，或者全不做”的机制，就叫事务。
如果不用事务，AI 一张表改一点，万一中间某一步失败了，就会出现订单建了、库存却没扣，优惠券用了、钱却没收到。
数据就成了一堆对不上的烂账，事后很难查，也很难补。
所以但凡多张表一起变动，尤其是牵扯到钱和库存的操作，一定要让 AI 用事务来保证一致性。
第三，数据库操作，必须和业务规则绑定。
能查到一条数据，不代表当前这个人就有权操作它。
比如用户只能改自己的资料，商家只能看自己的订单，管理员的操作也得有明确的权限入口。
这些规则必须写在后端的业务逻辑里，而不能只靠前端把按钮藏起来。
五、怎么验证：让 AI 从安全角度和业务角度一起测
安全不能只靠 AI 一句“已经处理了”。
每写完一个接口，都要让它自己做一遍安全审计，也做一遍基础测试。
如果这个接口会动数据库，就让它说清楚：是通过接口走完整流程测的，还是直接去改了数据库。
正常业务，尽量通过接口来验证。
因为项目真正上线后，用户也是通过接口访问系统的，不会直接打开数据库操作。
可以这样要求：
“请对本次新增或修改的接口做安全和业务双重验收。请输出：正常请求示例、参数错误示例、未登录示例、无权限示例、访问他人数据示例、数据库写入或修改前后的证据、日志记录证据。请说明哪些测试是通过接口完成，哪些测试是通过数据库检查完成。没有实际验证的项目标记为未验证。”
这里的关键是角色切换。
AI 不能只站在写代码的角度说“我写了校验”。
它还要站在普通用户、没权限的人、管理员、发异常请求的人这些角度去试。
如果它只能证明正常请求跑得通，却证明不了错误请求会被拦住，这个接口就还不算验收完成。
你不用看懂测试代码。
你只看它有没有覆盖这几类情况：正常能用，出错会拦，没权限过不去，数据不会越界，数据库结果对得上，关键过程能在日志里查到。
中间但凡哪段你看不懂，就让它用大白话重讲一遍。
看不懂的验收，等于没验收。
六、最后
这一篇讲的是配置、框架和数据库。
配置里不能写死真实密钥。
日志不能乱记敏感信息。
你用的框架和第三方库本身也会爆漏洞，要定期检查、及时更新。
数据库操作要分清谁能查、谁能改、谁能删，重要数据不能说删就删。
每写完一个接口，都要让 AI 从安全和业务两个角度一起验收。
但也别走到另一头，安全不是无止境地堆复杂代码。
该严的地方必须严，不该复杂的地方，别让 AI 为了显得安全乱加封装。
说到底，后端安全就一句话：不要问 AI “安不安全”，要让它说清楚风险在哪里、规则在哪里、证据在哪里。
