Integrationssikkerhed: API-nøgler, tokens og mindste privilegium

Kort svar: En API-nøgle er et login – behandl den som et kodeord med ekstra rettigheder: én nøgle pr. integration, mindste nødvendige rettighed (læseadgang, hvis der kun skal læses), opbevaring i en kodeords-manager eller i miljøvariabler (aldrig i mails, delte dokumenter eller frontend-kode), rotation ved mistanke og personaleafgang – og en kvartalsvis oprydning, hvor ubrugte nøgler slettes. Lækker en nøgle, så tilbagekald den først og undersøg bagefter.

Fagligt gennemgået: 2. oktober 2026

Jo mere du automatiserer, jo flere nøgler får du: WooCommerce-nøgler til regnskabet, applikationsadgangskoder til n8n, tokens til fragtplatformen og webhook-hemmeligheder på kryds og tværs. Hver af dem kan gøre præcis det, integrationen kan – læse ordrer, ændre priser, oprette indhold – uden at nogen logger ind, og uden at totrinslogin spørger om noget.

Denne guide er disciplinen, der sørger for, at netop dét aldrig bliver dit problem.

Nøgler, tokens og hemmeligheder – kortet

Type	Eksempel	Virker indtil	Særligt at være opmærksom på
API-nøgle	WooCommerce consumer key/secret	Den tilbagekaldes	Rettighed vælges ved oprettelse: læs, skriv eller begge
Applikationsadgangskode	WordPress application password	Den slettes	Arver brugerens rettigheder
Token (typisk OAuth)	Forbindelse til regnskab eller fragt	Udløber og fornys automatisk	Det, der fornyer tokenet, skal beskyttes lige så godt
Webhook-hemmelighed	Signatur på indgående beskeder	Den skiftes	Beviser, at beskeden er ægte

API-nøgler er faste adgangskort. Applikationsadgangskoder i WordPress er samme idé bundet til en bruger – med den fordel, at de kan oprettes og slettes enkeltvis (se WordPress REST API i praksis). Tokens er tidsbegrænsede og derfor sikrere i drift. Webhook-hemmeligheder vender pilen om og beviser, at indgående beskeder er ægte, jf. webhooks forklaret.

Fælles for dem alle: den, der har dem, er integrationen – systemet spørger ikke om andet. Tænk på hver nøgle som en medarbejder, du har ansat uden samtale. Så vil du gerne vide, hvem de er, hvad de må, og hvornår de skal stoppe.

Mindste privilegium i praksis

Tre konkrete vaner:

• Én nøgle pr. integration. Rapporten, regnskabet og fragtplatformen får hver sin. Så kan én tilbagekaldes uden at vælte de andre, og logs viser, hvem der gjorde hvad. Genbrugte nøgler er som fælles kodeord: umulige at rydde op i.
• Læs, når der kun skal læses. WooCommerce-nøgler oprettes med valget læs, skriv eller læs/skriv. Mandagsrapporten skal have læseadgang – så kan en lækket rapportnøgle højst lække data, aldrig ændre priser eller ordrer.
• Dedikerede brugere med små roller. Applikationsadgangskoder arver brugerens rettigheder, så hæng dem på en integrationsbruger med den mindste nødvendige rolle – ikke på administratoren.

Det er samme princip som i adgangsstyring i teams: maskiner er bare medarbejdere, der aldrig går hjem.

Opbevaring: hvor nøgler må bo

Her må nøgler bo:

• I kodeords-managerens delte boks, som ethvert andet kodeord.
• I integrationsplatformens indbyggede lager til credentials. n8n krypterer fx gemte forbindelser med en krypteringsnøgle – pas godt på den, jf. selvhostet n8n på en VPS.
• I miljøvariabler eller konfigurationsfiler uden for webroden på serveren.

Her må nøgler ikke bo:

• I mails og chatbeskeder – de lever videre i arkiver.
• I delte regneark og dokumenter.
• I frontend-kode eller JavaScript – alt, browseren får, er offentligt.
• I versionsstyring. Den klassiske ulykke er en nøgle, der bliver committet til et offentligt repository, hvor automatiske scannere kan finde den hurtigt.

Skal en nøgle deles med en samarbejdspartner, så brug kodeords-managerens delefunktion eller et link, der udløber – aldrig tråden, hvor resten af samtalen bor.

Nøgler i egen kode: konstanter og miljøvariabler

Skriver du selv kode, der kalder en ekstern tjeneste, så hardkod aldrig nøglen i temaet eller pluginet. Læs den fra en miljøvariabel, og definér den i wp-config.php, som ligger uden for versionsstyringen:

// wp-config.php
define( 'FRAGT_API_TOKEN', getenv( 'FRAGT_API_TOKEN' ) );

// I pluginet
$token = defined( 'FRAGT_API_TOKEN' ) ? FRAGT_API_TOKEN : '';

Bruger du en .env-fil, så læg den uden for webroden, og tilføj den til .gitignore. Kontrollér desuden, at kald med nøgler altid sker over HTTPS. WordPress tillader som standard kun applikationsadgangskoder, når sitet kører HTTPS, og det er en god regel for alle integrationer.

Rotation og den kvartalsvise oprydning

Rotér nøgler ved tre anledninger:

• Mistanke – mærkelig aktivitet eller et muligt læk.
• Afgang – en medarbejder eller et bureau med adgang til nøgler stopper.
• Alder for de mest kritiske – årlig rotation af nøgler med skriveadgang til penge og ordrer er billig forsikring.

Sæt et kvarter i kvartalet af til oprydning. Gå listerne igennem: WooCommerce’ REST API-nøgler, brugernes applikationsadgangskoder (WordPress viser, hvornår hver blev brugt sidst) og integrationsplatformens forbindelser. Stil to spørgsmål pr. nøgle: Bruges den stadig? Og ved vi, hvad der bruger den? Alt uden godt svar slettes. En integration, der så fejler, afslører sig selv og får en ny, dokumenteret nøgle.

Før listen i samme dokument som jeres øvrige adgange, jf. adgangsoversigten – én række pr. nøgle med navn, formål, rettighed og ejer.

Når en nøgle lækker

Rækkefølgen er fast, og første skridt er ikke at undersøge:

1. Tilbagekald eller rotér nøglen nu. Hvert minut, den lever, er et minut med åben dør.
2. Opret en ny med samme minimale rettigheder, og opdatér integrationen, så driften kører videre.
3. Undersøg, hvad nøglen kunne, og om logs – ordrer, prisændringer, eksporter, API-kald – viser tegn på misbrug i perioden.
4. Vurdér følgerne. Havde nøglen adgang til persondata, skal hændelsen vurderes som et muligt brud på persondatasikkerheden – med anmeldelse til Datatilsynet, hvis reglerne kræver det.
5. Luk hullet: hvor lå nøglen, siden den lækkede, og hvilken vane skal ændres?

En lækket nøgle, der tilbagekaldes på fem minutter, er en fodnote; en, der får lov at leve en weekend, kan blive en krise. Hastigheden er beredskabet – og den kommer af, at nøglelisten findes, så ingen skal lede efter, hvor man tilbagekalder hvad.

Læs også

• Hub: Automatisering og integrationer
• Adgangsstyring i teams
• WordPress REST API i praksis
• Webhooks forklaret
• WordPress hosting hos Hostious – med gratis SSL, så integrationer kan køre over HTTPS

Ofte stillede spørgsmål om API-nøgler

Hvor mange API-nøgler bør vi have?

Én pr. integration – hverken færre (genbrug ødelægger sporbarhed og oprydning) eller flere (ubrugte nøgler er åbne døre). Antallet skal matche listen over aktive integrationer.

Er læseadgang ufarlig?

Nej. En læsenøgle til ordrer kan lække kundedata, hvilket er en persondatahændelse. Men den kan ikke ændre noget – derfor er læseadgang stadig den rigtige standard, hvor skrivning ikke er nødvendig.

Hvor tit skal nøgler roteres?

Altid ved mistanke og når folk med adgang stopper; årligt for nøgler med skriveadgang til ordrer og priser. Ryd desuden op kvartalsvis – sletning af ubrugte nøgler er rotation, der næsten intet koster.

Må API-nøgler stå i temaets eller pluginets kode?

Nej. Kode bliver kopieret, delt og lagt i versionsstyring. Læs nøglen fra en miljøvariabel eller en konstant i wp-config.php, som holdes uden for versionsstyringen.