关于NextJS v13.4+ Server Actions的核心技术疑问与安全咨询

1. Server Actions 在功能上是否等同于对后端的 RPC 调用？ #

Server Actions 和传统后端 RPC 有功能重叠，但不能直接划等号：

• 相似点：两者都是触发服务端函数执行的机制，无需手动编写完整的 API 路由层，能直接调用服务端逻辑并获取结果。
• 差异点：Server Actions 是 Next.js 深度整合 React 生态的专属特性——它可以直接在 React 组件（客户端或服务端组件）中声明调用，支持表单原生提交（无 JS 场景），还能和 Next.js 的缓存、渲染体系联动；而通用 RPC 框架是跨技术栈的远程调用方案，没有和 React/Next.js 的渲染、表单系统做绑定。

2. 无 JavaScript 时，Server Actions 由什么执行？还有哪些功能优势？ #

• 无 JS 场景的执行机制：当用户禁用 JS 时，绑定了 Server Action 的 HTML 表单会通过浏览器原生表单提交触发请求——Next.js 服务端会直接接收这个表单请求，定位到对应的 Server Action 函数执行，然后返回渲染后的页面（或重定向）。
• 除兼容无 JS 场景外的优势：
  • 渐进增强体验：有 JS 时可以实现即时加载、错误提示等交互，无 JS 时依然保证核心功能可用。
  • 更低客户端负载：业务逻辑完全在服务端执行，不需要给客户端下发额外的 JS 代码，减少首屏加载体积。
  • 更可靠的提交流程：不会因为客户端 JS 报错、加载失败导致表单提交功能失效。
  • 更好的 SEO 友好性：爬虫能正常处理原生表单提交，不会因为依赖 JS 而无法抓取页面交互后的内容。

3. Server Actions 的安全考量及处理方式？是否限制仅当前应用客户端调用？ #

核心安全考量与处理方式 #

• CSRF 攻击防护：Next.js 默认给 Server Actions 启用了 CSRF 令牌验证——每个客户端会话会生成专属令牌，提交请求时会自动携带，服务端会校验令牌合法性，拦截非法跨站请求。
• 输入验证：必须对传入 Server Actions 的参数做严格校验（比如用 Zod、Yup 等工具），防止恶意输入导致的注入攻击。
• 权限控制：在 Server Action 内部必须添加身份校验逻辑，比如验证用户是否登录、是否拥有操作权限，避免未授权用户执行敏感操作。
• 函数暴露风险：避免把敏感逻辑的 Server Actions 配置为公开（默认是私有），防止不必要的暴露。

调用权限限制 #

• 默认情况下，只有当前应用的合法客户端可以调用：因为 CSRF 令牌和当前会话绑定，其他应用或通过 curl 直接调用时，无法获取有效的 CSRF 令牌，请求会被服务端拦截。
• 如果显式配置了 allowPublicAccess: true 把 Server Action 设置为公开，那么 curl 等工具可以直接调用，但此时必须自己额外添加权限控制（比如检查请求来源、用户身份），否则会存在安全风险。

内容的提问来源于stack exchange，提问作者Octo Palm Tree