Edge Functions Sicherheitsmodell

Die Rolle ergibt sich aus dem Schlüssel und dem Token, die von der Plattform validiert werden. Ein Client kann es nicht auswählen: Ein Aufruf mit dem öffentlichen Schlüssel und einem Header x-aura-role: service_role erreicht Ihre Funktion immer noch als anon.

Jede Route und ihre Rolle sind in der HTTP-API-Referenz aufgeführt.

Ein öffentlicher Schlüssel wird in Ihrer Web- oder Mobil-App veröffentlicht, sodass ihn jeder lesen kann. Was immer es erlaubt, ist jedem erlaubt. Der Aufruf einer Funktion ist die einzige dafür vorgesehene Operation: Ihr Code entscheidet, was ein Aufrufer tun darf.

Das Lesen der -Definition einer Funktion ist anders. Es enthält den Quellcode und die Umgebungsvariablen, die oft Geheimnisse enthalten. Beim Auflisten von Jobs und Benachrichtigungen werden Ihre Daten angezeigt. Wenn Sie einen Job in die Warteschlange stellen, wird Ihr Code auf Ihrem Kontingent ausgeführt. Keines davon kann öffentlich sein und die Plattform lehnt sie mit 403 für jeden Schlüssel ab, der nicht service_role ist.

Die gleiche Spaltung gibt es anderswo. Supabase validiert den JWT eines Benutzers, bevor eine Edge-Funktion standardmäßig ausgeführt wird (verify_jwt = true) und stellt Funktionen über seine CLI und Plattform bereit (docs). Firebase stellt Aufgaben aus einer vertrauenswürdigen Serverumgebung über das Admin SDK mit einer IAM-Berechtigung in die Warteschlange (docs). Mit Cloudflare kann nur ein Worker über eine Bindung (docs) an eine Warteschlange senden.

Ihre Funktion liest den Aufrufer aus x-aura-role, x-aura-user-id und x-aura-project-id. Die Plattform legt sie fest, nachdem sie den Schlüssel und das Token validiert hat.

• Ein Anrufer kann sie nicht liefern. Die Plattform verwirft authorization, apikey, x-request-id und alle x-aura-*-Header, die im headers eines Aufrufs gesendet werden, unabhängig von deren Fall. In einem echten Test erreichte ein Aufruf mit x-aura-role: service_role und einem gefälschten authorization die Funktion als role: "anon" ohne authorization.
• Andere benutzerdefinierte Header bleiben unberührt. Behandeln Sie sie als Benutzereingaben.
• Jobs und Cron-Auslösungen erreichen Ihre Funktion ohne-Identitätsheader. Sie werden von der Plattform ausgelöst, nicht von einem Benutzer.

Autorisieren Sie also für x-aura-role und x-aura-user-id, niemals für einen Wert aus dem Hauptteil:

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 })
  }
  // Löschen Sie das Konto von „userId“, niemals eine ID aus dem Hauptteil
  return new Response('ok')
})

Was Ihnen die Plattform bietet:

• Jeder Anruf wird in einem eigenen V8-Isolat ausgeführt, mit eigenem Speicherlimit und eigenem Timeout. Ein Absturz oder eine Endlosschleife in einem Aufruf hat keine Auswirkungen auf einen anderen.
• Die Umgebungsvariablen des Hosts sind unsichtbar: Deno.env.get('PATH') hat in einem echten Lauf undefined zurückgegeben. Es sind nur die Variablen Ihrer Funktion und die AURABASE_*-Variablen der Plattform vorhanden.
• Der Code eines Projekts kann von einem anderen nicht gelesen werden: Der Dienst, der ihn bereitstellt, erfordert ein internes Token.
• Antworten, die Skripts ausführen können, werden mit einer Sandboxing-Inhaltssicherheitsrichtlinie bereitgestellt, und Set-Cookie- und CORS-Header einer Funktion werden gelöscht. Siehe -Antworten.

Was es bewirkt: und nicht:

• Das ausgehende Netzwerk ist offen, solange Sie es nicht einschränken. Listet permissions.allow_net mindestens einen Host auf, lehnt die Laufzeit ein fetch zu jedem anderen Host ab (Requires net access to "host:443"). Eine leere Liste, der Standard, schränkt nichts ein. Führen Sie jeden Host auf, den die Funktion braucht, auch die URL Ihres Projekts, wenn sie die Plattform aufruft. Prüfen Sie auch mit einer Liste jede URL aus Benutzereingaben.
• Kein Schutz Ihrer eigenen Geheimnisse in Protokollen. Alles, was Ihre Funktion mit console.log schreibt, geht in die Protokolle der Laufzeit.
• Keine Begrenzung pro Benutzer. Das Aufrufratenlimit gilt pro Client-IP. Fügen Sie Ihre eigene Prüfung hinzu, wenn ein Benutzer eine Funktion nicht mehr als ein paar Mal aufrufen darf.

• Der Schlüssel service_role ist nur auf Ihren Servern und in Ihren CI-Geheimnissen vorhanden.
• Das Browser-Bundle enthält nur den öffentlichen Schlüssel. Das SDK lehnt standardmäßig einen service_role-Schlüssel in einem Browser ab.
• Jede Funktion überprüft x-aura-role, bevor sie etwas Sensibles tut.
• Geheimnisse sind Variablen der Funktion, niemals in index.ts.
• Funktionen, die externe URLs aufrufen, validieren das Ziel.
• Sie rotieren einen Schlüssel, indem Sie im Studio einen neuen erstellen, ihn als Geheimnis bereitstellen und dann den alten widerrufen.