企业官网建设流程全解析

前言

V1.0 基线版本业务流程可以跑通，但底层安全机制存在明显短板：云函数信任前端传入的身份参数，缺少真正独立的会话管理；RBAC 权限只是表层 UI 控制，后端缺少强制拦截；密码、日志、文件上传、数据脱敏多处存在安全隐患。 V1.0.1 迭代的 P0 最高优先级工作就是整套安全体系重构。本篇聚焦云开发 B 端项目的安全实战，全部来自项目真实安全审查与整改记录，不涉及业务 UI、财务流程 Bug（财务业务已经在 4‑7 篇完成复盘）。 对于云开发 B 端系统，很多开发者把权限控制只做在前端页面，认为 “菜单隐藏就是权限控制”；而真实安全防护需要做到前端 UI 拦截、云函数接口鉴权、数据库行级过滤的三重 RBAC 防护。本篇会还原旧版本安全缺陷、现象、根因、整改方案，同时沉淀云开发 B 端后台可复用的安全编码规范。

案例 1：旧鉴权缺陷 — 云函数信任前端传入角色参数，可抓包伪造身份越权

踩坑前认知误区：前端页面已经做了菜单、按钮权限控制；云函数直接读取前端上传callerRole、callerUserId、callerDesignerId就可以完成身份校验。

业务场景：PC 后台、小程序管理后台调用管理类云函数。

现象复现登录一个低权限账号（运营 / 设计师），抓包修改请求体里面的callerRole伪造为超级管理员；重新发送请求，云函数直接采信前端传的角色身份，实现越权执行高权限操作：新增角色、重置别人密码、读取全部财务数据。

原有代码虽然写了enforceAdminRBAC鉴权函数，但是鉴权逻辑依旧来源于前端传入参数，属于软防护，可以被绕过。

根因分析

1. 没有独立的会话存储集合，身份完全依赖前端请求携带的字段；
2. 云函数没有从后端会话集合解析真实登录身份；
3. 混淆「前端展示用身份」和「鉴权用真实身份」，前端任何入参都不可信。

整改方案

1. 新增custom_sessions会话集合；用户登录成功，后端生成32‑64 位随机十六进制 token，写入会话表，记录 accountId、role、designerId、permissions、expireAt 过期时间、revoked 作废标记；
2. 所有管理云函数，只信任请求携带的token；全部通过parseAdminSession从数据库会话表解析真实登录身份；完全丢弃、不采信前端上传的 callerRole /callerUserId/callerDesignerId；前端携带的这些字段仅用于页面渲染展示，不参与任何鉴权判断；
3. 重构enforceAdminRBAC公共鉴权中间件，每一个 custom_admin_* 云函数入口第一行调用该方法，完成 token 校验、身份解析、权限码校验；
4. 会话有效期固定 24 小时；登出、改密码、账号禁用时，批量 revoke 作废该账号全部历史 token，旧 token 直接失效。

开发落地规范

云开发 B 端后台铁律：所有后台鉴权身份，必须由后端数据库会话解析获得，永远不采信前端请求传入的身份字段。前端任何参数都可以抓包篡改，不能作为安全依据。

案例 2：权限模块存在提权漏洞，普通账号可以创建 / 修改超级管理员角色

踩坑前认知误区：只要页面隐藏角色编辑入口，普通账号就无法操作角色权限。

业务场景：权限管理云函数custom_admin_perms_main负责角色、后台账号的增删改查。

现象复现低权限账号抓包直接调用角色新增接口，可以创建超级管理员角色；也可以把自己账号的角色修改为超级管理员，完成权限提权。

根因分析角色、账号编辑接口内部，没有校验操作者自身的角色身份；没有增加 “禁止提升自身权限” 的防护逻辑。

整改方案

1. 在角色新增、编辑、删除、账号重置密码接口，增加强校验：只有超级管理员才允许执行这类操作；
2. 增加规则：操作者不允许把自己账号权限提升到比当前更高等级；不允许删除 / 降级超级管理员角色；
3. 权限变更的每一次操作，后端自动写入审计日志，记录操作人、变更前后内容。

开发落地规范高危权限管理接口，除了 RBAC 权限码校验，额外增加业务硬编码防护，防止权限码配置失误造成提权风险。

案例 3：登录密码校验兼容明文比对，账号密码存在泄露风险；缺少登录暴力破解防护

踩坑前认知误区：只要前端密码加密再传给后端，数据库存密文就足够安全。

业务场景：后台账号登录、密码校验逻辑。

现象复现数据库内如果残留历史明文密码记录，旧版校验逻辑支持明文直接比对登录；没有登录失败锁定，攻击者可以无限次暴力猜密码。

根因分析

1. verifyPassword函数保留明文密码比对分支；
2. 没有密码错误计数、账号锁定机制。

整改方案

1. 删除明文密码直接比对分支；统一使用加盐哈希方式校验密码；
2. 提供迁移脚本，批量把历史明文密码升级为哈希存储；登录时如果检测到历史明文密码，登录成功的同时自动升级为哈希；
3. 新增custom_login_attempts登录尝试记录表；密码连续输错 5 次，账号锁定 15 分钟，锁定期间无论密码对错均拒绝登录；
4. 每一次登录（成功 / 失败）写入登录日志，记录 ip、时间、结果。

开发落地规范禁止数据库存储明文密码；后台账号必须具备暴力破解防护；登录行为全部留日志。

案例 4：操作日志接口对外开放，可由前端伪造审计记录，日志失去溯源能力

踩坑前认知误区：提供一个日志写入云函数，前端页面发生操作就调用接口写日志，就可以完成审计留痕。

业务场景：系统操作审计日志，记录退款、改权限、订单重大变更。

现象复现前端可以直接调用日志新增云函数，自己伪造 operatorId、operatorName、操作内容，写入虚假操作记录；出现故障的时候，日志无法作为真实溯源凭证。

根因分析把写日志的能力开放给前端，操作人、操作内容由前端传入。

整改方案

1. 删除对外开放的日志写入云函数；所有操作日志，只能在各个业务云函数的内部代码中生成；
2. 操作人账号、角色全部从已经解析完成的 session 会话对象获取，完全不接收前端传入 operator 相关字段；
3. 日志集合设置权限约束，业务系统只允许新增记录，禁止更新、删除历史日志，历史审计记录不可篡改。

开发落地规范审计日志属于安全溯源数据，写日志逻辑必须放在后端业务内部，绝对不能开放给前端调用。

案例 5：短信验证码接口无限流，验证码明文返回接口响应，存在短信轰炸、泄露风险

踩坑前认知误区：前端按钮做倒计时，就可以防止短时间重复发送验证码。

业务场景：后台找回密码、短信验证接口。

现象复现抓包绕过前端倒计时，高频调用短信发送接口实现短信轰炸；接口响应体内直接返回验证码明文，抓包即可拿到验证码。

根因分析限流逻辑只做在前端；验证码明文返回给客户端。

整改方案

1. 后端增加限流规则：同一个手机号 60 秒最多发送 1 条，单日最多 10 条；结合 openid 二次限制；
2. 验证码只保存在数据库，接口返回仅提示 “发送成功”，响应体绝不返回验证码原文；
3. 验证码设置 5 分钟有效期；校验的时候同时比对手机号、验证码、过期时间三重条件。

开发落地规范所有限流逻辑必须后端实现，前端倒计时只是用户体验，不能当做安全防护。验证码禁止在 http 响应中返回。

案例 6：文件上传缺少后端校验，可上传恶意脚本文件；设计师数据隔离存在漏洞

踩坑前认知误区：前端限制图片后缀、大小，就可以控制上传内容。

业务场景：素材库上传、售后工单聊天图片上传。

现象复现

1. 抓包绕过前端校验，上传 exe/js/html 等非媒体文件；
2. 设计师账号部分接口没有做归属校验，可以读取不属于自己的订单、方案数据。

根因分析

1. 文件类型、大小校验只写在前端；后端没有二次校验；
2. 设计师行级数据隔离不全，部分读取、修改接口缺失checkDesignerScope归属校验。

整改方案

1. 后端校验上传文件：仅允许 jpg/png/webp/mp4；单文件最大 5MB，单次批量上传最多 9 张；
2. 补齐设计师全部业务接口的归属校验；封装checkDesignerScope公共函数；所有读取 / 修改订单、方案、工单、消息接口执行归属校验；列表查询直接在数据库查询条件拼接设计师 Id 做行级过滤；
3. 设计师即使抓包传入其他设计师 orderId，后端查询条件直接过滤，拿不到别人单据。

开发落地规范文件上传校验、行级数据隔离，后端必须兜底；前端校验仅做体验。设计师数据隔离不能靠前端隐藏列表，必须在数据库查询层过滤。

案例 7：客户手机号等敏感隐私信息未分级脱敏，内部账号可批量获取完整手机号

踩坑前认知误区：页面简单把手机号替换成星号展示就完成脱敏。

业务场景：客户列表、客户详情、Excel 导出客户数据。

现象复现运营、设计师账号页面虽然展示脱敏手机号；但是抓包接口响应可以拿到完整原始手机号；导出 Excel 也导出完整手机号。

根因分析脱敏只做在前端页面渲染；接口返回原始手机号，没有做后端层面的权限判断。缺少client:phone:view独立权限码。

整改方案

1. 新增权限码client:phone:view；仅超级管理员、财务账号拥有该权限；
2. 后端封装maskPhone脱敏工具；云函数返回客户数据时，判断当前账号权限；没有权限，后端直接返回脱敏后的手机号字符串；
3. Excel 导出逻辑同样复用该权限；无权限账号导出文件内手机号自动脱敏。

开发落地规范敏感数据脱敏，必须在后端接口输出层完成，禁止接口返回明文，靠前端页面打星号做脱敏。

案例 8：高危操作缺少二次密码校验，退款、重置密码可以直接执行

踩坑前认知误区：只要角色权限控制正确，高敏感业务不需要再次验证操作者身份。

业务场景：退款审核、重置后台账号密码、删除角色等高危操作。

现象复现账号一旦登录成功，就可以直接执行退款、重置他人密码，没有二次身份确认；如果账号被盗用，直接执行高危资金操作。

根因分析缺少敏感操作二次验密机制。

整改方案

1. 封装verifyReauthPassword公共工具函数；退款审核、重置密码、删除角色等高危操作，必须传入当前登录账号的登录密码；
2. 后端校验密码哈希，校验通过才执行业务；密码校验失败直接拦截操作；
3. 二次验密校验逻辑完全运行在云函数，前端弹窗只是收集密码输入，校验不交给前端。

开发落地规范涉及资金、账号权限变更的高危操作，增加后端二次密码校验，提升账号被盗之后的操作门槛。

本篇小结

本篇复盘 V1.0.1 整套底层安全体系的重构，一共 8 大类真实安全缺陷。 云开发 B 端后台很容易踩的共性安全误区：

1. 将鉴权、限流、文件校验、脱敏全部依赖前端实现；
2. 信任前端传入的身份、角色参数，缺少独立后端会话体系；
3. 审计日志交给前端写入，日志可伪造；
4. 行级数据隔离只做前端过滤，数据库查询层没有做强制过滤；
5. 高危操作只靠角色权限，缺少二次身份确认；
6. 密码、验证码这类敏感逻辑防护只在前端实现。

本项目最终落地三重 RBAC 防护模型：

1. 前端层：菜单隐藏、按钮置灰，仅作为用户体验防护，不承担安全；
2. 云函数接口层：token 会话解析、权限码校验、高危操作二次验密；
3. 数据库层：行级数据过滤、敏感字段后端脱敏、日志禁止删除更新。

重要：三重防护缺一不可，只做好其中一层，系统依旧存在安全漏洞。

下一篇预告：第九篇：花艺定制 SaaS｜全项目历程复盘、测试回归验收、实战深度总结

连载目录汇总
《云开发实战手记｜花艺定制 SaaS 门店管理系统》专栏目录

第一篇：花艺定制 SaaS｜产品需求总览（C 端小程序 + PC 商家后台）

第二篇：花艺定制 SaaS｜系统分层架构、业务流程总览

第三篇：花艺定制 SaaS｜C 端小程序 & PC 后台分角色分页面功能清单

第四篇：花艺定制 SaaS｜Vue3‑PC 商家后台全量踩坑复盘（业务 Bug + 云函数对接工程实战）

第五篇：花艺定制 SaaS｜两端数据联动踩坑复盘・上篇（订单、需求、方案、设计师档期同步）

第六篇：花艺定制 SaaS｜两端数据联动踩坑复盘・下篇（售后工单、佣金分销、统计报表）

第七篇：花艺定制 SaaS｜核心业务流程重构踩坑复盘｜退款审核、会员折扣、佣金冲减改造

第八篇：花艺定制 SaaS｜底层安全鉴权重构｜RBAC 三重权限、会话体系加固实战

第九篇：花艺定制 SaaS｜全项目历程复盘、测试回归验收、实战深度总结