La sicurezza delle API GraphQL è l’insieme di pratiche e tecnologie utilizzate per proteggere le API GraphQL da accessi non autorizzati, richieste dannose, esposizione dei dati, attacchi Denial of Service e abusi.
GraphQL, che è un linguaggio di query open source, offre ai client (computer, telefoni o browser, programmi software) una notevole flessibilità sui dati che richiedono. Invece di basarsi su endpoint predefiniti che restituiscono risposta fisse, i client possono costruire query che specificano i campi e i dati correlati di cui hanno bisogno.
Questa flessibilità può rendere le API più efficienti per gli sviluppatori, ma introduce anche considerazioni specifiche sulla sicurezza. Un’API GraphQL protetta in modo inadeguato può consentire agli hacker di costruire query computazionalmente costose, individuare parti sensibili di uno schema API, accedere a dati che non sono autorizzati a vedere o automatizzare un gran numero di richieste dannose.
Una sicurezza GraphQL efficace richiede quindi una combinazione di autenticazione, autorizzazione, controllo delle query, convalida degli input, limitazione della velocità, sicurezza dell'applicazione, monitoraggio e progettazione sicura di API.
Quali strumenti e pratiche comprendono la sicurezza delle API GraphQL?
La sicurezza delle API GraphQL protegge i dati, le operazioni e l’infrastruttura esposti tramite un’API GraphQL. Un’API GraphQL espone in genere uno schema che descrive i tipi di dati disponibili e le operazioni che i client possono eseguire. I client inviano query o mutazioni che descrivono le informazioni o le azioni che vogliono.
La protezione delle API GraphQL implica pratiche e strumenti relativi a:
Autenticazione
autorizzazione
Validazione dell’input
Controllo della profondità e della complessità delle query
Gestione dello schema e dell’introspezione
Protezione dalle injection
Gestione degli errori
Logging e monitoraggio
L’obiettivo è fornire ai client legittimi le funzionalità di cui hanno bisogno, senza limitare la flessibilità di GraphQL.
Come funziona la sicurezza delle API GraphQL?
Una richiesta GraphQL in genere raggiunge un singolo endpoint HTTP, come “/graphql”. La richiesta contiene una query che descrive l'operazione che il client vuole che il server esegua. Un client legittimo potrebbe richiedere informazioni su un prodotto e sulla sua disponibilità.
Il server GraphQL analizza la query, la convalida rispetto allo schema, richiama i resolver necessari, recupera i dati appropriati e restituisce una risposta.
I controlli di sicurezza possono essere applicati in diverse fasi di quel processo.
L’autenticazione identifica il client
L’autenticazione determina chi o che cosa sta effettuando la richiesta. Le API GraphQL possono usare meccanismi come cookie di sessione, chiavi API, OAuth o JSON Web Tokens (JWT), a seconda dell’architettura dell’applicazione.
L’autorizzazione controlla ciò che il client può fare
La sola autenticazione non è sufficiente. Dopo aver identificato il client, l'applicazione deve determinare se tale identità è autorizzata ad accedere a un particolare oggetto, campo o operazione.
L'autorizzazione dovrebbe essere applicata nel livello della logica di business anziché basarsi esclusivamente sui resolver GraphQL o nascondere parti dello schema.
I controlli delle query limitano le operazioni costose
Le query GraphQL possono essere annidate. Senza controlli appropriati, un client potrebbe inviare una query che richiede un uso significativo di CPU, memoria, lavoro del database o chiamate a servizi downstream.
Le applicazioni possono analizzare la profondità, l’ampiezza, la complessità o il costo delle query e rifiutare le richieste che superano i limiti accettabili.
La limitazione della velocità controlla il consumo di richieste
I rate limit possono controllare la frequenza con cui i client eseguono operazioni. Per GraphQL, le organizzazioni potrebbero aver bisogno di controlli più sofisticati del semplice conteggio delle richieste HTTP, perché due richieste allo stesso endpoint /graphql possono avere costi computazionali drasticamente diversi.
I controlli di sicurezza delle applicazioni ispezionano il traffico dannoso
Un web application firewall (WAF) o una piattaforma di protezione delle applicazioni web e delle API può ispezionare le richieste per individuare attacchi come l'injection e altri payload dannosi prima che raggiungano l'applicazione GraphQL.
Il monitoraggio rileva un comportamento insolito
I log e la telemetria di sicurezza possono rivelare pattern di query imprevisti, ripetuti errori di autorizzazione, richieste insolitamente costose, bot dannosi o picchi di traffico. Insieme, questi controlli forniscono una difesa a più livelli intorno alla GraphQL API.
Perché è necessaria la sicurezza delle API GraphQL?
GraphQL non rende intrinsecamente insicura un’API. Tuttavia, alcune delle funzionalità che rendono GraphQL potente comportano anche considerazioni sulla sicurezza diverse da quelle delle API REST convenzionali.
Di seguito sono riportati i rischi introdotti dalla natura di GraphQL e i motivi per cui la sicurezza delle API GraphQL è così importante.
I clienti hanno un controllo significativo sulle query
Con un’API REST, il server definisce comunemente endpoint che restituiscono strutture di dati predeterminate. Invece, GraphQL consente al client di specificare i campi e le relazioni che desidera. Senza restrizioni adeguate, un client malintenzionato può potenzialmente sfruttare tale flessibilità per costruire query costose o abusive.
Un singolo endpoint può esporre molte Operazioni
La tradizionale sicurezza delle API spesso utilizza i percorsi URL come parte importante della policy di sicurezza. GraphQL instrada comunemente molte query e mutazioni diverse attraverso lo stesso endpoint. Un sistema di sicurezza quindi non può presumere che tutte le richieste a /graphql rappresentino la stessa operazione o lo stesso rischio.
Le query possono diventare onerose dal punto di vista computazionale
GraphQL consente relazioni annidate. Una query profondamente annidata o eccezionalmente ampia può causare molte chiamate al resolver, operazioni del database o richieste downstream. Gli hacker possono sfruttare intenzionalmente questo comportamento per consumare le risorse dell'applicazione.
L'autorizzazione può diventare granulare
A un utente potrebbe essere consentito accedere a un oggetto GraphQL ma non a un altro, oppure ad alcuni campi di un oggetto ma non ad altri. Ogni operazione di accesso ai dati pertinente richiede pertanto un’autorizzazione appropriata.
Le informazioni sullo schema possono aiutare gli hacker
GraphQL supporta l'introspection, che consente ai client di eseguire query di informazioni sullo schema. Questo è estremamente utile per gli strumenti di sviluppo. In produzione, tuttavia, le organizzazioni dovrebbero prendere una decisione consapevole sull'effettiva necessità di un'introspezione senza restrizioni, perché le informazioni sullo schema possono aiutare gli hacker a comprendere le Operazioni disponibili.
Le API attirano abusi automatizzati
Gli hacker possono usare bot per eseguire ricognizione, attacchi alle credenziali, query di Operazioni costose, estrarre dati o tentare lo sfruttamento su larga scala. La sicurezza di GraphQL deve quindi affrontare sia le vulnerabilità sia l'abuso di funzionalità legittime.
Quali sono i rischi comuni per la sicurezza delle API GraphQL?
Autorizzazione non valida
Un’API può autenticare correttamente un utente ma non verificare se a quell’utente debba essere consentito l’accesso a un particolare oggetto o campo. Ad esempio, modificare un identificatore di oggetto in una query non dovrebbe consentire a un cliente di recuperare le informazioni private di un altro cliente.
Profondità eccessiva della query
Un hacker può costruire query profondamente nidificate che richiedono quantità di elaborazione sempre maggiori. I limiti di profondità possono impedire che le richieste superino i ragionevoli requisiti di nidificazione di un’applicazione.
Complessità delle query ed esaurimento delle risorse
La profondità non è l’unico aspetto da considerare: una query relativamente superficiale potrebbe richiedere migliaia di oggetti o richiamare resolver costosi. L’analisi del costo o della complessità delle query può offrire una protezione più precisa stimando le risorse necessarie per eseguire una richiesta.
Abuso del batching
Le implementazioni GraphQL possono consentire l’invio di più Operazioni insieme. Sebbene il batching possa migliorare l'efficienza delle applicazioni legittime, gli hacker potrebbero tentare di usarlo per aggirare semplici rate limit basati sulle richieste o eseguire un gran numero di Operazioni con un numero inferiore di richieste HTTP.
attacco injection
I resolver GraphQL interagiscono spesso con i database e altri sistemi backend. Se l’input dell’utente viene gestito in modo non sicuro nei sistemi downstream, le applicazioni GraphQL possono comunque essere vulnerabili a SQL injection, command injection e altri attacchi injection.
Divulgazione di informazioni
Gli errori dettagliati possono esporre stack trace, dettagli di implementazione interni o altre informazioni utili agli hacker. L’introspezione dello schema può anche divulgare informazioni sui tipi e sulle Operazioni disponibili quando è abilitata.
Denial of Service
Query costose, alias eccessivi, batching, richieste ripetute o altre operazioni ad alta intensità di risorse possono essere usati per degradare le prestazioni o la disponibilità dell’applicazione.
Scraping automatizzato e abusi
Una query GraphQL tecnicamente valida può comunque essere abusiva quando viene eseguita automaticamente su larga scala. La gestione dei bot e la limitazione della velocità possono essere importanti complementi alla sicurezza delle API incentrata sulle vulnerabilità.
Quali sono le migliori pratiche di sicurezza per le API GraphQL?
La sicurezza di GraphQL dovrebbe iniziare dall'applicazione stessa ed essere rafforzata con controlli di sicurezza del runtime.
1. Richiedi un'autenticazione avanzata
Proteggi le operazioni non pubbliche con meccanismi di autenticazione appropriati. Usa standard di identità consolidati e una gestione sicura delle sessioni o dei token, invece di creare schemi di autenticazione personalizzati senza un motivo valido.
2. Applica l'autorizzazione a ogni livello pertinente
Non dare per scontato che gli utenti autenticati debbano avere accesso a ogni oggetto esposto tramite lo schema. L’autorizzazione deve essere collegata alle regole di business dell’applicazione e applicata in modo coerente quando si accede ai dati o li si modifica.
3. Limite della profondità della query
Imposta limiti ragionevoli alla profondità di annidamento delle query. Il massimo appropriato dipende dai requisiti legittimi dell’applicazione.
4. Implementa l’analisi del costo delle query
Assegna costi ai campi o alle operazioni in base al consumo previsto di risorse e rifiuta le richieste il cui costo calcolato supera una soglia accettabile. Questo può offrire una protezione più significativa rispetto ai soli limiti di profondità.
5. Applica i rate limit
Applica il rate limit ai client in base al rischio dell’applicazione e ai normali modelli di uso. Ove possibile, considera l’effettiva operazione GraphQL o il costo della risorsa invece di trattare ogni richiesta HTTP come equivalente.
6. Controllo di batching e alias
Imposta limiti ragionevoli sul numero di operazioni, alias o campi che un client può richiedere contemporaneamente. Questo può ridurre le opportunità di aggirare i rate limit convenzionali o creare carichi di lavoro inaspettatamente costosi.
7. Convalida tutti gli input
Tratta gli argomenti GraphQL come input non attendibili. Usa la convalida dello schema, query di database parametrizzate, API sicure e una gestione dell’output appropriata al contesto.
8. Prendi una decisione intenzionale sull'introspezione
L'introspection è preziosa per lo sviluppo e gli strumenti, ma l'accesso in produzione dovrebbe essere in linea con i requisiti dell'organizzazione. Disabilitare o limitare l'introspection non sostituisce l'autorizzazione, ma può ridurre l'esposizione non necessaria di informazioni.
9. Evita dettagli eccessivi sugli errori
Restituisci errori utili ai client legittimi senza esporre stack trace, informazioni sul database, dettagli del servizio interno o altre informazioni sensibili sull'implementazione.
10. Usa i timeout
Le query non dovrebbero poter consumare risorse del server indefinitamente. Timeout appropriati per l’esecuzione, il database e i servizi downstream possono limitare l’impatto di operazioni inaspettatamente costose.
11. Proteggi l'endpoint GraphQL con un web application firewall
Un web application firewall può fornire un ulteriore livello di sicurezza contro richieste di applicazione dannose. Non dovrebbe sostituire una progettazione GraphQL sicura, ma può aiutare a impedire che gli attacchi raggiungano componenti dell’applicazione vulnerabili.
12. Monitorare il traffico GraphQL
Traccia i tassi di richieste, gli errori, i fallimenti di autenticazione, i modelli di operazione, la complessità delle query, la latenza del backend e il consumo di risorse. Un'osservabilità efficace semplifica l'identificazione di attacchi e problemi di prestazioni prima che incidano significativamente sugli utenti.
Chi ha bisogno della sicurezza delle API GraphQL?
Qualsiasi organizzazione che esponga API GraphQL dovrebbe implementare controlli di sicurezza appropriati, ma questa esigenza diventa particolarmente importante per le API che gestiscono dati sensibili, volumi di traffico elevati o Operazioni aziendali di valore.
Provider SaaS
GraphQL può consentire alle applicazioni front end di recuperare in modo efficiente dati complessi di clienti e applicazioni. Un’autorizzazione efficace è essenziale negli ambienti multi-tenant per impedire che i dati oltrepassino i confini tra clienti.
Aziende di e-commerce
Le API GraphQL possono esporre cataloghi di prodotti, account cliente, carrelli, inventario, funzionalità di checkout e altre operazioni di alto valore. Queste API possono attirare scraping, attacchi alle credenziali, frodi e attacchi alla disponibilità.
Servizi finanziari
Le API che gestiscono informazioni finanziarie o personali richiedono autenticazione, autorizzazione, monitoraggio e prevenzione degli abusi efficaci.
Aziende del settore media ed editoria
GraphQL può fornire un accesso flessibile a grandi librerie di contenuti, ma può anche diventare un obiettivo per lo scraping non autorizzato e per query ad alto consumo di risorse.
Sviluppatori di dispositivi mobili e applicazioni
GraphQL è utile quando client diversi necessitano di sottoinsiemi di dati diversi. Le applicazioni mobili comunicano comunque con API accessibili pubblicamente, quindi un hacker può potenzialmente interagire direttamente con l’API anziché usare l’applicazione ufficiale.
Aziende che utilizzano microservizi
GraphQL può fornire un livello API unificato su più servizi backend. Questo rende la sicurezza particolarmente importante perché un'interfaccia GraphQL può fornire accesso a dati e funzionalità distribuiti tra numerosi sistemi interni.
In che modo Fastly può aiutare a proteggere le API GraphQL?
Fastly offre diverse funzionalità di sicurezza che possono integrare i controlli implementati all'interno di un'applicazione GraphQL.
WAF Next-Gen di Fastly
WAF Next-Gen di Fastly protegge le applicazioni web e le API dalle richieste dannose. Utilizza la tecnologia di rilevamento SmartParse di Fastly per analizzare i parametri delle richieste e identificare il comportamento dannoso delle applicazioni, anziché dipendere esclusivamente dalla tradizionale corrispondenza tramite espressioni regolari.
Questo può fornire un ulteriore livello di protezione contro gli attacchi di injection e altri attacchi a livello di applicazione che prendono di mira le API GraphQL.
Funzionalità di sicurezza delle API Fastly
Le funzionalità di Fastly per la protezione delle applicazioni web e delle API possono aiutare le organizzazioni a proteggere le API insieme alle applicazioni web tradizionali. Posizionare la sicurezza ai bordi della rete consente di ispezionare le richieste dannose prima che consumino le risorse dell'applicazione GraphQL, del database o dei servizi backend.
Questo è particolarmente utile nelle architetture GraphQL, dove una richiesta può potenzialmente attivare un notevole lavoro a valle.
Gestione dei bot di Fastly
Una richiesta GraphQL non deve necessariamente un exploit per causare danni. Gli hacker possono usare client automatizzati per estrarre dati, analizzare schemi e operazioni, tentare attacchi agli account o richiamare ripetutamente query costose.
Fastly gestione dei bot aiuta a identificare e gestire il traffico automatizzato, così le organizzazioni possono applicare controlli appropriati ai bot indesiderati, preservando al contempo l’accesso per gli utenti legittimi e l’automazione approvata.
Limitazione della velocità
Le funzionalità di limitazione della velocità di Fastly possono aiutare a controllare il traffico eccessivo prima che raggiunga le applicazioni protette. Per gli ambienti GraphQL, la limitazione della velocità all’edge può integrare controlli a livello di applicazione come l’analisi del costo delle query. L’edge può limitare l’attività eccessiva delle richieste, mentre il server GraphQL applica criteri più dettagliati in base al costo effettivo e ai requisiti di autorizzazione di ciascuna operazione.
DDoS Protection
Gli endpoint GraphQL possono diventare bersagli di attacchi DDoS a livello di applicazione, in particolare quando gli hacker identificano query che consumano risorse backend sproporzionate. Fastly DDoS Protection può aiutare a rilevare e mitigare il traffico dannoso ai bordi della rete, riducendo la quantità di traffico di attacco che raggiunge l’infrastruttura dell’applicazione.
Edge delivery e caching
Laddove le risposta GraphQL possono essere memorizzabili nella cache in modo sicuro, le capacità di distribuzione di Fastly possono ridurre le richiesta ripetute all'infrastruttura GraphQL. La memorizzazione nella cache di GraphQL richiede una progettazione attenta perché le risposta possono dipendere da query, variabili, autenticazione e dati specifici dell'utente. Le organizzazioni dovrebbero memorizzare nella cache le risposta solo quando le chiavi e i criteri della cache rappresentano accuratamente tali variazioni.
Se implementata correttamente, la memorizzazione nella cache edge può ridurre le richieste al backend e migliorare le performance API.
Visibilità in tempo reale
Fastly fornisce logging in tempo reale e visibilità sulla sicurezza che possono aiutare i team a indagare su attività API sospette. Per le distribuzioni GraphQL, questo può integrare l’osservabilità a livello di applicazione offrendo ai team di sicurezza e Operazioni visibilità sul traffico prima che raggiunga il servizio GraphQL.
In che modo Fastly si inserisce in una strategia di sicurezza GraphQL?
Fastly è considerato al meglio come un ulteriore livello di sicurezza attorno a un’applicazione GraphQL adeguatamente protetta, non un sostituto della sicurezza all’interno dell’implementazione GraphQL.
L’applicazione dovrebbe continuare a essere responsabile di controlli che includono:
Autenticazione
Autorizzazione a livello di oggetto e di campo
Limiti di profondità della query
Analisi della complessità o del costo delle query
Implementazione sicura del resolver
Validazione dell’input
Gestione sicura degli errori
Criteri di introspezione appropriati
Fastly può integrare questi controlli con Next-Gen WAF, Protezione API, gestione dei bot, limitazione della velocità, DDoS Protection, edge delivery e visibilità in tempo reale.
Insieme, questi livelli possono aiutare le organizzazioni a bloccare le richieste dannose prima che raggiungano l'infrastruttura GraphQL, controllare gli abusi automatizzati, ridurre l'impatto dei picchi di traffico, proteggere le API dagli attacchi alle applicazioni e limitare il consumo non necessario di risorse backend.
Il principio centrale della sicurezza delle API GraphQL è preservare la flessibilità di GraphQL senza dare ai client un controllo illimitato sulle risorse o sui dati dell’applicazione. Combinare una progettazione sicura di GraphQL con la protezione dell’applicazione e delle API basata sull’edge può aiutare le organizzazioni a raggiungere questo equilibrio.