🌐 DA

🔑 API-nøglegenerator

Generer sikre tilfældige API-nøgler. Brug til REST API, autentificeringstokens og hemmelige nøgler.

API-nøgleformat
GUIDE

Laes mere

01

1. Vigtigheden af API-nøglesikkerhed

API-nøgler er afgørende sikkerhedselementer til applikationsautentificering. Svage nøgler er sårbare over for brute force-angreb, og eksponering fører til uautoriseret API-adgang. Stærke API-nøgler bør være mindst 32 tegn lange tilfældige strenge og bruge kryptografisk sikre pseudo-random number generators (CSPRNG). UUID v4, Base64 og Hex er udbredte formater, hvor hver nøgle er unik og uforudsigelig. Tilbagekald og erstat straks eksponerede nøgler, og commit dem aldrig til offentlige repositories som GitHub.

02

2. Sammenligning af metoder til nøglegenerering

Der findes flere metoder til generering af API-nøgler. UUID v4 bruger 122 tilfældige bits med ekstremt lav sandsynlighed for kollision og er bredt anvendt. Base64 koder binære data til tekst og giver cirka 192 bits entropi i 32 tegn. Hex repræsenterer data i hexadecimal form med høj læsbarhed og giver 256-bit sikkerhed i 64 tegn. Alfanumerisk bruger kun bogstaver og tal for URL-sikkerhed, og præfikser (sk_, api_) gør nøgletype nem at genkende. Stripe, AWS og OpenAI bruger forskellige nøgleformater til at skelne mellem tjenestespecifikke nøgler.

03

3. UUID vs tilfældige strenge

UUID v4 er en standardiseret 128-bit identifikator, der sikrer global entydighed. Formatet 8-4-4-4-12 (f.eks. 550e8400-e29b-41d4-a716-446655440000) har en tydelig struktur, der følger RFC 4122-standarden. Brugerdefinerede tilfældige strenge giver fleksibilitet i længde og format. Mens UUID'er egner sig til primære databasekeys, er tilfældige strenge mere kompakte og praktiske til API-nøgler. Sikkerheden er omtrent den samme, men tilfældige strenge gør valideringslogik med præfikser og checksummer lettere at implementere.

04

4. Anbefalinger til lagring af nøgler

Gem aldrig API-nøgler i klar tekst. Gem dem i miljøvariabler (.env) og tilføj dem til .gitignore for at udelukke dem fra versionsstyring. I produktion bør du bruge dedikerede secrets management-systemer som AWS Secrets Manager, HashiCorp Vault eller Azure Key Vault. Ved lagring i databaser bør du konvertere til hashes (SHA-256) og anvende kryptering (AES-256), når det er nødvendigt. Undgå at hardcode nøgler i koden; brug Docker secrets eller Kubernetes Secrets. Maskér nøgler i logs for at forhindre eksponering, og overvåg nøglebrugs-historik.

05

5. Politikker for nøglerotation

API-nøgler bør roteres regelmæssigt. Rotation hver 90. dag er almindelig praksis; tilbagekald straks, hvis der er mistanke om eksponering. Ved rotation uden nedetid aktiveres to nøgler samtidigt, skift til den nye nøgle, og deaktiver derefter den gamle. AWS IAM og Google Cloud API Keys tilbyder automatiske rotationsfunktioner. Sæt udløbsdatoer for hver nøgle, så gamle nøgler automatisk bliver ugyldige, og registrer rotationshistorik i audit logs. Brug af tokenbaseret autentificering som OAuth 2.0 eller JWT i stedet for API-nøgler giver bedre sikkerhed med automatisk udløb.

06

6. Rate limiting og brugsbegrænsninger

Anvend altid rate limiting på API-nøgler for at forhindre misbrug. Sæt grænser som 100 anmodninger pr. minut pr. IP eller 1.000 pr. time pr. nøgle. Implementer kvoter for maksimale daglige kald og returnér 429 Too Many Requests, når grænsen overskrides. Konfigurer IP-whitelists, så nøglebrug kun er tilladt fra bestemte IP-adresser, og registrér unormale mønstre (mange anmodninger på kort tid) til automatisk blokering. API-gateways som Cloudflare, Kong og AWS API Gateway gør implementering af rate limiting enklere. Sæt nøglespecifikke tilladelser (Scopes) for at begrænse adgang til f.eks. kun læsning eller kun skrivning.

Ofte stillede sporgsmal

Sendes genererede nøgler til en server?
Nej. Alle nøgler genereres kun i din browser og sendes aldrig til en server, så de er sikre at bruge.
Hvilket format skal jeg vælge?
UUID v4 er bredt anvendt på grund af den lave kollisionssandsynlighed. Vælg Alfanumerisk for URL-sikkerhed eller Hex for bedre læsbarhed.