wp-config-hærdning: saltnøgler, file edit og debug

Kort svar: wp-config.php er sitets nøglering, og fire greb hærder den mærkbart: friske, unikke saltnøgler (gør stjålne login-cookies ubrugelige), DISALLOW_FILE_EDIT (fjerner kode-editoren i wp-admin, så en kapret admin-konto ikke kan plante kode med ét klik), debug-visning slukket på live (WP_DEBUG_DISPLAY sat til false – log i stedet, og helst uden for webroden) og stramme filrettigheder på selve filen. Det tager typisk 10–20 minutter og skal kun gøres én gang pr. site.

Fagligt gennemgået: 2. oktober 2026

wp-config.php indeholder databaseadgangen, sikkerhedsnøglerne og sitets grundindstillinger. Alligevel står filen på de fleste sites præcis, som installationen efterlod den – eller som en tidligere udvikler kopierede den fra et andet projekt.

Denne guide gennemgår de hærdninger, der giver reel værdi, forklarer hvorfor de virker, og springer de rituelle over, som kun giver falsk tryghed. Alle eksempler bruger pladsholdere – skriv aldrig rigtige nøgler eller kodeord ind i en guide, en mail eller et supportticket.

Før du ændrer noget: Tag en backup af wp-config.php (download en kopi via SFTP eller filhåndteringen i dit kontrolpanel), og hav adgang til filerne uden om wp-admin. En syntaksfejl i wp-config.php – fx et manglende semikolon eller et forkert anførselstegn – giver hvid skærm eller kritisk fejl på hele sitet, og så kan du kun rette den via filadgang.

1. Find filen, og læs den igennem

wp-config.php ligger normalt i sitets rodmappe sammen med mapperne wp-admin, wp-content og wp-includes. Åbn den i en teksteditor (ikke et tekstbehandlingsprogram, der kan ændre anførselstegn), og notér, hvad der allerede står. Mange ældre eller migrerede sites har konstanter, ingen længere kan forklare – og nogle gange dubletter, hvor den første definition vinder.

Med WP-CLI kan du se de definerede konstanter uden at åbne filen:

wp config list --fields=name,type

Kommandoen viser navnene, ikke værdierne, hvis du begrænser felterne som her – praktisk, når du deler output med andre. Alle nye konstanter skal stå over linjen /* That's all, stop editing! Happy publishing. */, ellers indlæses de for sent.

2. Sæt friske saltnøgler

De otte AUTH- og SALT-konstanter (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY og de fire tilsvarende …_SALT) indgår i alt, WordPress signerer – først og fremmest login-cookies og nonces. Konsekvensen går begge veje: unikke, hemmelige nøgler gør cookies praktisk talt umulige at forfalske, og et skift af nøglerne gør alle eksisterende login-cookies ugyldige med det samme.

Derfor er der to brugsscenarier. Sæt friske nøgler én gang, hvis sitet kører med svage, tomme eller genbrugte nøgler (det ses ofte på ældre sites og sites, der er klonet fra en skabelon). Og skift dem igen som fast del af enhver sikkerhedshændelse – det logger alle ud, også ubudne gæster med en stjålet session.

Nye nøgler hentes fra WordPress’ officielle generator (api.wordpress.org/secret-key/1.1/salt/), som du kopierer ind i stedet for de gamle linjer. Har du WP-CLI, gør én kommando det hele:

wp config shuffle-salts

Brug aldrig håndskrevne nøgler, og genbrug dem aldrig på tværs af sites. Nøglerne skal ikke huskes af nogen – de skal bare være lange, tilfældige og hemmelige.

3. Slå kode-editoren fra med DISALLOW_FILE_EDIT

WordPress leveres med en indbygget kode-editor (under Udseende og Plugins), der kan redigere tema- og pluginfiler direkte fra wp-admin. I praksis bruges den mest af én gruppe: angribere med en kapret administratorkonto, som med få klik planter en bagdør i functions.php. Én linje fjerner editoren helt:

define( 'DISALLOW_FILE_EDIT', true );

Legitime rettelser hører alligevel hjemme i et child-tema, i versionsstyring eller via SFTP, hvor de kan fortrydes. Vil du et skridt videre, blokerer DISALLOW_FILE_MODS også installation og opdatering af plugins og temaer fra wp-admin. Det er stærkt på låste driftsmiljøer, men kun hvis opdateringerne så sker ad anden vej (WP-CLI, kontrolpanel eller en deploy-proces). Uopdaterede plugins er en større risiko end editoren – så slå ikke opdateringerne fra uden en plan for dem.

4. Debug på live: log, aldrig vis

Fejlbeskeder på skærmen afslører filstier, versioner og nogle gange databasedetaljer for alle besøgende – gratis rekognoscering for en angriber. Standardtilstanden på et live-site bør derfor være stille udadtil og talende i loggen:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Når du skal fejlsøge, slår du WP_DEBUG til og lader WP_DEBUG_LOG skrive til en fil. Her er der en faldgrube: sætter du WP_DEBUG_LOG til true, skriver WordPress til wp-content/debug.log, som på mange servere kan hentes direkte i en browser. Angiv i stedet en sti uden for webroden:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/sti/uden/for/webroden/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );

Mappen skal findes og være skrivbar for PHP-brugeren. Slå WP_DEBUG fra igen, når fejlen er fundet, og slet loggen – den kan vokse hurtigt og indeholde følsomme stier. Selve fejljagten står i guiden til kritisk fejl i WordPress; pointen her er standardtilstanden.

5. Stram rettighederne på wp-config.php

Filen bør ikke være læsbar for andre brugere på serveren. På de fleste hostingmiljøer, hvor PHP kører som din egen bruger, er 600 eller 640 et godt valg; 644 er standard for almindelige filer, men unødigt åbent for netop denne fil. Principperne bag tallene står i guiden til filrettigheder.

chmod 600 wp-config.php
ls -l wp-config.php

Nogle guides anbefaler 400 eller 440 (kun læsning). Det virker, men betyder, at plugins og WP-CLI-kommandoer som wp config set ikke kan skrive i filen – og så fejler fx et salt-skift. Vælg den strammeste værdi, dit site stadig fungerer med, og test bagefter. Ejerskabet tæller lige så meget som tallet: filen skal ejes af den bruger, PHP kører som, ikke af root eller en anden konto.

6. Andre konstanter, der giver mening

Ud over de fire hovedgreb er der en håndfuld konstanter, som er værd at kende. De er ikke alle sikkerhedsfunktioner i snæver forstand, men de gør driften mere forudsigelig:

Konstant	Hvad den gør	Hvornår
—	—	—
FORCE_SSL_ADMIN	Tvinger login og wp-admin over HTTPS	Når sitet har et gyldigt SSL-certifikat
WP_ENVIRONMENT_TYPE	Markerer miljøet som local, development, staging eller production	På staging, så plugins kan slå fx mails og betalinger fra
WP_AUTO_UPDATE_CORE	Styrer automatiske WordPress-opdateringer	Sæt den bevidst – mindst sikkerhedsopdateringer bør køre automatisk
DISALLOW_FILE_MODS	Blokerer installation og opdatering fra wp-admin	Kun når opdateringer sker ad anden vej
WP_DEBUG_LOG	Skriver fejl til en logfil	Under fejlsøgning – helst med sti uden for webroden

Tilføj kun konstanter, du kan forklare. Hver linje i wp-config.php er noget, den næste udvikler skal forstå, før vedkommende tør ændre noget.

7. Spring det rituelle over

En del klassiske „hærdningsråd“ giver meget lidt på moderne hosting. At flytte wp-config.php en mappe op over webroden giver marginal ekstra beskyttelse, så længe PHP fungerer normalt, og kan drille værktøjer og backupløsninger. At skjule WordPress-versionen stopper ingen scanner – de tester sårbarheder direkte. At skifte tabelpræfiks fra wp_ på et eksisterende site er risikabelt og beskytter ikke mod SQL-injektion, som er det egentlige problem.

Det samme gælder lange remser af konstanter fra gamle blogindlæg. Hærdning er de få greb med dokumenteret effekt, udført konsekvent – suppleret med opdateringer, totrinslogin og en backup, du har testet.

8. Verificér, at hærdningen virker

Du er færdig, når du kan krydse alle punkter af:

• Alle otte saltnøgler er unikke og friske – og du blev logget ud, da du satte dem. Det er beviset på, at skiftet slog igennem.
• Theme File Editor og Plugin File Editor er væk fra menuerne i wp-admin.
• En fremprovokeret fejl (fx på staging) viser ingenting på skærmen, men lander i loggen.
• https://ditdomæne.dk/wp-content/debug.log giver 404 eller 403 – ikke en fil med indhold.
• ls -l wp-config.php viser 600 eller 640 og den rigtige ejer.

Notér datoen for salt-skiftet i driftsloggen, og læg konstanterne ind i jeres standardopsætning, så næste site fødes hærdet i stedet for at skulle indhentes bagefter.

Læs også

• Hub: WordPress sikkerhed og backup
• Filrettigheder i WordPress – hvad 644 og 755 betyder
• 10 enkle trin til at holde din WordPress hjemmeside sikker (ingen plugins)
• Malware-oprydning i WordPress trin for trin
• Sikkerhedsheadere: HSTS, nosniff og vejen til CSP
• WordPress hosting hos Hostious – LiteSpeed, daglig backup med selvbetjent gendannelse og dansk support døgnet rundt

Ofte stillede spørgsmål om wp-config-hærdning

Logger et salt-skifte alle ud – også mig?

Ja. Alle sessioner bliver ugyldige, og alle skal logge ind igen. Det er hele pointen ved en sikkerhedshændelse, fordi stjålne cookies holder op med at virke, og i almindelig drift er det en lille gene. Tag skiftet uden for spidsbelastning på sites med mange indloggede brugere eller kunder.

Mister jeg funktioner med DISALLOW_FILE_EDIT?

Kun kode-editoren i wp-admin – alt andet virker som før. Reelle kodeændringer sker via SFTP, child-tema eller versionsstyring, hvor de kan fortrydes. Bruger du DISALLOW_FILE_MODS i stedet, forsvinder også installation og opdatering af plugins fra wp-admin, så det kræver en anden opdateringsrutine.

Skal jeg også skifte databasekodeordet?

Ved en sikkerhedshændelse: ja, altid, og wp-config.php opdateres samtidig. I almindelig drift kun hvis det er svagt eller har været delt – et stærkt, unikt databasekodeord sat én gang er tilstrækkeligt.

Hvor skal debug.log ligge?

Helst uden for webroden, så den ikke kan hentes i en browser. Sæt WP_DEBUG_LOG til en fuld sti i stedet for true, og slå logningen fra igen, når fejlen er fundet. Kan du ikke skrive uden for webroden, så bloker adgangen til filen på webserveren og slet den efter brug.

Hjælper det at flytte wp-config.php en mappe op?

Meget lidt på moderne hosting. Filen bliver ikke vist, så længe PHP fungerer, og flytningen kan drille værktøjer og backupløsninger. Stramme rettigheder, friske saltnøgler og slukket fejlvisning giver langt mere sikkerhed for indsatsen.