Modèle de sécurité Edge Functions

Le rôle vient de la clé et du token, que la plateforme valide. Un client ne peut pas le choisir : un appel avec la clé publique et un en-tête x-aura-role: service_role parvient toujours à votre fonction en tant que anon.

Chaque route et son rôle sont répertoriés dans la référence de l'API HTTP .

Une clé publique est publiée dans votre application Web ou mobile afin que tout le monde puisse la lire. Quoi que cela permette, tout le monde est autorisé. L'appel d'une fonction est la seule opération conçue pour cela : votre code décide de ce qu'un appelant peut faire.

La lecture de la définition d'une fonction est différente. Il contient le code source et les variables d'environnement, qui détiennent souvent des secrets. La liste des tâches et des alertes affiche vos données. La mise en file d'attente d'un travail exécute votre code sur votre quota. Aucun de ceux-ci ne peut être public, et la plateforme les refuse avec 403 pour toute clé autre que service_role.

La même fracture existe ailleurs. Supabase valide le JWT d'un utilisateur avant qu'une fonction Edge ne s'exécute par défaut (verify_jwt = true) et déploie des fonctions via sa CLI et sa plate-forme (docs). Firebase met en file d'attente les tâches d'un environnement de serveur de confiance via le SDK Admin, avec une autorisation IAM (docs). Cloudflare permet uniquement à un Worker d'envoyer vers une file d'attente, via une liaison (docs).

Votre fonction lit l'appelant depuis x-aura-role, x-aura-user-id et x-aura-project-id. La plateforme les définit après avoir validé la clé et le jeton.

• Un appelant ne peut pas les fournir. La plateforme supprime authorization, apikey, x-request-id et tout en-tête x-aura-* envoyé dans le headers d'une invocation, quel que soit leur cas. Lors d'un test réel, un appel avec x-aura-role: service_role et un faux authorization a atteint la fonction sous le nom role: "anon" sans authorization.
• Les autres en-têtes personnalisés restent intacts. Traitez-les comme une entrée utilisateur.
• Les tâches et les tirs cron atteignent votre fonction sans en-têtes d'identité. Ils sont déclenchés par la plateforme et non par un utilisateur.

Autorisez donc sur x-aura-role et x-aura-user-id, jamais sur une valeur du corps :

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 })
  }
  // supprimer le compte de `userId`, jamais d'un identifiant extrait du corps
  return new Response('ok')
})

Ce que la plateforme vous apporte :

• Chaque appel s'exécute dans son propre isolat V8, avec sa propre limite de mémoire et son propre délai d'expiration. Un crash ou une boucle infinie dans un appel n’affecte pas un autre.
• Les variables d'environnement de l'hôte sont invisibles : Deno.env.get('PATH') a renvoyé undefined lors d'une exécution réelle. Seules les variables de votre fonction et les variables AURABASE_* de la plateforme sont présentes.
• Le code d'un projet ne peut pas être lu par un autre : le service qui le sert nécessite un token interne.
• Les réponses qui peuvent exécuter des scripts sont servies avec une stratégie de sécurité du contenu en sandbox, et les en-têtes Set-Cookie et CORS d'une fonction sont supprimés. Voir les réponses .

Ce qu'il fait, et non vous donne :

• Le réseau sortant est ouvert tant que vous ne le restreignez pas. Quand permissions.allow_net liste au moins un hôte, le moteur refuse un fetch vers tout autre hôte (Requires net access to "host:443"). Une liste vide, la valeur par défaut, ne restreint rien. Listez chaque hôte dont la fonction a besoin, y compris l’URL de votre projet si elle appelle la plateforme. Même avec une liste, validez toute URL issue d’une saisie utilisateur.
• Aucune protection de vos propres secrets dans les journaux. Tout ce que votre fonction écrit avec console.log va dans les journaux d'exécution.
• Aucune limite par utilisateur. La limite du taux d'appel est par adresse IP client. Ajoutez votre propre vérification si un utilisateur ne doit pas appeler une fonction plusieurs fois.

• La clé service_role existe uniquement sur vos serveurs et dans vos secrets CI.
• Le bundle du navigateur contient uniquement la clé publique. Le SDK refuse par défaut une clé service_role dans un navigateur.
• Chaque fonction vérifie x-aura-role avant de faire quoi que ce soit de sensible.
• Les secrets sont des variables de la fonction, jamais dans index.ts.
• Les fonctions qui appellent des URL externes valident la destination.
• Vous faites pivoter une clé en en créant une nouvelle dans le Studio, en la déployant en tant que secret, puis en révoquant l'ancienne.