如何在iframe嵌入的JavaScript组件中安全保护API密钥

针对你遇到的API密钥暴露问题，核心思路是避免在前端（包括iframe的src参数）直接存放永久API密钥，以下是几个可落地的方案，结合你的React组件和Rails后端场景：

方案1：让客户服务器代理API请求（最安全） #

把API密钥放在客户自己的后端服务器中，iframe里的React组件只和客户后端通信，再由客户后端转发请求到你的Rails服务：

• 操作步骤：
  1. 客户在其后端存储你的API密钥（比如环境变量），并编写一个代理接口（比如/proxy/your-service）。
  2. 你的React组件将API请求发送到客户的代理接口，而非直接调用你的Rails API。
  3. 客户后端接收到请求后，在请求头或参数中带上API密钥，转发到你的Rails后端。
  4. 你的Rails服务验证密钥有效性后，返回结果给客户后端，再由客户后端返回给React组件。
• React示例（修改请求地址）：

// 原来的直接调用
// fetch('https://your-rails-api.com/data?api_key=XXX')

// 改为调用客户代理接口
fetch('https://customer-site.com/proxy/your-service/data')
  .then(res => res.json())
  .then(data => console.log(data))

• Rails端无需大幅修改，保持原有API密钥验证逻辑即可，请求来源变为可信的客户服务器，而非前端浏览器。

方案2：使用短期临时令牌替代永久API密钥 #

让客户通过后端向你的Rails服务申请短期令牌，iframe组件用令牌调用API，令牌过期自动失效：

• 操作步骤：
  1. 在Rails后端开发一个令牌生成接口（比如POST /api/tokens），客户后端携带自己的永久API密钥调用该接口，Rails验证后返回一个有效期较短的JWT或自定义令牌（比如15分钟）。
  2. 客户网站将生成的临时令牌通过postMessage传递给你的iframe组件，或者作为iframe的src参数（短期令牌即使暴露，风险也极低）。
  3. React组件拿到令牌后，在API请求头中携带令牌（比如Authorization: Bearer <token>）调用你的Rails API。
  4. Rails后端验证令牌的有效性、归属及过期时间，通过则处理请求。
• Rails令牌生成示例（用JWT）：

# Gemfile添加gem 'jwt'
# 控制器代码
class TokensController < ApplicationController
  def create
    customer = Customer.find_by(api_key: params[:api_key])
    if customer
      payload = { customer_id: customer.id, exp: 15.minutes.from_now.to_i }
      token = JWT.encode(payload, Rails.application.credentials.jwt_secret, 'HS256')
      render json: { token: token }
    else
      render json: { error: 'Invalid API key' }, status: :unauthorized
    end
  end
end

# API请求验证逻辑
before_action :validate_token

def validate_token
  token = request.headers['Authorization']&.split(' ')&.last
  begin
    payload = JWT.decode(token, Rails.application.credentials.jwt_secret, true, algorithm: 'HS256')
    @customer = Customer.find(payload[0]['customer_id'])
  rescue JWT::DecodeError, JWT::ExpiredSignature
    render json: { error: 'Invalid or expired token' }, status: :unauthorized
  end
end

• React接收令牌示例（postMessage方式）：

useEffect(() => {
  const handleMessage = (event) => {
    // 验证消息来源为客户网站域名
    if (event.origin === 'https://customer-site.com') {
      const tempToken = event.data.token;
      // 存储令牌到组件状态或localStorage（短期存储即可）
      setToken(tempToken);
    }
  };
  window.addEventListener('message', handleMessage);
  return () => window.removeEventListener('message', handleMessage);
}, []);

// 调用API时携带令牌
fetch('https://your-rails-api.com/data', {
  headers: {
    'Authorization': `Bearer ${token}`
  }
})

方案3：域名验证（辅助增强安全） #

作为上述方案的补充，在Rails后端验证请求的来源域名，只允许客户备案的域名发起请求：

• Rails实现示例：

before_action :validate_origin

def validate_origin
  # 假设Customer表存储了该客户允许的域名列表（比如allowed_origins字段为数组）
  allowed_origins = @customer&.allowed_origins || []
  request_origin = request.headers['Origin'] || request.referer&.match(/^https?:\/\/[^\/]+/)[0]
  
  unless allowed_origins.include?(request_origin)
    render json: { error: 'Unauthorized origin' }, status: :forbidden
  end
end

• 注意：该方案不能单独使用（请求头可被伪造），但能大幅降低恶意批量调用的风险，配合前两个方案使用效果更佳。

避坑提醒 #

不要尝试在前端加密API密钥——加密密钥本身仍会暴露在前端代码中，攻击者可获取加密后的密钥和加密逻辑，照样能伪造请求调用你的API。

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