Guida alla messa in sicurezza delle chiamate API in un ambiente WordPress

Introduzione: due direzioni, due problemi distinti

Si parla di «sicurezza della API» come se fosse un unico argomento. Sono due, e confonderli è la causa della maggior parte degli errori:

IN ENTRATA : ciò che il mondo può chiedere al suo WordPress → API REST, webhook
IN USCITA  : ciò che il suo WordPress chiede al mondo       → chiavi, fornitori, IA

L'entrata è un problema di permessi: chi può chiedere che cosa. L'uscita è un problema di segreti: dove vive la chiave e chi può leggerla. Questo articolo tratta entrambi, cominciando da quello più trascurato.

1. In uscita — dove vive la chiave

È il punto che annulla tutto il resto se lo si sbaglia.

Mai in un file versionato. Una chiave in un repository resta nella cronologia anche se la si cancella dopo. La revoca è l'unica soluzione reale: cambiare il file non basta.

Mai nel codice di un tema. Un tema si copia, si condivide, si distribuisce in preproduzione, si invia a un fornitore.

Mai in JavaScript lato client. Una chiave che arriva nel browser è una chiave pubblica. Questo errore è più frequente di quanto sembri proprio perché «funziona» perfettamente.

In una variabile d'ambiente del server, o nel deposito dei segreti del suo hosting. E con una regola organizzativa che vale quanto quella tecnica: una chiave per cliente e per uso. Una chiave condivisa rende impossibile ogni attribuzione, e uno sforamento diventa anonimo.

Quest'ultimo punto è anche ciò che rende leggibile il budget — il ragionamento completo è in ottimizzare il budget della sua agenzia con una chiave API personale.

2. In uscita — che cosa verificare a ogni chiamata

• Un tempo di attesa esplicito. Senza, un fornitore lento blocca la sua pagina. È la causa più comune di «il sito è caduto» quando in realtà stava aspettando una risposta.
• Un tetto di spesa presso il fornitore, per chiave. È una garanzia strutturale: tiene anche se un trattamento automatico entra in ciclo. Nessun impegno contrattuale offre questo, perché agisce a posteriori.
• Un limite di frequenza dalla sua parte, perché un ciclo mal chiuso costi un incidente e non un mese di budget.
• Nessun dato inutile inviato. Il meglio protetto è quello che non è uscito: se il trattamento ha bisogno solo del testo di un prodotto, non ha bisogno del nome del cliente. È il principio sviluppato in perché la riservatezza dei dati è la sua migliore alleata.
• Nessun segreto nei registri. Un messaggio di errore che riversa la richiesta completa scrive la sua chiave in un file che si conserva e talvolta si invia a terzi.

3. In entrata — la API REST e ciò che espone per impostazione predefinita

WordPress espone una API REST attiva per impostazione predefinita. Non è un difetto, ma conviene sapere tre cose:

1. Alcune rotte sono pubbliche per scelta progettuale, e qualcuna rivela l'elenco degli autori del sito, cioè nomi di account utilizzabili per un attacco alle password. Limitare quella rotta costa poche righe.
2. Ogni plugin può aggiungere le proprie rotte. La sua superficie in entrata cresce a ogni installazione, senza che nessuno la guardi. È un argomento in più per verificare i propri plugin.
3. Una rotta personalizzata senza verifica delle capacità è aperta a tutti. È l'errore classico del plugin scritto su misura: si controlla il nonce, si dimentica la capacità. Il nonce dimostra l'origine della richiesta, non il diritto di eseguirla. Servono entrambi.

4. In entrata — i webhook

Un webhook è un URL pubblico che esegue codice. Tre regole, e nessuna è facoltativa:

• verificare la firma inviata dall'emittente, sistematicamente. Senza verifica, chiunque conosca l'URL può innescare il trattamento;
• rendere il trattamento idempotente: lo stesso evento ricevuto due volte non deve produrre due effetti. I fornitori rinviano, è normale;
• rispondere in fretta e lavorare dopo. Un webhook che esegue un trattamento lungo prima di rispondere provoca rinvii, e i rinvii provocano duplicati.

5. I cinque errori che si trovano ovunque

1. La chiave lato client — funziona, ed è pubblica.
2. Il nonce senza la capacità — si controlla l'origine, non il diritto.
3. La chiave condivisa fra clienti — attribuzione impossibile, revoca impossibile senza toccare tutti.
4. Nessun tempo di attesa — il guasto del fornitore diventa il suo.
5. Il segreto nei registri — scritto una volta, conservato per mesi.

6. Il protocollo, in una pagina

• Nessuna chiave in un repository versionato, in un tema o in JavaScript lato client
• Una chiave per cliente e per uso, in variabile d'ambiente o nel deposito dei segreti
• Tetto di spesa fissato presso il fornitore, per chiave, con avviso intermedio
• Tempo di attesa esplicito su ogni chiamata in uscita
• Limite di frequenza sui trattamenti automatici
• Rotte REST personalizzate: nonce e verifica delle capacità, senza eccezioni
• Webhook: firma verificata, trattamento idempotente, risposta rapida
• Registri riletti: nessun segreto, nessuna richiesta completa riversata
• Procedura di revoca scritta — e collaudata una volta, non supposta

L'ultimo punto è quello che nessuno fa ed è l'unico che conta il giorno in cui serve.

Conclusione

La sicurezza delle chiamate API non poggia su uno strumento ma su due domande a cui bisogna saper rispondere in qualsiasi momento: dove vivono le mie chiavi, e chi può leggerle? e che cosa può chiedermi il mondo senza identificarsi?

La maggior parte degli incidenti non nasce da un attacco sofisticato, ma da una chiave che stava dove non doveva e da una rotta che non verificava ciò che credeva di verificare.

La prova: se dovesse revocare tutte le sue chiavi stasera, saprebbe dove sono e quanto tempo ci vorrebbe? Se non può rispondere, quello è il lavoro da fare per primo.

Per continuare: l'irrobustimento avanzato di WordPress, la protezione proattiva contro le minacce zero-day e l'approccio GDPR+ e l'architettura a chiave API personale. Le nostre estensioni premium sono disponibili con rimborso integrale entro 14 giorni: vedere il catalogo.