.Net Core项目中客户端JavaScript安全管理凭证方案咨询

核心原则 #

任何下发到浏览器客户端的密钥/凭证都不存在绝对安全的可能性，只要明文传输到前端，就可以通过开发者工具、网络抓包等方式被截获，你设想的调用后删除JS变量的方案完全无法规避风险，不要使用。

以下是兼顾安全性和开发效率的可行方案，按推荐优先级排序：

方案1：后端轻量API代理（最推荐，代码量极低） #

这是最稳妥的方案，你只需要在.Net Core项目中写一个通用的代理接口，所有前端对外部API的请求都先发送到这个代理接口，由后端带上API密钥转发给目标API，再把响应透传给前端即可。
.Net Core中可以借助IHttpClientFactory快速实现，示例代码如下：

[ApiController]
[Route("proxy")]
public class ExternalApiProxyController : ControllerBase
{
    private readonly IHttpClientFactory _httpClientFactory;
    // 密钥从配置中心/环境变量读取，禁止硬编码
    private readonly string _targetApiKey = Environment.GetEnvironmentVariable("TARGET_API_KEY");

    public ExternalApiProxyController(IHttpClientFactory httpClientFactory)
    {
        _httpClientFactory = httpClientFactory;
    }

    [HttpAcceptVerbs("GET", "POST", "PUT", "DELETE", Route = "{*path}")]
    public async Task<IActionResult> Proxy(string path)
    {
        var client = _httpClientFactory.CreateClient();
        client.DefaultRequestHeaders.Add("Authorization", $"ApiKey {_targetApiKey}");
        // 可在此处添加自定义权限校验，判断当前用户是否有权限调用该接口
        var requestMessage = new HttpRequestMessage(new HttpMethod(Request.Method), $"https://目标API根地址/{path}");
        if (Request.ContentLength > 0)
        {
            var content = await new StreamReader(Request.Body).ReadToEndAsync();
            requestMessage.Content = new StringContent(content, Request.ContentType);
        }
        var response = await client.SendAsync(requestMessage);
        var responseContent = await response.Content.ReadAsStringAsync();
        return new ContentResult
        {
            Content = responseContent,
            ContentType = response.Content.Headers.ContentType?.ToString(),
            StatusCode = (int)response.StatusCode
        };
    }
}

写完这一个通用接口后，前端所有需要调用外部API的请求，只要把目标路径替换为你本地的/proxy/xxx路径即可，不需要额外编写其他服务端代码，完全满足你节省开发时间的需求。同时密钥只会保存在服务端，永远不会暴露到前端，还可以按需添加限流、请求日志、参数校验等扩展能力。

方案2：申请短期受限令牌（适合外部API支持STS能力的场景） #

如果你调用的外部API支持生成临时访问令牌，可以在后端用永久密钥生成有效期极短（比如1~5分钟）、权限范围严格限制（比如仅允许查询指定资源、不允许修改/删除操作）的临时令牌，再下发给前端使用。
即使令牌被用户截获，也会在短时间内失效，且无法执行超出权限的操作，风险可控。这种方案你只需要额外编写一个获取临时令牌的后端接口即可，不需要做请求转发，开发量也很低。

方案3：最小权限密钥兜底（不推荐，仅适合非敏感场景） #

如果以上两种方案都无法实现，你只能选择将密钥下发到前端的话，必须做到以下几点降低风险：

• 单独为前端调用场景生成专用密钥，不要使用全局高权限密钥
• 严格限制该密钥的权限，仅开放你需要用到的最小操作权限
• 在外部API控制台配置域名白名单，仅允许你的网站域名调用该密钥
• 配置调用频率限制，避免密钥被滥用
• 定期轮换该密钥，降低泄露后的影响范围

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