Edge Functions modelo de seguridad

El rol proviene de la clave y el token, que la plataforma valida. Un cliente no puede elegirlo: una llamada con la clave pública y un encabezado x-aura-role: service_role aún llega a tu función como anon.

Cada ruta y su función se enumeran en la referencia de la API HTTP .

Se publica una clave pública en su aplicación web o móvil, para que cualquiera pueda leerla. Lo que sea que permita, todo el mundo está permitido. Invocar una función es la única operación diseñada para eso: su código decide lo que puede hacer la persona que llama.

Leer la definición de una función es diferente. Contiene el código fuente y las variables de entorno, que a menudo guardan secretos. Listar trabajos y alertas muestra sus datos. Poner en cola un trabajo ejecuta su código en su cuota. Ninguno de estos puede ser público y la plataforma los rechaza con 403 para cualquier clave que no sea service_role.

La misma división existe en otros lugares. Supabase valida el JWT de un usuario antes de que se ejecute una función perimetral de forma predeterminada (verify_jwt = true) e implementa funciones a través de su CLI y plataforma (documentos). Firebase pone en cola tareas desde un entorno de servidor confiable a través del SDK de administración, con un permiso de IAM (documentos). Cloudflare permite que solo un trabajador envíe a una cola, a través de un enlace (docs).

Su función lee la persona que llama desde x-aura-role, x-aura-user-id y x-aura-project-id. La plataforma los configura después de validar la clave y el token.

• Una persona que llama no puede proporcionarlos. La plataforma descarta authorization, apikey, x-request-id y cualquier encabezado x-aura-* enviado en el headers de una invocación, cualquiera que sea su caso. En una prueba real, una llamada con x-aura-role: service_role y un authorization falsificado alcanzó la función como role: "anon" sin authorization.
• Otros encabezados personalizados pasan intactos. Trátelos como entrada del usuario.
• Los trabajos y los despidos cron llegan a su función sin encabezados de identidad. Los activa la plataforma, no el usuario.

Así que autorice en x-aura-role y x-aura-user-id, nunca en un valor del cuerpo:

Deno.serve((req) => {
  const userId = req.headers.get('x-aura-user-id')
  if (req.headers.get('x-aura-role') !== 'authenticated' || !userId) {
    return new Response('Forbidden', { status: 403 })
  }
  // eliminar la cuenta de `userId`, nunca de un id tomado del cuerpo
  return new Response('ok')
})

Qué te ofrece la plataforma:

• Cada llamada se ejecuta en su propio aislamiento V8, con su propio límite de memoria y tiempo de espera del reloj de pared. Un fallo o un bucle infinito en una llamada no afecta a otra.
• Las variables de entorno del host son invisibles: Deno.env.get('PATH') devolvió undefined en una ejecución real. Solo están presentes las variables de su función y las variables AURABASE_* de la plataforma.
• El código de un proyecto no puede ser leído por otro: el servicio que lo presta requiere un token interno.
• Las respuestas que pueden ejecutar scripts se entregan con una política de seguridad de contenido de espacio aislado y los encabezados Set-Cookie y CORS de una función se eliminan. Consulte las respuestas de .

Lo que te da y no:

• La red saliente está abierta mientras no la restrinja. Cuando permissions.allow_net enumera al menos un host, el tiempo de ejecución rechaza un fetch a cualquier otro host (Requires net access to "host:443"). Una lista vacía, el valor predeterminado, no restringe nada. Enumere cada host que necesita la función, incluida la URL de su proyecto si llama a la plataforma. Incluso con una lista, valide cualquier URL que provenga de la entrada del usuario.
• No hay protección de sus propios secretos en los registros. Todo lo que su función escriba con console.log va a los registros del tiempo de ejecución.
• Sin límite por usuario. El límite de tasa de invocación es por IP de cliente. Agregue su propia verificación si un usuario no debe llamar a una función más de unas cuantas veces.

• La clave service_role existe solo en sus servidores y en sus secretos de CI.
• El paquete del navegador contiene únicamente la clave pública. El SDK rechaza una clave service_role en un navegador de forma predeterminada.
• Cada función verifica x-aura-role antes de hacer algo sensible.
• Los secretos son variables de la función, nunca en index.ts.
• Las funciones que llaman a URL externas validan el destino.
• Para rotar una clave, crea una nueva en Studio, la implementa como secreta y luego revoca la anterior.