Risorse · 37
Proteggere un'API GraphQL: autorizzazione, costo delle query e prove
Applicare i diritti su oggetti e campi, limitare il lavoro del server e testare i percorsi di negazione.
Aggiornato · 3 min
Obiettivi di questa guida
- Mappare lo schema esposto
- Esercitare le autorizzazioni
- Costo delle query vincolate
- Verificare i rifiuti
Verifica rapida
- Un account può leggere l'oggetto di un altro account?
- Un campo sensibile segue la decisione di accesso del suo elemento padre?
- Qual è il costo complessivo di profondità, alias e paginazione?
- Quali dettagli vengono divulgati tramite errori?
- Chi monitora i rifiuti e gli abusi?
Metodo passo passo
- 1
Operazioni di inventario
Elencare tipi, campi, mutazioni, ruoli, proprietari degli oggetti e dati sensibili. Includere le query client correnti e i percorsi raramente utilizzati.
Risultato: matrice di operazioni, ruoli, oggetti e campi.
- 2
Testare ogni decisione di accesso
Creare account di test distinti e scambiare gli ID degli oggetti, inclusi gli oggetti nidificati. I resolver devono applicare l'autorizzazione prima di restituire i dati.
Risultato: casi riproducibili di accesso consentito e negato.
- 3
Lavoro del server vincolato
Misurare il costo effettivo di campi e raccolte. Testare contemporaneamente profondità, ampiezza, alias, paginazione, batching e tempo, quindi impostare limiti appropriati.
Risultato: policy di costo e set di query avversarie.
- 4
Ridurre l'esposizione non necessaria
Decidere sull'introspezione per il contesto, nascondere i dettagli degli errori interni e rimuovere i campi che rivelano più di quanto necessario ai client.
Risultato: revisione della configurazione pubblica e delle risposte di errore.
- 5
Osservare con moderazione
Registrare identità tecniche utili, operazioni, costi, negazioni e correlazioni, escludendo segreti e argomenti sensibili. Assegnare la responsabilità degli avvisi.
Risultato: dashboard e procedura di indagine.
- 6
Riproduci dopo la modifica
Quando un campo, un ruolo o un client cambia, ripetere l'autorizzazione e i casi di carico. Verificare le vecchie query che ora attraversano il grafico rivisto.
Risultato: esito della regressione e decisione di rilascio.
Indicatori di gestione
| Indicatore | Cosa misura | Prima azione |
|---|---|---|
| Accesso | Casi di oggetti e campi negati come previsto | Correggere il resolver |
| Costo | Query complesse contenute dalla policy | Regolare campi e limiti |
| Errori | Risposte pubbliche senza dettagli interni | Ridurre i dettagli esposti |
| Regressione | Riproduzioni delle operazioni del client dopo la modifica | Blocco di malfunzionamenti involontari |
Errori comuni
- Affidamento esclusivo all'accesso agli endpoint
- Limitazione della profondità ma ignorazione dell'ampiezza
- Dimenticanza dell'autorizzazione dei campi annidati
- Registrazione degli argomenti con dati sensibili
Domande frequenti
GraphQL elimina la normale autorizzazione API?
No. Ogni accesso a oggetti e campi richiede comunque una decisione basata su identità e contesto.
Disabilitare l'introspezione è sufficiente?
No. Può ridurre l'esposizione dello schema, ma non risolve i costi di accesso o di query.
Un limite di profondità è sufficiente?
No. Anche alias, ampiezza, elenchi e costi specifici dei campi sono importanti.
Riferimenti ufficiali
I riferimenti supportano il metodo. Adattare i controlli al proprio contesto; non costituiscono una certificazione. I titoli dei riferimenti originali e i documenti di origine potrebbero essere in un'altra lingua.
