# HMAC-SHA256 per la firma dei webhook DLR: come e perché

> HMAC-SHA256 è il primitivo crittografico utilizzato da tutte le moderne piattaforme di messaggistica per firmare i webhook di conferma di ricezione e di ricezione dei messaggi. La piattaforma calcola un hash con chiave sul corpo della richiesta utilizzando un segreto condiviso; il tuo endpoint ricalcola lo stesso hash e lo confronta. Questo dimostra che il webhook proviene dalla piattaforma, e non da qualcuno che ha indovinato il tuo URL, e che il corpo non è stato manomesso durante la trasmissione.

- URL canonico: https://www.broadnet.me/it/answers/hmac-sha256-dlr-signing
- Lingua: it
- Ultima revisione: 2026-09-24
- Editore: BroadNet (https://www.broadnet.me)

## Come viene costruita la firma

Una costruzione comune forma la stringa canonica come `${timestamp}.${requestBody}`, calcola `HMAC-SHA256(canonical, secret)`, la codifica in esadecimale e invia il digest e il timestamp in un header di firma. Includere il timestamp nel payload firmato impedisce gli attacchi di replay: il tuo endpoint dovrebbe rifiutare i webhook più vecchi di 5 minuti. I nomi degli header e il formato canonico esatto variano da piattaforma a piattaforma, quindi verificali con il tuo provider prima di scrivere il codice di verifica.

## Perché le firme HMAC e non quelle RSA?

HMAC è simmetrico, ovvero entrambe le parti condividono un segreto, il che significa che la firma e la verifica sono circa 10.000 volte più veloci di RSA-2048. Per i webhook con un elevato numero di connessioni, dove un singolo SMSC può emettere 50.000 DLR al secondo, la firma RSA sovraccarica la CPU. HMAC-SHA256 su hardware moderno impiega solo pochi microsecondi. Il compromesso: chiunque possieda il segreto può firmare, quindi il segreto va condiviso solo tra la piattaforma e il tuo ambiente, conservato come qualsiasi altra credenziale e ruotabile su richiesta.

## Insidie della verifica

Tre bug comuni. Confrontare stringhe con `==` invece di un confronto a tempo costante (attacco di temporizzazione: utilizzare `crypto.timingSafeEqual`). Convalidare la firma dopo aver analizzato il corpo in formato JSON (è necessario verificare i byte grezzi, non una rappresentazione ri-serializzata: il riordino JSON compromette l'hash). Dimenticare la finestra anti-replay del timestamp.

## Oltre HMAC

Per gli ambienti regolamentati (banche, sanità), alcune piattaforme supportano anche la consegna dei webhook tramite mTLS: il mittente presenta un certificato client che il tuo load balancer convalida prima che la richiesta raggiunga l'applicazione. È più robusto di HMAC perché lega la consegna a una chiave hardware, ma ne giustifica il costo solo per carichi di lavoro davvero sensibili. Per la maggior parte delle integrazioni, HMAC-SHA256 su HTTPS è la risposta giusta.

## Correlati

- [Tutte le risposte](https://www.broadnet.me/it/answers)
- [Glossario](https://www.broadnet.me/it/answers)
- [TLS 1.3 nella messaggistica: cosa è cambiato e perché è importante per SMPP](https://www.broadnet.me/it/answers/tls-1-3-in-messaging)
- [Che cos'è una DLR (ricevuta di consegna)?](https://www.broadnet.me/it/answers/what-is-dlr)
- [Webhook setup](https://www.broadnet.me/it/developers/webhooks)