Edge Functions modello di sicurezza

Il ruolo deriva dalla chiave e dal token, che la piattaforma convalida. Un client non può sceglierlo: una chiamata con la chiave pubblica e un'intestazione x-aura-role: service_role raggiunge comunque la tua funzione come anon.

Ogni percorso e il relativo ruolo sono elencati nel riferimento API HTTP .

Una chiave pubblica viene pubblicata nella tua app Web o mobile, in modo che chiunque possa leggerla. Qualunque cosa permetta, è consentita a tutti. Invocare una funzione è l'unica operazione progettata per questo: il tuo codice decide cosa può fare un chiamante.

La lettura della definizione di una funzione è diversa. Contiene il codice sorgente e le variabili d'ambiente, che spesso contengono segreti. L'elenco dei lavori e degli avvisi mostra i tuoi dati. L'accodamento di un lavoro esegue il codice sulla tua quota. Nessuno di questi può essere pubblico e la piattaforma li rifiuta con 403 per qualsiasi chiave che non sia service_role.

La stessa divisione esiste altrove. Supabase convalida l'JWT di un utente prima che una funzione Edge venga eseguita per impostazione predefinita (verify_jwt = true) e distribuisce le funzioni tramite la CLI e la piattaforma (documenti). Firebase accoda le attività da un ambiente server attendibile tramite Admin SDK, con un'autorizzazione IAM (docs). Cloudflare consente solo a un lavoratore di inviare a una coda, tramite un'associazione (docs).

La tua funzione legge il chiamante da x-aura-role, x-aura-user-id e x-aura-project-id. La piattaforma li imposta dopo aver convalidato la chiave e il token.

• Un chiamante non può fornirli. La piattaforma scarta authorization, apikey, x-request-id e qualsiasi intestazione x-aura-* inviata in headers di un'invocazione, qualunque sia il loro caso. In un test reale, una chiamata con x-aura-role: service_role e un authorization contraffatto hanno raggiunto la funzione come role: "anon" senza authorization.
• Altre intestazioni personalizzate passano intatte. Trattateli come input dell'utente.
• I lavori e le attivazioni cron raggiungono la tua funzione senza intestazioni di identità. Vengono attivati ​​dalla piattaforma, non dall'utente.

Quindi autorizza su x-aura-role e x-aura-user-id, mai su un valore dal corpo:

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 })
  }
  // eliminare l'account di `userId`, mai di un id preso dal body
  return new Response('ok')
})

Cosa ti offre la piattaforma:

• Ogni chiamata viene eseguita nel proprio isolamento V8, con il proprio limite di memoria e timeout dell'orologio. Un arresto anomalo o un loop infinito in una chiamata non influisce su un'altra.
• Le variabili di ambiente dell'host sono invisibili: Deno.env.get('PATH') ha restituito undefined in un'esecuzione reale. Sono presenti solo le variabili della tua funzione e le variabili AURABASE_* della piattaforma.
• Il codice di un progetto non può essere letto da un altro: il servizio che lo serve richiede un token interno.
• Le risposte che possono eseguire script vengono fornite con una policy di sicurezza del contenuto sandbox e le intestazioni Set-Cookie e CORS da una funzione vengono eliminate. Vedi le risposte .

Cosa fa e non ti dà:

• La rete in uscita è aperta finché non la limiti. Quando permissions.allow_net elenca almeno un host, il runtime rifiuta un fetch verso qualsiasi altro host (Requires net access to "host:443"). Un elenco vuoto, il valore predefinito, non limita nulla. Elenca ogni host di cui la funzione ha bisogno, compreso l’URL del tuo progetto se chiama la piattaforma. Anche con un elenco, convalida qualsiasi URL proveniente dall’input dell’utente.
• Nessuna protezione dei tuoi segreti nei log. Tutto ciò che la tua funzione scrive con console.log va nei log del runtime.
• Nessun limite per utente. Il limite della velocità di chiamata è per IP client. Aggiungi il tuo controllo se un utente non deve chiamare una funzione più di poche volte.

• La chiave service_role esiste solo sui tuoi server e nei tuoi segreti CI.
• Il bundle del browser contiene solo la chiave pubblica. Per impostazione predefinita, l'SDK rifiuta una chiave service_role in un browser.
• Ogni funzione controlla x-aura-role prima di fare qualcosa di sensibile.
• I segreti sono variabili della funzione, mai in index.ts.
• Le funzioni che chiamano URL esterni convalidano la destinazione.
• Puoi ruotare una chiave creandone una nuova in Studio, distribuendola come segreta, quindi revocando quella vecchia.