前后端分离架构下,如何安全存储和使用 API 密钥?
大家好,我是 展菲,目前在上市企业从事人工智能项目研发管理工作,平时热衷于分享各种编程领域的软硬技能知识以及前沿技术,包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者:《ESP32-C3 物联网工程开发实战》
图书作者:《SwiftUI 入门,进阶与实战》
超级个体:COC上海社区主理人
特约讲师:大学讲师,谷歌亚马逊分享嘉宾
科技博主:华为HDE/HDG
我的博客内容涵盖广泛,主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告,同时也会提供产品优缺点分析、横向对比,并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲:您的前沿技术领航员
👋 大家好,我是展菲!
📱 全网搜索“展菲”,即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”,每周定时推送干货满满的技术长文,从新兴框架的剖析到运维实战的复盘,助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”,与我直接交流,不管是项目瓶颈的求助,还是行业趋势的探讨,随时畅所欲言。
📅 最新动态:2025 年 3 月 17 日
快来加入技术社区,一起挖掘技术的无限潜能,携手迈向数字化新征程!
文章目录
- 前言
- 为什么前端存放 API 密钥不安全?
- 正确思路:前端不碰密钥,后端来做转发
- 后端(Node.js + Express)
- 前端(Vue/React 都一样)
- 现实场景:为什么一定要这样做?
- 扩展方案:进一步保护密钥
- 总结
前言
在做前后端分离开发的时候,很多同学都会遇到一个头疼的问题:API 密钥怎么保密?
如果直接把密钥写在前端 JS 代码里,无论你怎么加密、怎么混淆,最终都能被别人通过浏览器调试工具拿到。那怎么办呢?本文就来聊聊常见的解决方案,并结合实际案例写一些可运行的 Demo 代码。
为什么前端存放 API 密钥不安全?
很多初学者喜欢在前端 .env
或者 JS 文件里直接写 API 密钥,比如:
// 错误做法
const API_KEY = "my-secret-api-key";fetch(`https://api.example.com/data?key=${API_KEY}`).then(res => res.json()).then(data => console.log(data));
问题在于,前端代码最终会被打包到浏览器里运行,用户只要打开 F12 调试工具就能看到网络请求里的 key,等于密钥完全裸奔。
所以,我们必须换一种思路:密钥不应该放在前端,而应该交给后端管理。
正确思路:前端不碰密钥,后端来做转发
核心原则其实很简单:
- 密钥只放在后端安全环境里(比如环境变量、配置文件)。
- 前端调用自己后端的 API,由后端去请求第三方服务。
这样用户拿到的只是你提供的业务接口,完全接触不到真实的密钥。
举个例子:
后端(Node.js + Express)
// server.js
import express from "express";
import fetch from "node-fetch";const app = express();
const PORT = 3000;// 将密钥放到环境变量
const API_KEY = process.env.API_KEY;app.get("/api/weather", async (req, res) => {try {// 后端替前端调用第三方 APIconst response = await fetch(`https://api.example.com/weather?key=${API_KEY}`);const data = await response.json();res.json(data);} catch (err) {res.status(500).json({ error: "后端调用失败", detail: err.message });}
});app.listen(PORT, () => {console.log(`后端服务已启动:http://localhost:${PORT}`);
});
前端(Vue/React 都一样)
// 前端只访问自己后端的接口,不涉及真实密钥
fetch("/api/weather").then(res => res.json()).then(data => console.log("天气数据:", data));
这样即便用户打开浏览器抓包,也只能看到 /api/weather
这个接口,拿不到第三方的真实 API Key。
现实场景:为什么一定要这样做?
比如我们做一个大学生实验课的天气查询系统:
- 学生在前端页面点击按钮,查询某个城市的实时天气。
- 如果你把 API Key 直接放在前端,学生就能拿到 Key 去无限调用,甚至滥用。
- 一旦 Key 被泄漏,你的付费额度可能会瞬间被刷爆。
而如果走后端转发:
- 学生的请求都先经过你的后端。
- 你可以在后端加 限流(Rate Limit)、日志监控、用户鉴权 等控制。
- 即使前端代码被扒了,也不会泄漏真正的 Key。
扩展方案:进一步保护密钥
除了最基本的后端代理思路,还可以结合以下方式:
- 限制来源 IP 或域名:大部分 API 平台支持设置白名单,只允许来自指定后端服务器的请求。
- JWT 授权机制:前端登录后获取一个临时 Token,带着 Token 请求后端,后端校验后再访问第三方 API。
- Serverless 云函数:把 API 请求封装在云函数里,比如阿里云/腾讯云函数,前端调用云函数而不是直接调用 API。
- API Gateway:通过网关统一管理 API 请求和密钥,便于日志和权限控制。
总结
前端分离开发时,API 密钥千万不要放在前端代码里,否则必然会泄漏。正确做法是:
- 把密钥放在后端。
- 前端只调用后端接口,由后端去访问第三方服务。
- 根据场景增加限流、日志、鉴权等机制。
这样不仅能保证密钥安全,还能让整个系统更稳定、更可控。