基于Next.js+Prisma的API：前端传Prisma对象请求是否安全？

即使已经校验了会话和角色，这种实现方式仍然不安全，核心风险和对应解决方案如下：

核心风险 #

• 权限越权操作：前端可以随意传入超出其权限范围的参数。比如创建用户时，前端在data里偷偷加isAdmin: true，直接创建管理员账号；如果是更新接口，甚至可以传入where条件修改其他用户的数据，完全绕过角色校验的边界。
• 敏感数据泄露：通过include/select参数，前端可以关联查询原本不允许该角色访问的数据。比如普通用户创建自己账号时，指定include: { allUsers: true }（如果模型有这个关联），就能获取全平台用户的敏感信息。
• 性能与稳定性风险：前端可以传入复杂的嵌套关联查询，或者大量的skip/take参数，导致数据库执行低效查询，拖垮服务器性能。

安全的实现方案 #

• 严格参数白名单过滤：只允许前端传递预定义的合法参数，过滤掉所有未授权的字段和关联项。示例代码：

// 预定义允许的字段和关联
const allowedDataFields = ['name', 'age'];
const allowedIncludes = ['posts'];

// 过滤请求体中的data字段
const filteredData = Object.fromEntries(
  Object.entries(body.data || {}).filter(([key]) => allowedDataFields.includes(key))
);

// 过滤请求体中的include字段
const filteredInclude = Object.fromEntries(
  Object.entries(body.include || {}).filter(([key]) => allowedIncludes.includes(key))
);

// 执行Prisma操作
const user = await prisma.user.create({
  data: filteredData,
  include: filteredInclude,
});

• API路由对应明确操作：每个API路由只处理单一明确的业务逻辑，比如/api/users/create仅负责创建普通用户，不做通用的Prisma操作入口，从根源上避免前端随意控制操作逻辑。
• 服务器端管控敏感字段：敏感字段（如isAdmin、passwordHash）绝对不允许前端传入，必须由服务器端根据当前用户角色判断是否允许设置，比如只有管理员账号调用的接口才能设置isAdmin字段。

内容的提问来源于stack exchange，提问作者nbgslv