纯 vibe coding 写后端，最让人放松警惕的，往往就是一切看起来都正常的时候：你感觉什么功能都跑通了，而AI也跟你说“没问题，可以上线了”。
可一切看起来正常，去不代表你的项目安全了。
功能跑通，只代表正常流程走完了。
后端安全要看的，是那些不该通过的请求，能不能被挡在外面。
这件事不像前端页面，一眼就能看出哪里乱了，对没有技术背景的人尤其难判断。
一天一个 vibe coding 小技巧，今天讲后端安全里最容易被忽略的一块：接口与系统权限设计。
这一篇会给你 6 段可以直接发给 AI 的话，帮你查清楚几件最要命的事：别人能不能改你的价格、能不能动到不属于自己的数据、密码会不会被轻易破解。
很多人用 vibe coding 写后端，最关心的就是功能能不能跑，功能一通就觉得差不多完成了，根本没意识到后端还有安全这一层。也有人反过来，意识到之后又迟迟不敢上线，总担心 AI 写出来的代码到处是漏洞。
可这两种状态，AI 都帮你下不了判断——它那句“没问题了”，只是一句安抚，给不了你任何验收价值。
你真正要问的不是“安不安全”，而是：风险在哪里，规则在哪里，代码里由谁处理，怎么证明它真的拦住了不该通过的请求。
后端安全可以讲很多内容，这一篇先讲最容易和业务功能混在一起的部分：接口与系统权限设计，也就是用户请求进来以后，后端到底分不分得清这个请求该不该处理。
一、先把安全拆成边界
在这里，你要知道的是：后端安全是分散在请求处理的每一步里的，你可以把它想成请求进来后要过的一道道关卡，每道关卡只负责检查一个方面：
1.身份认证：这个请求是谁发的、有没有登录。
2.权限控制：这个人能不能做这件事。
3.输入校验：前端传进来的数据可不可信。
4.数据归属：这条数据是不是属于他自己。
5.注入防护：用户填的内容会不会被后端当成命令去执行。
这几项里有的后面会专门展开，这里你只要先知道它们是不同的关卡。
这几条防线各自挡的风险不一样，少一条就是一个口子，所以不能用一句“我做了安全处理”打包带过。你要先让 AI 按这些维度，把边界一条条说清楚。
可以这样要求：
“请根据项目架构设计文档和当前业务功能，输出后端安全边界表。不要只说已做安全处理。请按接口输入、登录状态、系统权限设计、密码规则、数据归属、注入风险分别说明：风险是什么，当前在哪里处理，处理规则是什么，如何验证，哪些还没有验证。”
这一步不要求你记住每个术语，但要让 AI 把每条防线落到具体位置：哪些接口必须登录，哪些接口只能管理员访问，哪些数据不能直接相信前端，哪些参数会影响金额、角色、系统权限和数据归属。
如果它回答得太专业、你看不进去，别硬着头皮装懂，直接跟它说“用大白话重讲一遍，别用技术名词”。你看不懂的安全说明，本身就不算合格——这一点贯穿后面每一步，回答看不懂就让它换种说法再讲。
如果这些边界都说不清，后面就不要急着问能不能上线。
二、接口输入默认不可信
接口安全里最重要的一条原则是：默认前端输入不可信。
为什么不可信？
因为后端接口本质上是公开的。真正想钻空子的人，根本不会老老实实从你设计好的页面进来——他们用一些现成的工具，就能绕开整个前端，直接对着后端接口发请求。你在页面上做的格式校验、按钮置灰、字段隐藏，对他们一点用都没有。
所以前端校验主要是为了用户体验以及防止无意义的API请求占用服务器资源。
而真正影响业务结果的内容，必须在后端重新判断一遍。比如价格、数量、角色、用户 ID、订单归属、数据状态，这些都不能因为前端传了，后端就当成事实。
你可以这样要求：
“请审查当前后端接口的输入安全。不要只说已做参数校验。请按接口说明：哪些参数来自前端，哪些参数会影响身份、系统权限、金额、库存、数据归属或数据库写入；每个关键参数在哪里校验；校验失败返回什么；是否有示例请求证明。”
这里你不用看懂全部代码，只看它有没有把关键输入和普通输入分开。
普通输入错了，最多是页面显示不对；关键输入错了，可能就是越权、改错数据、金额错误、库存错误。
所以后端不能只靠前端限制，也不能只靠“参数存在就通过”。
三、密码和管理员账号必须强制约束
安全不只是防别人乱传参数，也包括强制用户遵守基本规则，最典型的就是账号和密码。这里有两层要管。
第一层是密码强度。
攻击者破解密码，靠的不是一个个手动猜，而是拿几百万条常见密码组成字典，让程序批量去试，这叫暴力破解。
如果再用别处泄露的账号密码来碰运气，就叫撞库。abc123、123456 这种密码几秒就会被试出来。
所以注册、登录、修改密码、重置密码、创建管理员账号这些接口，不能允许过弱密码一路通过。
第二层是密码怎么存。
密码绝不能明文写进数据库，必须先经过哈希（一种不可逆的处理）再存，否则数据库一旦泄露，所有人的密码就等于直接公开了。
尤其是管理员账号——管理员密码太弱，影响的不是一个用户，而是整个系统。
可以这样要求：
“请审查当前后端的账号和密码安全规则。请说明注册、登录、修改密码、重置密码、创建管理员账号分别在哪里校验密码强度。请检查是否包含密码长度、字符组合、常见弱密码拦截、密码是否哈希存储（禁止明文保存）、登录失败次数限制、管理员账号额外要求。没有实现的项目标记为未验证，不要默认安全。”
你不用一开始就追求特别复杂的密码策略，但至少要确认三件事：密码规则存在，管理员账号有更严格要求，后端真的会拦截明显弱密码。
四、系统权限设计要提前定
系统权限设计是后端安全里最容易被 AI 写乱的地方。
先分清两件事：一是登录，确认你是谁，这叫认证；二是权限，确认你能做什么，这叫授权。登录通过，不代表什么都能做。
权限出问题通常是两种越权。一种是普通用户调用了本该只有管理员能用的接口，比如改别人角色、删后台数据，这叫垂直越权。另一种更隐蔽：人是登录的、身份也合法，但他动了不属于自己的数据，比如把链接里的订单号一改，就看到了别人的订单，这叫水平越权。
很多 vibe coding 项目只做了“要不要登录”，却漏掉“登录之后能不能动这条数据”，水平越权大多就是这么来的。所以哪些接口必须登录、哪些只有管理员能访问、哪些普通用户只能操作自己的数据，这些不能写到哪算哪。如果项目涉及多角色或多层级权限，比如普通用户、商家、运营、管理员，就应该在立项或功能设计阶段先讲清楚。
否则 AI 写业务代码时，很容易临时猜：这个接口一会儿认为管理员能访问，一会儿又认为登录用户都能访问，最后整个项目的权限规则就乱了。
可以这样要求：
“请根据项目功能设计文档，输出系统权限设计表。每个接口都要说明：是否需要登录、允许哪些角色访问、是否只能操作自己的数据、管理员是否可以访问、权限判断在哪个文件或中间件处理、无权限时返回什么、有没有测试证明。”
这张表不是形式主义，它是给后面继续写业务用的规则。有了这张表，AI 后面新增接口时，才知道应该沿用哪一套系统权限设计，而不是每次重新猜。
五、不要让用户输入直接进入关键语句
还有一类常见风险，叫注入。
它的原理一句话能说清：用户输入的内容，本来只该是“数据”，却被后端当成了“指令”去执行。最典型的是 SQL 注入——如果后端把用户填的内容直接拼接成数据库查询语句，别人就能在输入框里填入一段精心构造的内容，让数据库执行计划外的操作，比如绕过登录、拖走整张用户表。除了数据库，系统命令、HTML、模板拼接也有同类问题。
所以要记住一句话：用户输入的内容，不能被后端直接拼进数据库语句、系统命令、查询条件、HTML 或模板内容里。
正确的防法不是让 AI 自己发明一套过滤规则，而是优先用框架和数据库工具提供的成熟机制：参数化查询（也叫预编译，把“指令”和“数据”分开，让用户输入永远只当数据处理）、ORM、查询构造器、白名单字段校验、内容转义或内容清洗。
可以这样要求：
“请检查当前接口是否存在注入风险。重点检查 SQL 注入、数据库查询注入、命令注入、HTML 或模板内容注入。请说明哪些位置使用了框架 ORM、参数化查询、白名单校验、内容转义或内容清洗；如果存在字符串拼接用户输入的情况，请标记为风险并给出修复方案。”
这里不要让 AI 只说“已经过滤”。你不用搞懂这些机制具体怎么运作，只要让它讲清楚一件事：用的到底是框架、数据库本身自带的成熟方案，还是它自己临时写的一段过滤代码。如果是后者，还拍胸脯说“已经安全”，就要特别警惕——自己造的防护，往往就是漏得最多的。
六、该严的地方严，不该复杂的地方别乱加
安全不是把代码写得越复杂越好。
一听你说“安全”，有些 AI 就会滑向相反的方向：拼命加防御。最典型的一种，是给那些根本不可能发生的情况也写上判断——前面已经强制登录了，后面又反复判断“如果没登录怎么办”；参数类型已经校验过了，再叠一堆永远为真或永远为假的条件分支。
这类分支在实际运行中根本走不到，专业上叫死代码。它不会让系统更安全一分，只会白白增加代码量、消耗资源，还会把真正的业务逻辑淹没，让人误以为“判断这么多，肯定很安全”。
真正要严的，是会影响业务结果的地方：是否登录、是否有权限访问这条数据、是否能修改这条记录、金额和库存是否符合业务规则。这些必须由后端按真实业务逻辑校验。而像输入框提示、格式提醒、前端展示优化这种，就不必上升成复杂的后端安全逻辑。
可以这样要求：
“请审查当前接口安全逻辑是否存在过度防御。请区分：必须校验的业务规则、框架已经处理的基础校验、可以由前端体验层处理的提示校验，以及永远不会触发的防御分支（死代码）。不要为了安全感新增重复判断或不可能成立的条件。任何新增安全封装都必须说明解决什么真实风险。”
这句话的作用，是防止 AI 为了显得安全，堆出一堆没人维护得动、又永远跑不到的判断。
七、最后
这一篇讲的是接口和系统权限设计，重点不是让你吃透每一个安全术语，而是把后端安全拆成能追问的规则。
总结起来就几句话：前端传来的关键数据，后端要重新判断；密码和管理员账号，后端要强制约束；多角色项目，系统权限设计要提前写清楚；用户输入不能直接进入关键语句；该严的地方必须严，不该复杂的地方不要乱加。
说到底，后端安全也不要听 AI 说“已经做了安全处理”，要看它把风险、规则、处理位置和验证证据一项项交出来。
下一篇继续讲后端安全的另一条线：配置、框架和数据库。
