Webhook in ingresso: domande di sicurezza per applicazioni self-hosted

Mappa ogni webhook in ingresso

Prima di attivare un webhook, raccogli le informazioni necessarie per capire chi può inviare richieste, che cosa accetta l’endpoint e quali azioni potrebbe avviare l’applicazione. Questa mappa è un punto di partenza per le verifiche, non una garanzia di sicurezza.

Esamina ogni integrazione separatamente: mittente, tipi di evento, dati e conseguenze possono variare da un endpoint all’altro.

• Quale servizio esterno dovrebbe inviare le richieste e come viene identificato?
• Qual è l’URL esatto e a quale istanza e ambiente appartiene?
• Quali tipi di evento prevede di inviare l’integrazione e quali intendi accettare?
• Quali dati possono comparire nei payload, inclusi eventuali dati personali o informazioni aziendali sensibili?
• Quali modifiche, messaggi o altre azioni può attivare ciascun evento?

Verifica l’autenticazione del mittente

Consulta la documentazione della versione dell’applicazione in uso e dell’integrazione specifica. Cerca il metodo previsto per verificare il mittente e come vengono trattate le richieste che non superano il controllo.

Non dedurre l’autenticazione dalla sola presenza di un URL difficile da indovinare o dalla configurazione di un certificato TLS. Se le istruzioni non chiariscono come vengono verificate le richieste in ingresso, considera la questione non risolta e chiedi chiarimenti al fornitore o a chi gestisce l’integrazione.

• La documentazione descrive un metodo di verifica del mittente, per esempio una firma o una credenziale?
• Spiega che cosa viene verificato in relazione alla richiesta o all’evento?
• Specifica che cosa accade quando le credenziali sono assenti o non valide?
• La funzionalità documentata è disponibile nella versione installata e attiva nella configurazione effettiva?
• Se il controllo è affidato a un proxy o a un livello di integrazione, chi ne gestisce la configurazione?

Esamina i payload e gli eventi accettati

Verifica se la documentazione dell’integrazione descrive i controlli eseguiti sul contenuto delle richieste, compresa la gestione di struttura, tipi, dimensioni e valori prima che l’applicazione intervenga.

Accertati che gli eventi accettati e le azioni associate siano espliciti. Non presumere che l’applicazione rifiuti automaticamente eventi o campi sconosciuti: cerca conferma nella documentazione o verifica il comportamento in un ambiente adatto.

• Sono descritti i campi richiesti e i formati attesi per ciascun tipo di evento?
• È documentato come vengono trattate richieste malformate, incomplete o di dimensioni inattese?
• Come vengono verificati gli identificativi e i record a cui fa riferimento il payload?
• È possibile limitare l’integrazione ai soli tipi di evento necessari?
• Quali componenti analizzano il payload e quali possono avviare azioni conseguenti?

Chiarisci la gestione delle richieste ripetute

Verifica se la documentazione del mittente e del destinatario descrive timestamp, identificativi degli eventi o altri meccanismi relativi alle richieste ripetute. La disponibilità e il comportamento di questi controlli dipendono dalla specifica integrazione.

Chiediti che cosa accade se lo stesso evento viene ricevuto più di una volta e se tale comportamento è accettabile per le azioni coinvolte. Una richiesta autenticata non è automaticamente immune da elaborazioni duplicate.

• Se sono previsti timestamp, è documentata una regola per valutarne la validità?
• Se sono forniti identificativi degli eventi, il sistema li registra e per quanto tempo?
• Come vengono trattati ritardi nella consegna, differenze tra gli orologi e richieste ripetute?
• Una seconda elaborazione potrebbe creare record o messaggi duplicati o produrre altri effetti indesiderati?
• Se l’applicazione non gestisce questi casi, è documentato un modo per farlo in un altro livello?

Esamina i permessi e le azioni dell’integrazione

Ricostruisci il percorso dalla richiesta all’azione, compresi gli account, i token e i servizi collegati. Verifica i permessi effettivamente usati e se corrispondono alle operazioni necessarie.

Usa la documentazione e la configurazione per individuare le azioni associate a ciascun evento e le conseguenze di un evento inatteso o di una credenziale compromessa.

• È possibile usare un’identità o una credenziale dedicata all’integrazione?
• Quali permessi e dati sono accessibili a tale identità?
• A quali azioni corrisponde ciascun evento accettato?
• Quali conseguenze avrebbe un errore di configurazione o l’uso improprio di una credenziale?
• L’endpoint deve essere raggiungibile pubblicamente? Quali restrizioni sono effettivamente disponibili nella distribuzione?

Verifica la conservazione e la rotazione dei segreti

Individua dove vengono conservate le chiavi di firma, le credenziali o gli eventuali segreti condivisi dell’integrazione. Verifica chi può accedervi e se possono apparire in esportazioni di configurazione, materiali di assistenza o output diagnostici.

Consulta le istruzioni del provider e dell’applicazione per capire se e come si possono sostituire le credenziali. Chiarisci il coordinamento necessario tra i sistemi coinvolti e come verificare che la nuova configurazione funzioni.

• Dove è documentato che debbano essere conservati i segreti e chi può leggerli o modificarli?
• Sono presenti in codice sorgente, documentazione pubblica o note di assistenza?
• È possibile associare ciascun segreto all’integrazione che lo utilizza?
• La procedura di rotazione è descritta e, se necessario, può essere provata in un ambiente sicuro?
• Come si verifica che le credenziali obsolete non siano più utilizzate o accettate?

Esamina i log e la conservazione dei dati

Controlla la documentazione e la configurazione dei log dell’applicazione e dei componenti circostanti. Verifica se registrano payload, header o altri valori che potrebbero contenere dati sensibili o credenziali.

Chiarisci chi può accedere ai log, per quanto tempo vengono conservati e come vengono gestite eventuali copie esportate o di backup. Impostazioni e comportamento possono variare tra applicazioni e distribuzioni.

• I log includono corpi delle richieste, header di autorizzazione, firme o stringhe di query?
• Quali dettagli diagnostici sono disponibili senza registrare l’intero payload?
• Chi può consultare i log dell’applicazione, del proxy e dell’integrazione?
• Quali regole di conservazione ed eliminazione si applicano ai dati registrati?
• I messaggi di errore possono mostrare segreti o contenuti del payload a utenti o chiamanti esterni?

Attribuisci ogni controllo al componente che lo applica

Per ogni controllo, annota quale componente ne è responsabile: applicazione, provider esterno, proxy, livello di integrazione o procedura amministrativa. La ripartizione dipende dall’architettura specifica; non presumere che un livello applichi i controlli di un altro.

Per consultare fonti primarie generali, puoi partire da [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) e dal [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework). Per i componenti dell’infrastruttura, sono disponibili la [documentazione Docker](https://docs.docker.com/), la [documentazione Traefik](https://doc.traefik.io/traefik/) e la [documentazione Let’s Encrypt](https://letsencrypt.org/docs/). Sono riferimenti da consultare, non attestazioni che una specifica applicazione implementi determinati controlli webhook: per questi, verifica la documentazione dell’app e dell’integrazione.

Airbip dichiara che le istanze applicative vengono eseguite come carichi di lavoro Docker sui server cloud Airbip e che l’instradamento e i certificati TLS sono automatizzati tramite Traefik e Let’s Encrypt. Queste funzionalità di hosting non attestano come una particolare applicazione gestisca autenticazione dei mittenti, richieste ripetute, payload o permessi.

• Quale componente applica ciascun controllo e chi ne configura il comportamento?
• È documentato che cosa accade quando un controllo fallisce?
• Chi può modificare l’esposizione dell’endpoint, le credenziali e le azioni consentite?
• Se un controllo rilevante resta da verificare, quali chiarimenti o verifiche aggiuntive sono possibili prima di attivare l’integrazione?