TL; DR
La maggior parte delle violazioni delle API è riconducibile a problemi di autorizzazione, non a exploit particolari. Tre delle prime cinque categorie della OWASP API Security Top 10 sono errori di autorizzazione, guidati da BOLA.
Non puoi proteggere ciò di cui non sai che esiste. Gestione impropria delle scorte è una categoria di rischio OWASP a sé stante, ed è il fondamento su cui si basano tutti gli altri controlli.
Individuare il rischio prima dell'implementazione, non dopo. L'analisi statica del codice e delle specifiche API rileva un endpoint non funzionante in un pull request, al costo di uno commitI test in fase di esecuzione rilevano lo stesso problema in ambiente di produzione, al costo di un incidente.
Si tratta di una lista di controllo da eseguire in modo continuativo. Su ogni pull request, non una recensione pre-lancio: 10 pratichedall'inventario e dall'autorizzazione alla limitazione della frequenza, all'esposizione dei dati di risposta e alla fiducia in terze parti.
La superficie di attacco della tua API cresce con ogni pull request. La maggior parte dei team scopre che un endpoint è esposto solo quando è attivo e riceve traffico, il che significa che la correzione che sarebbe costata una commit In fase di revisione, ora è necessario un rapporto di incidente. Questa guida illustra le migliori pratiche di sicurezza delle API che si dimostrano effettivamente valide in produzione, organizzate come una checklist che puoi applicare oggi stesso al tuo codice, non come un elenco di principi astratti che nessuno implementa.
Perché le migliori pratiche per la sicurezza delle API sono cambiate
Un tempo le API rappresentavano il tessuto connettivo tra i sistemi. Ora sono diventate l'interfaccia principale per quasi tutto: app per dispositivi mobili, integrazioni con partner, agenti di intelligenza artificiale, microservizi interni. Questo cambiamento ha modificato le best practice per la protezione delle API. Non è più sufficiente proteggere le API documentate; bisogna tenere conto anche di quelle create dai team e dimenticate di documentare.
Due numeri spiegano perché questo è importante. Sicurezza dell'API OWASP Top 10 Il sistema inserisce i problemi di autorizzazione non corretti in tre delle sue cinque categorie principali, il che significa che la maggior parte degli incidenti API reali sono riconducibili a una manciata di schemi prevenibili, non a vulnerabilità zero-day particolari. Anche la gestione impropria dell'inventario rientra nella stessa lista, con una categoria di rischio specifica: i team subiscono violazioni tramite API di cui ignoravano l'esistenza.
Questo è il filo conduttore di ogni elemento qui di seguito. Le migliori pratiche per una gestione efficace delle API iniziano con la consapevolezza di ciò che si possiede, non solo con la difesa di ciò che ci si è ricordati di documentare.
Panoramica sulle migliori pratiche di sicurezza delle API
Prima di passare alla lista di controllo dettagliata, ecco una breve sintesi: cosa implementare, da cosa protegge effettivamente e con quale urgenza.
Considera la riga “Obbligatorio” come la base non negoziabile per qualsiasi API, interna o rivolta al pubblico. Gli elementi ad “Alta” priorità sono ciò che distingue un programma che individua i problemi in un pull request da qualcuno che lo scopre in un rapporto sull'incidente.
Lista di controllo delle migliori pratiche per la sicurezza delle API
1. Crea un inventario completo prima di costruire una difesa
Non è possibile proteggere un endpoint di cui non si conosce l'esistenza. Ogni iniziativa per la protezione delle API dovrebbe iniziare con un inventario completo: ogni endpoint, il suo metodo, il suo percorso, il servizio e il modulo a cui appartiene e se richiede autenticazione. Queste informazioni devono essere ricavate sia dal codice sorgente che dalle specifiche API (OpenAPI, Swagger), non solo dalla documentazione, perché è proprio in questo divario che si nascondono gli endpoint dimenticati e orfani.
Dove si colloca Xygeni: Sicurezza dell'API Xygeni Questo strumento crea l'inventario direttamente dal codice sorgente dell'applicazione e dalle specifiche API, evidenziando sia gli endpoint documentati dal team che quelli non documentati, prima ancora che vengano messi in produzione.
2. Applicare l'autorizzazione a livello di oggetto e di funzione
Le vulnerabilità di autorizzazione a livello di oggetto e di funzione sono costantemente in cima alla OWASP API Security Top 10. La best practice non è "aggiungere l'autenticazione", ma verificare, per ogni richiesta, se questo utente specifico è autorizzato ad accedere questo oggetto specificoNon si tratta solo di verificare se l'utente ha effettuato l'accesso. L'autenticazione definisce chi è una persona. L'autorizzazione definisce a cosa può accedere e deve essere verificata ogni volta, non presupposta da un token valido.
3. Convalidare e sanificare tutto ciò che l'API riceve
Ogni parametro, intestazione e campo del corpo della richiesta è considerato input non attendibile fino a prova contraria. Applica una rigorosa convalida dello schema, rifiuta i campi imprevisti (questa è la tua difesa contro l'assegnazione di massa) e non fidarti mai dei dati forniti dal cliente per determinare l'ambito di accesso o la logica di prezzo.
4. Limitare la velocità e la portata fin dalla fase di progettazione, non come ripensamento successivo.
Il consumo illimitato di risorse consente a un singolo client di esaurire l'infrastruttura o di accumulare costi elevati per i servizi di backend a pagamento. Imposta dei limiti per endpoint, per utente e per chiave API, e assicurati che i limiti siano proporzionali al costo effettivo dell'operazione, non a un valore fisso applicato ovunque.
5. Considera ogni risposta come una potenziale fuga di dati
L'eccessiva esposizione dei dati si verifica quando un'API restituisce più informazioni di quelle necessarie al client e si affida al frontend per filtrarle. Questa è un'abitudine, non un errore raro, ed è una delle violazioni più comuni delle best practice per la protezione delle API, perché è invisibile finché qualcuno non esamina le risposte grezze invece dell'interfaccia utente renderizzata.
Dove si colloca Xygeni: Xygeni API Security segnala l'esposizione di dati personali direttamente nelle risposte API, individuando la condivisione eccessiva prima che venga inviata, anziché dopo che un cliente o un'autorità di regolamentazione se ne accorgono.
6. Mantenere un inventario API accurato e aggiornato, comprese quelle obsolete.
Improprio inventario La gestione delle API costituisce una categoria a sé stante nella lista OWASP per un motivo ben preciso: le versioni obsolete delle API e gli ambienti di staging non documentati sono spesso ancora raggiungibili e vulnerabili, anche molto tempo dopo che qualcuno si ricorda della loro esistenza. Un programma di best practice per la gestione delle API deve includere la dismissione, non solo la loro individuazione.
7. Esamina attentamente di cosa si fida la tua API da parte di terzi
L'utilizzo non sicuro di API di terze parti è un rischio sottovalutato. Gli sviluppatori tendono a fidarsi maggiormente dei dati provenienti da API esterne rispetto all'input dell'utente, il che è esattamente il contrario: un'integrazione di terze parti rimane pur sempre una fonte esterna e non verificata e dovrebbe essere validata allo stesso modo.
8. Presentate agli sviluppatori prove concrete, non solo avvisi.
Un problema che indica "autorizzazione non valida su questo endpoint" è un ticket che deve essere esaminato prima ancora di poter iniziare a risolverlo. Un problema che indica il file, la classe, il metodo e la riga esatti è qualcosa su cui uno sviluppatore può intervenire immediatamente. Questa è una best practice per il programma di sicurezza nel suo complesso, non solo per l'API: i problemi che richiedono un'indagine preliminare prima della risoluzione rallentano tutto.
Dove si colloca Xygeni: Ogni rilevamento di sicurezza dell'API di Xygeni indica con precisione il gestore, il file, la classe, il metodo e la riga che lo hanno introdotto, quindi la correzione inizia nel momento stesso in cui viene rilevato.
9. Individuare l'esposizione prima dell'implementazione, non dopo
Il test API in fase di esecuzione ti dice che un endpoint è esposto quando sta già gestendo il traffico. L'analisi statica del codice e delle specifiche API rileva la stessa esposizione mentre è ancora in esecuzione. pull request, quando la riparazione costa uno commit anziché una risposta a un incidente. Le migliori pratiche di gestione delle API considerano la scoperta statica come primo livello, con i test in fase di esecuzione come secondo controllo complementare su ciò che è già in produzione.
Dove si colloca Xygeni: Xygeni API Security è statico per impostazione predefinita, analizza il codice e le specifiche prima del rilascio e funziona insieme Xygeni DAST per la copertura in fase di esecuzione di applicazioni già in produzione.
10. Mantieni il rischio API nello stesso posto in cui si trova il resto del rischio dell'applicazione
Le API non falliscono in isolamento. Una vulnerabilità dell'API spesso si trova a valle di un problema di dipendenza, una configurazione errata pipelineo un segreto trapelato. Trattare la sicurezza delle API come uno strumento separato con una propria console significa perdere quel contesto proprio quando è più importante.
Dove si colloca Xygeni: La sicurezza API si affianca SAST, SCA, Segreti, IaCe DAST in un'unica piattaforma Xygeni, in modo che un risultato API sia visibile accanto al codice e al rischio di dipendenza che lo ha prodotto, non in un separato login.
Trasformare la lista di controllo in un'abitudine
Le migliori pratiche di sicurezza delle API funzionano solo come pratica continua, non come revisione pre-lancio. Esegui l'inventario e l'analisi statica su ogni pull request, non una volta al trimestre. Tratta un nuovo endpoint non documentato allo stesso modo in cui tratteresti una nuova dipendenza non documentata: come qualcosa da esaminare immediatamente, non in un secondo momento. E misura le tue best practice di protezione API allo stesso modo in cui misuri qualsiasi altra parte del SDLC, da quanto precocemente si individua il problema, non solo dal fatto di averlo individuato o meno.
Risposte rapide: Domande e risposte sulle migliori pratiche di sicurezza delle API
Punti chiave
- Prima viene la difesa, poi l'inventario. Non è possibile applicare autorizzazioni, limiti di frequenza o controlli sui dati a un endpoint di cui non si conosce l'esistenza, e una gestione impropria dell'inventario è un rischio specifico incluso nella OWASP API Security Top 10.
- La maggior parte delle violazioni si verifica nell'ambito dell'autorizzazione, non solo dell'autenticazione. Tre dei cinque principali rischi per la sicurezza delle API secondo OWASP riguardano le violazioni delle autorizzazioni. Verificare l'identità di una persona non è la stessa cosa che verificare a cosa è autorizzata ad accedere.
- L'analisi statica individua ciò che i test in fase di esecuzione rilevano troppo tardi. Trovare esposizione in un pull request costa uno commitRiscontrare questo problema in fase di produzione comporta un incidente.
- Ogni risposta rappresenta una potenziale fuga di dati. L'eccessiva esposizione dei dati è un'abitudine, non un errore raro, ed è invisibile finché qualcuno non esamina le risposte API grezze invece dell'interfaccia utente renderizzata.
- Le migliori pratiche di sicurezza delle API funzionano solo se applicate con costanza., eseguito su ogni pull request, non una revisione trimestrale o una lista di controllo pre-lancio.
- La gestione del rischio delle API non dovrebbe essere affidata a uno strumento separato. Le best practice più utili per la protezione delle API considerano i risultati delle API come parte dello stesso quadro di rischio del codice, delle dipendenze e pipeline securitynon una console isolata.
FAQ
Quali sono le best practice più importanti per la sicurezza delle API da cui iniziare?
Iniziate dall'inventario. Non è possibile applicare controlli di autorizzazione, limiti di frequenza o controlli di esposizione dei dati a un endpoint di cui non si conosce l'esistenza, quindi un inventario completo e accurato di ogni endpoint API è la base su cui si fonda tutto il resto di questa checklist.
Qual è la differenza tra le migliori pratiche di sicurezza delle API e le migliori pratiche di sicurezza generali delle applicazioni?
Le API introducono rischi che le pratiche generali di sicurezza delle applicazioni non coprono completamente: l'autorizzazione a livello di oggetto e di funzione su larga scala, il pericolo specifico di fidarsi delle risposte delle API di terze parti e la difficoltà di tracciare endpoint obsoleti o non documentati. Le migliori pratiche di sicurezza delle API sono le migliori pratiche di sicurezza delle applicazioni, applicate alle parti della superficie di attacco che sono più facili da trascurare.
I test di sicurezza delle API dovrebbero essere eseguiti prima o dopo la distribuzione?
Entrambi, ma il punto di leva più alto è prima. L'analisi statica del codice e delle specifiche API individua l'esposizione mentre è ancora pull requestI test in fase di esecuzione (DAST) verificano quindi cosa sia effettivamente raggiungibile una volta che l'applicazione è in produzione. Affidarsi esclusivamente ai test in fase di esecuzione significa che ogni correzione costa più del necessario.
Con quale frequenza è necessario aggiornare l'inventario delle API?
Continuamente, idealmente su ogni pull requestUn inventario creato una sola volta e rivisto trimestralmente è già obsoleto nel momento stesso in cui viene rilasciato un nuovo prodotto, ed è proprio questa lacuna che una gestione inadeguata dell'inventario sfrutta.
Le migliori pratiche di gestione delle API si applicano anche alle API interne, non solo a quelle accessibili al pubblico?
Sì. Le API interne sono spesso soggette a standard di sicurezza inferiori perché "non sono esposte a Internet", ma gestiscono comunque dati sensibili e sono accessibili a chiunque abbia accesso alla rete interna, inclusi account compromessi o dipendenti.
