Edge Functions beveiligingsmodel

De rol komt voort uit de sleutel en het token, die het platform valideert. Een client kan er niet voor kiezen: een oproep met de publieke sleutel en een header x-aura-role: service_role bereikt nog steeds jouw functie als anon.

Elke route en zijn rol worden vermeld in de HTTP API-referentie.

Er wordt een openbare sleutel gepubliceerd in uw web- of mobiele app, zodat iedereen deze kan lezen. Wat het ook toelaat, iedereen mag. Het aanroepen van een functie is de enige handeling die daarvoor is ontworpen: uw code bepaalt wat een beller mag doen.

Het lezen van de definitie van een functie is anders. Het bevat de broncode en de omgevingsvariabelen, die vaak geheimen bevatten. Door vacatures en waarschuwingen weer te geven, worden uw gegevens weergegeven. Als u een taak in de wachtrij plaatst, wordt uw code uitgevoerd op basis van uw quotum. Geen van deze kan openbaar zijn en het platform weigert ze met 403 voor elke sleutel die niet service_role is.

Dezelfde splitsing bestaat elders. Supabase valideert de JWT van een gebruiker voordat een Edge-functie standaard wordt uitgevoerd (verify_jwt = true) en implementeert functies via de CLI en het platform (docs). Firebase plaatst taken uit een vertrouwde serveromgeving in de wachtrij via de Admin SDK, met een IAM-machtiging (docs). Met Cloudflare kan alleen een werknemer naar een wachtrij verzenden, via een binding (docs).

Uw functie leest de beller van x-aura-role, x-aura-user-id en x-aura-project-id. Het platform stelt ze in nadat het de sleutel en het token heeft gevalideerd.

• Een beller kan deze niet verstrekken. Het platform verwijdert authorization, apikey, x-request-id en elke x-aura-* header die in de headers van een aanroep wordt verzonden, ongeacht het geval. In een echte test bereikte een aanroep met x-aura-role: service_role en een vervalste authorization de functie als role: "anon" zonder authorization.
• Andere aangepaste headers gaan onaangeroerd door. Behandel ze als gebruikersinvoer.
• Taken en cron-vuren bereiken uw functie zonder identiteitsheaders. Ze worden geactiveerd door het platform, niet door een gebruiker.

Dus autoriseer op x-aura-role en x-aura-user-id, nooit op een waarde uit de hoofdtekst:

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 })
  }
  // verwijder het account van `userId`, nooit van een ID uit de hoofdtekst
  return new Response('ok')
})

Wat het platform u biedt:

• Elke oproep wordt uitgevoerd in zijn eigen V8-isolaat, met zijn eigen geheugenlimiet en time-out van de wandklok. Een crash of een oneindige lus in de ene oproep heeft geen invloed op de andere.
• De omgevingsvariabelen van de host zijn onzichtbaar: Deno.env.get('PATH') retourneerde undefined in een echte run. Alleen de variabelen van uw functie en de AURABASE_*-variabelen van het platform zijn aanwezig.
• De code van het ene project kan niet door het andere worden gelezen: de dienst die het bedient, heeft een intern token nodig.
• Reacties die scripts kunnen uitvoeren, worden geleverd met een sandboxing-inhoudsbeveiligingsbeleid, en Set-Cookie- en CORS-headers van een functie worden verwijderd. Zie antwoorden.

Wat het u geeft en niet:

• Uitgaand netwerk staat open zolang u het niet beperkt. Als permissions.allow_net minstens één host noemt, weigert de runtime een fetch naar elke andere host (Requires net access to "host:443"). Een lege lijst, de standaardwaarde, beperkt niets. Noem elke host die de functie nodig heeft, inclusief de URL van uw project als ze het platform aanroept. Valideer ook met een lijst elke URL die uit gebruikersinvoer komt.
• Geen bescherming van uw eigen geheimen in logboeken. Alles wat uw functie met console.log schrijft, gaat naar de runtimelogboeken.
• Geen limiet per gebruiker. De limiet voor het aanroeppercentage geldt per client-IP. Voeg uw eigen controle toe als een gebruiker een functie niet vaker dan een paar keer mag aanroepen.

• De sleutel service_role bestaat alleen op uw servers en in uw CI-geheimen.
• De browserbundel bevat alleen de openbare sleutel. De SDK weigert standaard een service_role-sleutel in een browser.
• Elke functie controleert x-aura-role voordat er iets gevoeligs gebeurt.
• Geheimen zijn variabelen van de functie, nooit in index.ts.
• Functies die externe URL's aanroepen, valideren de bestemming.
• Je roteert een sleutel door een nieuwe aan te maken in de Studio, deze als geheim in te zetten en vervolgens de oude in te trekken.