En webhook uden signatur er en \u00e5ben d\u00f8r. Enhver, der kender din URL, kan sende en falsk betaling, en falsk ordre eller en falsk “konto slettet”-besked, og din server vil behandle den som \u00e6gte. HMAC (Hash-based Message Authentication Code) lukker den d\u00f8r. Med en delt hemmelig n\u00f8gle og en hashfunktion kan du bevise to ting p\u00e5 \u00e9n gang: at beskeden kommer fra den rette afsender, og at ingen har \u00e6ndret et eneste byte undervejs.<\/p>\n\n\n\n
Denne tutorial bygger en komplet, k\u00f8rende HMAC-l\u00f8sning i Node.js fra bunden i 12 trin. Du l\u00e6rer at generere en st\u00e6rk n\u00f8gle, beregne en HMAC med HMAC er en n\u00f8glebaseret beskedautentificeringskode. Den kombinerer en kryptografisk hashfunktion, for eksempel SHA-256, med en hemmelig n\u00f8gle, som kun afsender og modtager kender. Resultatet er en kort streng bytes, en MAC, der f\u00f8lger med beskeden. Modtageren beregner sin egen MAC over den modtagne besked med samme n\u00f8gle. Hvis de to MAC’er er identiske, ved modtageren, at beskeden er autentisk og u\u00e6ndret. Standarden er defineret i RFC 2104 og i NIST’s FIPS 198-1, og den er en af de mest udbredte byggeklodser i moderne API-sikkerhed.<\/p>\n\n\n\n Bem\u00e6rk en vigtig skelnen: HMAC er ikke kryptering. Den skjuler ikke indholdet af din besked. Den giver integritet og autenticitet, ikke fortrolighed. Vil du b\u00e5de skjule og autentificere data, kombinerer du HMAC med kryptering, eller du bruger en AEAD-ordning som AES-GCM. HMAC l\u00f8ser et andet, men lige s\u00e5 kritisk problem: “kan jeg stole p\u00e5, at denne besked virkelig kom fra den, jeg tror, og at den ikke er pillet ved?”<\/p>\n\n\n\n Du m\u00f8der HMAC overalt, selvom du ikke altid l\u00e6gger m\u00e6rke til det. Stripe, GitHub, Shopify og Slack signerer alle deres webhooks med HMAC-SHA256. AWS bruger HMAC i Signature Version 4 til at signere API-kald. JSON Web Tokens med algoritmen HS256 er reelt en HMAC-SHA256 over header og payload. N\u00e5r du forst\u00e5r m\u00f8nsteret i denne tutorial, kan du verificere alle disse signaturer korrekt, og du undg\u00e5r de timingfejl, der g\u00f8r mange hjemmelavede implementeringer usikre.<\/p>\n\n\n\n Hvorfor ikke bare en almindelig hash? Fordi en almindelig SHA-256 ikke har nogen n\u00f8gle. Enhver, der kan \u00e6ndre beskeden, kan beregne en ny gyldig hash og sende den med. HMAC’s hemmelige n\u00f8gle er det, der g\u00f8r forfalskning umulig uden adgang til n\u00f8glen. Forskellen mellem en hash og en HMAC er n\u00f8glen, og den forskel er hele pointen.<\/p>\n\n\n\n Du beh\u00f8ver meget lidt for at f\u00f8lge med, fordi alt det kryptografiske kommer fra Node.js’ kerne. S\u00f8rg for at have f\u00f8lgende p\u00e5 plads, f\u00f8r du g\u00e5r i gang.<\/p>\n\n\n\n Det indbyggede crypto.createHmac<\/code>, verificere den i konstant tid med crypto.timingSafeEqual<\/code>, og bygge en Express-server, der signerer udg\u00e5ende webhooks og afviser forfalskede indg\u00e5ende. Du f\u00e5r ogs\u00e5 6 faldgruber, 8 fejlfindingspunkter, avancerede tips og et fuldt projekt, du kan kopiere direkte. Alt er testet p\u00e5 Node.js 22 LTS og bruger udelukkende det indbyggede crypto<\/code>-modul, s\u00e5 du skal ikke installere et eneste kryptobibliotek.<\/p>\n\n\n\nHvad er HMAC, og hvorfor bruge det?<\/h2>\n\n\n\n
Foruds\u00e6tninger og versioner<\/h2>\n\n\n\n
\n
node --version<\/code>. K\u00f8rer du noget \u00e6ldre, s\u00e5 opgrader, da gamle udgaver mangler sikkerhedsrettelser i crypto<\/code>.<\/li>\nnpm --version<\/code>.<\/li>\ncrypto<\/code>-modul leverer hele HMAC-funktionaliteten. Du importerer det med const crypto = require('node:crypto')<\/code> eller, hvis du bruger ES-moduler, import crypto from 'node:crypto'<\/code>. Pr\u00e6fikset node:<\/code> er den anbefalede m\u00e5de at importere kernemoduler p\u00e5, fordi det g\u00f8r det tydeligt, at modulet kommer fra runtime og ikke fra en npm-pakke.<\/p>\n\n\n\n