Proxea Claude por una Edge Function de Supabase: la clave en el servidor, con auth y límites

Si tu frontend habla con Claude, la pregunta no es si meter un servidor en medio: es qué tan mínimo puede ser ese servidor sin dejar de hacer las tres cosas que de verdad importan. Tiene que guardar la API key donde el navegador no la pueda leer, decidir si quien pide tiene permiso de pedir, y evitar que una sola persona convierta tu factura de Anthropic en un ataque de denegación de cartera. Una Edge Function de Supabase hace las tres en un solo archivo Deno, desplegado al lado de tu base de datos. Esta guía la arma de punta a punta: la función, auth por JWT, whitelist del request, rate limiting por usuario, streaming y las pruebas que confirman que el camino de rechazo de verdad rechaza.

Uso este mismo patrón en Ilustrari (que opera como NexoString). El trabajo de multi-agente y soporte de decisiones en ThinkTank AI y Proyección llama a Claude, y ninguna de esas llamadas sale de un navegador que tenga la clave. Esta disciplina es lo que mantiene la clave de un fundador en solitario fuera del internet público y la factura bajo control.

01 · Por qué un proxy

Un request desde el navegador queda completamente a la vista de quien lo hace. Abre la pestaña de red y ahí está cada header, incluido x-api-key, en texto plano. No hay ofuscación que aguante a alguien con las herramientas de desarrollo y diez minutos. Así que una clave en el código del cliente es una clave publicada, da por filtrado cualquier proyecto que lo haga así.

El proxy mueve la llamada privilegiada a un lugar que tú controlas. El navegador habla con tu función usando el token de sesión del usuario; la función habla con Anthropic usando la clave secreta. Dos fronteras de confianza separadas, y la peligrosa nunca pisa terreno no confiable.

Hay una segunda razón que la gente suele descubrir por la vía cara. Aunque pudieras esconder la clave en el cliente, igual estarías dejando que el cliente arme el request completo a su antojo: qué modelo, cuántos tokens, cuántas llamadas. El proxy es donde recuperas ese control.

02 · Arma la función y guarda el secreto

Crea la función con la CLI. El nombre pasa a ser parte de la URL, así que elige algo aburrido y estable.

supabase functions new claude-chat

# Pon la clave en el almacén de secretos de la función — nunca en el código, nunca en el cliente.
supabase secrets set ANTHROPIC_API_KEY=sk-ant-...

# Despliega cuando estés listo (vuelve a correrlo después de cada cambio).
supabase functions deploy claude-chat

El secreto que pones con supabase secrets set solo se lee dentro de la función con Deno.env.get, y en ningún otro lado. No va en el bundle, no se manda al cliente y no se vuelve a ver en el dashboard una vez que lo configuras. En esa única propiedad está todo el sentido del ejercicio.

Un detalle sobre la auth de Supabase en Edge Functions

Por defecto, las Edge Functions de Supabase quedan detrás del gateway de la plataforma, que rechaza los requests sin una key válida de Supabase antes de que tu código siquiera corra. Es una primera barrera útil, pero no es autenticación de usuario, verifica que haya una key, no cuál usuario está llamando. De todos modos tienes que verificar el JWT del usuario dentro de la función. Las dos capas se complementan: el gateway deja afuera el ruido aleatorio de internet, y tu código decide quién en concreto tiene permiso.

03 · Verifica quién llama antes de hacer cualquier cosa

Las primeras líneas del handler deben rechazar a quien no sea un usuario con sesión iniciada. Hazlo antes de leer el body, llamar a Anthropic o tocar la base de datos. Un request sin autenticar no debería costarte ni un centavo.

import { createClient } from "jsr:@supabase/supabase-js@2"

Deno.serve(async (req) => {
  // 1. Rechaza de entrada cualquier cosa sin header Authorization.
  const authHeader = req.headers.get("Authorization")
  if (!authHeader) {
    return new Response("unauthorized", { status: 401 })
  }

  // 2. Verifica el JWT contra tu proyecto. getUser() valida la firma del
  //    token y su expiración — no confíes en un token que solo decodificaste.
  const supabase = createClient(
    Deno.env.get("SUPABASE_URL")!,
    Deno.env.get("SUPABASE_ANON_KEY")!,
    { global: { headers: { Authorization: authHeader } } },
  )
  const { data: { user }, error } = await supabase.auth.getUser()
  if (error || !user) {
    return new Response("unauthorized", { status: 401 })
  }

  // De aquí en adelante, `user.id` es un usuario real y verificado. Todo lo
  // de abajo se apoya en ese id — rate limits, logging y cualquier regla por usuario.
  // ... seguimos en los próximos pasos ...
  return new Response("ok")
})

La línea que importa es getUser(). Decodificar un JWT te dice lo que afirma; verificarlo te dice si creerle. Un token decodificado pero no verificado se puede falsificar. Cualquiera arma uno con el user.id que se le antoje. getUser() chequea la firma contra el secreto de tu proyecto, así que un token falsificado se cae aquí.

04 · Whitelist del request, acota los topes

Aquí está el error que convierte un proxy funcional en una barra libre: reenviarle a Anthropic el body JSON completo del cliente. Si el cliente puede darle forma al body, quien llama puede poner en model tu modelo más caro, empujar max_tokens al máximo y mandar unos cuantos miles de esos en un loop. Te enteras al cierre del ciclo de facturación.

Arma el request de salida desde cero. Lee solo los campos que piensas exponer, valídalos e impón tus propios topes.

// Dentro del handler, una vez que pasa la auth:
const body = await req.json().catch(() => null)
if (!body || !Array.isArray(body.messages)) {
  return new Response("bad request", { status: 400 })
}

// Arma el request de Anthropic tú mismo. NO hagas `...body`.
const MAX_OUTPUT = 4096
const upstream = {
  model: "claude-opus-4-8",                 // el servidor elige el modelo, no el cliente
  max_tokens: Math.min(body.max_tokens ?? MAX_OUTPUT, MAX_OUTPUT),
  messages: body.messages.slice(-20),       // acota también el largo de la conversación
  stream: true,
}

const res = await fetch("https://api.anthropic.com/v1/messages", {
  method: "POST",
  headers: {
    "x-api-key": Deno.env.get("ANTHROPIC_API_KEY")!,
    "anthropic-version": "2023-06-01",
    "content-type": "application/json",
  },
  body: JSON.stringify(upstream),
})

Ahí hay varias decisiones tomadas a propósito. El model se fija en el servidor. El cliente nunca lo nombra, así que no puede echar mano de una tier más cara. max_tokens se acota con Math.min contra un tope duro, de modo que un cliente que pida 200000 recibe 4096. El arreglo messages se recorta para que nadie pueda pegar un megabyte de historial y volver gigante cada llamada. Hacer whitelist quiere decir que el request de salida lleva exactamente los campos que tú decidiste y nada que el cliente haya colado.

05 · Rate limiting por usuario con una sola tabla

La auth frena a los extraños; no hace nada contra un usuario con sesión (o una sesión robada) martillando el endpoint. La solución que escala con la menor maquinaria es un contador por usuario en Postgres, chequeado de forma atómica en cada llamada.

create table api_rate_limits (
  user_id uuid not null references auth.users (id),
  window_start timestamptz not null,
  count int not null default 0,
  primary key (user_id, window_start)
);

-- Incremento atómico para una ventana fija (por ejemplo, el minuto actual).
-- Devuelve el conteo ya incrementado para que la función pueda decidir.
create function bump_rate_limit(uid uuid, win timestamptz)
returns int language sql as $func$
  insert into api_rate_limits (user_id, window_start, count)
  values (uid, win, 1)
  on conflict (user_id, window_start)
  do update set count = api_rate_limits.count + 1
  returning count;
$func$;

En la función, redondea el reloj a una ventana, llama a bump_rate_limit y corta con un 429 si el conteo pasa tu límite, antes de gastar un token en Anthropic. Como el incremento y la lectura ocurren en una sola sentencia, dos requests concurrentes no pueden colarse ambos bajo el límite; Postgres serializa el upsert que entra en conflicto.

Por usuario le gana a por IP en una API autenticada. Las IP son compartidas (oficinas, operadoras móviles, VPNs) y se rotan sin el menor esfuerzo; el user.id verificado es lo que de verdad quieres limitar. Si además quieres un cortacircuitos global, digamos, un tope duro para todos los usuarios juntos que proteja la factura pase lo que pase, agrega un segundo contador con clave en una constante. Dos contadores baratos, dos radios de impacto distintos.

06 · Devuelve el stream y llámalo desde el cliente

Las respuestas de Claude pueden ser largas, y un proxy sin streaming deja al usuario mirando un spinner mientras se genera la respuesta completa, y se arriesga a que la función choque con su límite de tiempo de ejecución en una respuesta grande. Como ya pusiste stream: true en el request de salida, pasa ese stream directo de vuelta al navegador.

// Reenvía el stream SSE de Anthropic al cliente tal cual, sin tocarlo.
return new Response(res.body, {
  status: res.status,
  headers: {
    "content-type": "text/event-stream",
    "cache-control": "no-cache",
    "connection": "keep-alive",
  },
})

En el cliente, llama a la URL de la función con el token de sesión del usuario y lee el stream conforme va llegando. El token de sesión es el access_token de la sesión actual de Supabase, nunca la clave service-role, nunca la clave de Anthropic.

El ciclo completo se lee limpio ahora: el navegador manda un token de sesión y un arreglo de mensajes; la función verifica al usuario, chequea el rate limit, arma un request acotado, llama a Claude con la clave secreta y devuelve la respuesta en streaming. La clave se quedó en el servidor todo el tiempo, y en ningún momento el cliente pudo elegir el modelo ni el presupuesto de tokens.

Dos cosas separan un proxy que funciona en un demo de uno que dejarías corriendo en serio. Prueba los caminos de rechazo: un request sin token, un token expirado, un token falsificado y un usuario que se pasó del rate limit deben devolver cada uno el status correcto y cero llamadas a Anthropic. Y vigila la factura la primera semana; un log por usuario del consumo de tokens (un insert más en el handler) convierte el "¿habrá alguien abusando de esto?" de una corazonada en una query.