React构建社交媒体站时如何防范未授权API调用与配置前后端鉴权？

前端鉴权永远只做体验优化，所有安全防护逻辑必须100%落在后端，不存在例外。你担心的“他人直接通过URL绕开前端发起请求”的问题，本质是错误把前端鉴权当成了安全屏障，这个设计思路从根源上就有漏洞。

需要，但核心目的不是防攻击，是优化用户体验：

• 未登录用户访问个人中心、内容发布页等需要权限的页面时，前端直接跳转登录页，比等接口返回403状态码再跳转响应更快，用户感知更好
• 前端可以根据用户权限提前隐藏无操作权限的按钮、菜单，避免用户点击后才弹出无权限提示
• 必须明确：这层防护没有任何安全作用，用户通过修改本地存储、浏览器控制台执行JS代码等方式，几秒钟就能绕开前端的所有路由拦截、组件渲染限制。

前端永远不可能阻止他人主动发起请求，所有拦截逻辑必须写在后端每一个接口的入口处，具体落地可以按以下步骤执行：

• 不要信任前端传递的任何权限标识。用户登录成功后，由后端生成带签名、带过期时间的会话凭证：优先选择存在HttpOnly、Secure属性的Cookie中（避免XSS攻击窃取凭证），不要把敏感凭证存在localStorage；凭证的生成、校验逻辑全由后端掌控，前端无法篡改、伪造。
• 所有涉及MongoDB读写的受保护接口，接收到请求的第一时间先校验凭证：未携带凭证、凭证过期、凭证签名不合法的，直接返回401状态码，不执行后续任何数据库操作逻辑。
• 做细粒度的权限校验，不能只判断“用户是否登录”。比如用户删除自己发布的动态时，接口需要校验这条动态的作者ID，是否和当前凭证解析出的用户ID一致，避免登录用户篡改请求参数操作他人数据。
• 配置CORS跨域白名单，只允许你自己的前端域名跨域调用接口，禁止设置Access-Control-Allow-Origin: *。注意这层只能挡住普通网页直接发起的跨域请求，挡不住Postman、curl、自定义脚本发起的请求，所以仅作为辅助防护，不能替代凭证校验。
• 增加基础的限流、防爬规则，比如同一个IP短时间内请求次数超过阈值就临时封禁，减少恶意刷接口的风险。

以下是后端接口校验的最简逻辑示例：

// 所有受保护接口都需要在业务逻辑前执行校验
app.get('/api/my/posts', async (req, res) => {
  // 1. 从请求Cookie中取登录凭证
  const token = req.cookies.auth_token
  if (!token) return res.status(401).send('未授权')
  // 2. 校验凭证合法性、过期时间，解析出当前登录用户ID
  let currentUserId
  try {
    currentUserId = jwt.verify(token, process.env.JWT_SIGN_SECRET)
  } catch (err) {
    return res.status(401).send('凭证无效')
  }
  // 3. 校验通过后再操作数据库，只返回当前用户有权限查看的数据
  const userPosts = await mongoDb.posts.find({ authorId: currentUserId })
  res.send(userPosts)
})

不管请求是从你的React应用发起，还是用户手动拼URL、用工具发起，只要携带的凭证不合法，就会被后端直接拦截，根本接触不到数据库操作逻辑，从根源上解决非法调用的问题。

问题在于把安全防护的重心放在了前端。你之前开发MVC架构站点时，受保护路由的拦截逻辑是写在服务端的，这个逻辑本身是正确的；开发React前后端分离应用时，只是把页面渲染的工作从服务端转移到了用户浏览器，所有安全校验的逻辑和MVC架构没有区别，必须全部落在服务端，不能有任何侥幸。

打个直白的比方：你不能把家门锁装在小区电梯里，指望电梯帮你拦没钥匙的人——电梯谁都能坐，别人甚至可以走楼梯上来。前端就是这个电梯，能帮用户省几步路，但真正的锁必须装在自己家门上，也就是后端每一个接口的入口处。

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