Avancerede sikkerhedsindstillinger i WordPress wp-config.php – Komplet guide

Avancerede sikkerhedsindstillinger i WordPress wp-config.php er konfigurationer, der beskytter databaseadgang, styrker sessionsnøgler, deaktiverer filredigering, håndterer debug-output sikkert, gennemtvinger SSL og begrænser kritiske sti-angivelser. Kort sagt er wp-config.php et af din WordPress-sides sikkerhedscentre; med de rette indstillinger mindsker du angrebsfladen, reducerer risikoen for uautoriseret adgang og begrænser skaden ved et eventuelt sikkerhedsbrud.

De fleste site-ejere, der installerer WordPress, ser wp-config.php som en teknisk fil, hvor man blot indtaster databasenavn, brugernavn og adgangskode. Men i virkeligheden er denne fil en kritisk del af sikkerhedsarkitekturen på et live-website. Især for webshops, medlemssystemer, virksomhedswebsites og blogs med høj trafik giver en korrekt konfigureret wp-config.php et stærkt forsvarslag mod simple bot-angreb, filmanipulation via panelet, lækage af fejlmeddelelser og sessionskapring.

I denne guide gennemgår vi trin for trin de avancerede sikkerhedsindstillinger, du kan implementere i WordPress wp-config.php-filen. Vi forklarer, hvad hver indstilling gør, i hvilke situationer vi anbefaler den, og hvad du skal være opmærksom på, før du går i gang – i et enkelt men teknisk præcist sprog. Hvis du endnu ikke har en sikker og opdateret hostinginfrastruktur, er valget af pålidelig WordPress-hosting lige så vigtigt som at hærde wp-config.php. Her kan WordPress hosting pakker og sikker webhosting løsninger være relevante.

Hvad er wp-config.php, og hvorfor er den kritisk for sikkerheden?

wp-config.php er den konfigurationsfil, der ligger i WordPress' rodmappe og indeholder de grundlæggende driftsparametre for sitet. Via denne fil opretter WordPress forbindelse til databasen, læser sikkerhedsnøgler, bestemmer fejlsøgningsadfærd, håndterer filsystemoperationer og eksekverer visse avancerede konstanter. Filens indhold er derfor langt mere følsomt end en almindelig temafil.

Filen indeholder typisk følgende kritiske oplysninger:

• Databasenavn, brugernavn, adgangskode og serveroplysninger
• Sessionssikkerhedsnøgler kendt som Authentication Unique Keys og Salts
• Database-tabelpræfiks
• Debug- og logningsindstillinger
• Konstanter, der styrer filredigering, opdatering og SSL-adfærd
• Driftsindstillinger som WordPress-hukommelsesgrænse og midlertidig filmappe

Hvis en angriber får adgang til wp-config.php's indhold, kan vedkommende få fat i databaseforbindelsesoplysningerne. I så fald er det ikke kun WordPress-panelet, der er i fare, men også brugerkonti, ordredata, formularer, indhold og private kundedata i databasen. Derfor er beskyttelse af wp-config.php et af de grundlæggende trin i WordPress-sikkerhed.

Før du begynder: Backup, test og adgangsplan

Selv en lille stavefejl i wp-config.php kan forårsage en hvid skærm, afbrudt databaseforbindelse eller mistet adgang til administrationspanelet. Implementer derfor en tre-trins sikkerhedsplan, før du foretager ændringer.

1. Tag en komplet backup

Tag først backup af både filer og database. Det er ikke nok kun at downloade wp-config.php til din computer; en databasebackup er også vigtig, da en ændring kan påvirke databaseforbindelsen. Hvis dit kontrolpanel har automatisk backup, så tjek datoen for seneste backup. Opret en manuel backup om nødvendigt. Her kan du gå videre med guide til website backup.

2. Implementer ændringer én ad gangen

I stedet for at tilføje 8-10 sikkerhedsindstillinger på én gang, så test sitet, administrationspanelet og kritiske formularer efter hver ændring. Luk f.eks. først for filredigering, og tjek derefter sitet. Konfigurer så debug-indstillingen. Denne metode gør det nemt hurtigt at finde den linje, der skaber problemer, hvis der opstår en fejl.

3. Hav FTP- eller filhåndteringsadgang klar

Hvis wp-config.php gemmes med fejl, kan du miste adgang til WordPress-panelet. Sørg derfor for, at cPanel-filhåndtering, SFTP eller sikker filoverførselsadgang fungerer. SFTP er mere sikkert end FTP, da forbindelsen er krypteret. En guide med titlen hvad er SFTP og hvordan bruges det kan være nyttig for sikker adgang.

Oversigt over wp-config.php sikkerhedsindstillinger

Tabellen nedenfor opsummerer de grundlæggende og avancerede sikkerhedsindstillinger, der beskrives i denne guide. Vurder hver linje i forhold til dit sites behov, før du implementerer på live-sitet.

Styrk sikkerhedsnøgler og salt-værdier

WordPress sessionssikkerhed understøttes af AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY og deres salt-modstykker i wp-config.php. Disse nøgler gør brugercookies og sessionsvalideringsprocesser mere sikre. Hvis nøglerne er svage, standardindstillede eller ikke har været skiftet i lang tid, kan sessionssikkerheden svækkes.

Den anbefalede praksis er at generere nye, tilfældige nøgler via WordPress' officielle secret key-generator. Disse nøgler er typisk over 64 tegn lange, indeholder tilfældige symboler og er i praksis umulige at gætte. Du skal blot erstatte de eksisterende linjer i wp-config.php med de nye nøgler.

Effekten er tydelig: Alle aktive brugersessioner afsluttes, og brugerne skal logge ind igen. Hvis du har mistanke om, at en administratorkonto er blevet kompromitteret, er det et hurtigt nødskridt at forny salt-værdierne. Det er god praksis at forny disse nøgler hver 6. måned eller ved mistanke om sikkerhedsbrud.

Deaktiver filredigering via panelet

WordPress-administrationspanelet har en editor, der tillader redigering af tema- og plugin-filer. Selvom denne funktion virker praktisk under udvikling, udgør den en alvorlig risiko på live-sites. Hvis en angriber får adgang til en administratorkonto, kan vedkommende tilføje skadelig PHP-kode via fileditoren i panelet.

Du kan deaktivere filredigering fra panelet ved at tilføje følgende konstant til wp-config.php: define('DISALLOW_FILE_EDIT', true);

Denne indstilling deaktiverer tema- og plugin-fileditoren i WordPress-panelet. Vi anbefaler, at den som standard er aktiveret for blogs med daglige opslag, virksomhedssites og WooCommerce-butikker. Hvis filændringer er nødvendige, bør de foretages via SFTP, Git eller sikre distributionsprocesser.

Som en mere vidtgående mulighed kan konstanten DISALLOW_FILE_MODS, der også begrænser filupload og opdateringer, anvendes. Men da denne indstilling også kan blokere plugin- og temaopdateringer, bør den kun foretrækkes på meget følsomme systemer, hvor ændringer uden for vedligeholdelsesvinduer ikke bør finde sted.

Tilpas debug-indstillinger til live-site

I et WordPress-udviklingsmiljø er det nyttigt at slå WP_DEBUG til; du kan se fejl, finde inkompatible plugins og diagnosticere temaproblemer. Men på et live-site kan fejlmeddelelser vist på skærmen indeholde oplysninger som serversti, pluginnavn, filplacering, databaseforespørgselstips og PHP-version – information, der kan være nyttig for en angriber.

Den sikre tilgang i live-miljøet bygger på følgende logik: Vis ikke fejl til besøgende, skriv dem om nødvendigt til en dedikeret logfil. Til dette skal WP_DEBUG være false; hvis logning er nødvendig under udvikling, bør WP_DEBUG_LOG være true og WP_DEBUG_DISPLAY false. Eksempel: define('WP_DEBUG', false); define('WP_DEBUG_DISPLAY', false);

Hvis du har brug for at undersøge en fejl, så slå logning til i en kort periode, løs problemet, og slå det fra igen. Sørg også for, at logfilen ikke er tilgængelig fra en offentlig mappe. Debug.log-filen kan nogle gange oprettes tæt på web-roden og kan være læsbar udefra på fejlkonfigurerede servere. Korrekt hostingopsætning er kritisk for at mindske sådanne risici. hvordan håndteres WordPress fejllogs og sikker WordPress hosting er naturlige fortsættelser her.

Gør SSL og panelsikkerhed obligatorisk

Et SSL-certifikat krypterer trafikken mellem bruger og server. Da login til WordPress-panelet sker med brugernavn og adgangskode, er det afgørende, at admin-trafikken foregår over HTTPS. Denne indstilling er endnu vigtigere for teams, der tilgår administrationspanelet fra fællesnetværk, uden for kontoret eller via mobilforbindelser.

I wp-config.php kan SSL gøres obligatorisk i administrationspanelet med konstanten FORCE_SSL_ADMIN: define('FORCE_SSL_ADMIN', true);

For at denne indstilling virker korrekt, skal der være et gyldigt SSL-certifikat på dit domæne. Hvis du endnu ikke bruger SSL, skal du først færdiggøre certifikatinstallationen. SSL er ikke kun et sikkerhedskrav, men også essentielt for brugertillid og SEO. For SSL-muligheder hos Hostragons kan du se SSL certifikat produkter, og for domæneadministration kan du tjekke domæneopslag og domæneregistrering.

Hvis der opstår en uendelig omdirigeringsfejl efter SSL-tvang, skyldes det ofte, at proxy-, CDN- eller load balancer-konfigurationen ikke registreres korrekt. I så fald skal HTTPS-headers på serversiden og WordPress site-adresseindstillinger kontrolleres.

Administrer databaseoplysninger og tabelpræfiks mere sikkert

Værdierne DB_NAME, DB_USER, DB_PASSWORD og DB_HOST i wp-config.php gør det muligt for WordPress at oprette forbindelse til databasen. Disse oplysninger skal være stærke og have begrænsede rettigheder. En af de hyppigste fejl er at give databasebrugeren flere rettigheder end nødvendigt.

Til et live WordPress-site anbefales det, at databasebrugeren kun har de nødvendige tilladelser. Typisk er rettigheder som SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER og INDEX tilstrækkelige. Det er risikabelt at bruge bredt bemyndigede brugere med adgang til alle databaser i WordPress-konfigurationen.

Korrekt tilgang til tabelpræfiks

WordPress' standard tabelpræfiks er wp_. I nye installationer kan du ændre dette til en anden og tilfældig værdi for at besværliggøre automatiske angrebsværktøjers arbejde. Du kan f.eks. vælge et kort men svært gætteligt præfiks som hr7x_ i stedet for wp_. Men at ændre tabelpræfikset på et eksisterende site er ikke kun et spørgsmål om at ændre table_prefix i wp-config.php; tabelnavnene i databasen og visse usermeta-poster skal også opdateres.

Hvis du derfor skal ændre tabelpræfikset på et eksisterende live-site, så tag først en komplet backup, test proceduren i et staging-miljø hvis muligt, og flyt derefter til live. For nye installationer er det mere sikkert og mindre risikabelt at bruge et andet præfiks fra starten.

Mulighed for at flytte wp-config.php uden for rodmappen

I visse serverkonfigurationer kan WordPress også læse wp-config.php ét niveau over rodmappen. Hvis WordPress-filerne f.eks. ligger i public_html, kan wp-config.php flyttes til en overordnet mappe uden for public_html. Denne metode reducerer risikoen for direkte adgang via nettet.

Denne praksis fungerer dog ikke nødvendigvis ens i alle hostingmiljøer. På delt hosting kan mappetilladelser, kontrolpanelstruktur eller sikkerhedspolitikker gøre det umuligt at flytte filen til en overordnet mappe. Desuden skal de personer, der vedligeholder sitet, kende filens placering; ellers kan fejlfindingsprocessen blive unødigt lang.

Før du implementerer denne metode, bør du tjekke din hostingudbyders filstruktur. Hvis du bruger administreret WordPress-hosting, så spørg supportteamet om den anbefalede mappestruktur. For korrekt mappe- og tilladelseshåndtering på Hostragons' infrastruktur kan hosting kontrolpanel guide være understøttende.

Stram filtilladelser og skriverettigheder

Sikkerheden omkring wp-config.php handler ikke kun om konstanterne indeni, men også om filens tilladelser på operativsystemniveau. Den generelle anbefaling er, at wp-config.php ikke må være skrivbar for alle. I de fleste Linux-baserede hostingmiljøer kan filtilladelser konfigureres med mere begrænsede værdier som 400, 440 eller 600. Hvilken værdi, der virker, afhænger af serverbrugeren og PHP-driftsmodellen.

Den praktiske tilgang er: Filen bør have de lavest mulige tilladelser, der ikke forhindrer sitets drift. Indstillinger som 777, der giver alle skriverettigheder, må absolut ikke anvendes. 644 fungerer som standard i nogle miljøer, men i mere følsomme installationer kan 600 eller 440 foretrækkes. Efter ændringen skal du teste sitevisning, administrationspanel og pluginopdateringsskærme.

Derudover er det vigtigt at blokere adgang til wp-config.php på webserverniveau. I moderne hostinginfrastrukturer vises PHP-filer ikke direkte som kilder; men på fejlkonfigurerede servere kan der opstå en risiko. Derfor er pålidelig hostinginfrastruktur lige så vigtig som filtilladelser.

Administrer automatiske opdateringer med sikkerhed for øje

WordPress-kernen, plugins og temaer modtager regelmæssigt sikkerhedsopdateringer. Via wp-config.php kan du til en vis grad styre adfærden for automatiske opdateringer. Sikkerhedsmæssigt anbefales det generelt, at mindre versionsopdateringer foretages automatisk, da disse oftest fokuserer på sikkerhed og fejlrettelser.

At holde automatiske mindre opdateringer slået til for WordPress-kernen reducerer f.eks. forsinkelsen i forhold til kendte sårbarheder. Men større versionsskift kan kræve test i forhold til tema- og pluginkompatibilitet. Derfor er den sundeste metode for virksomhedssites at holde automatiske sikkerhedsrettelser aktive, men at teste store opdateringer i et staging-miljø, før de implementeres på live-sitet.

Du kan bruge tre grundregler i din opdateringsstrategi: Først backup, så test, og til sidst implementering på live. Denne enkle rækkefølge skaber den rette balance mellem sikkerhed og kontinuitet.

Hold PHP-hukommelsesgrænse og ressourceforbrug under kontrol

I wp-config.php kan mængden af hukommelse, WordPress kan bruge, defineres med WP_MEMORY_LIMIT og WP_MAX_MEMORY_LIMIT. Selvom disse indstillinger ikke umiddelbart ligner sikkerhedsindstillinger, er de vigtige ved ressourceudmattelsesangreb, fejlbehæftede plugins og intensive admin-processer.

For en lille blog er 128M f.eks. ofte tilstrækkeligt, mens WooCommerce-butikker eller flersprogede sites kan have brug for 256M. Men at hæve hukommelsesgrænsen unødigt højt kan få et defekt plugin til at forbruge flere ressourcer og forringe serverens ydeevne. Den korrekte værdi skal vurderes i forhold til sitets trafik, antallet af plugins og hostingpakkens ressourcer.

Hvis du ofte får hukommelsesfejl, bør du undersøge kilden til problemet i stedet for blot at hæve grænsen. Tunge plugins, uoptimerede forespørgsler, en gammel PHP-version eller en utilstrækkelig hostingpakke kan være årsagen. Ydeevne og sikkerhed bør håndteres sammen. Her giver WordPress ydelsesoptimering og højtydende hosting pakker naturlige linkmuligheder.

Hold midlertidig filmappe og uploadadfærd sikker

I nogle hostingmiljøer opbevarer WordPress midlertidige filer i systemets standardmapper. Dette er normalt; men fællesmapper med fejlagtige tilladelser kan udgøre en sikkerhedsrisiko. Ved at definere WP_TEMP_DIR i wp-config.php kan du angive den mappe, WordPress skal bruge til midlertidige filer.

Hvis du bruger denne metode, skal du sikre, at mappen er lukket for offentlig adgang, har kontrollerede skriverettigheder og kun er tilgængelig for den relevante sitebruger. Midlertidige mapper bruges aktivt især under filupload, mediehåndtering og pluginopdateringer. En forkert konfigureret midlertidig mappe kan forårsage uploadfejl eller risiko for fillækage.

Cookie-domæne og multisite-sikkerhed

I projekter, der bruger WordPress multisite, underdomæner eller undermappestrukturer, bliver cookie-domæne og site-URL-værdier mere følsomme. En forkert definition af cookie-domænet kan medføre, at sessioner er gyldige på uventede underdomæner eller forårsager login-loops. Sikkerhedsmæssigt bør cookie-omfanget begrænses til det mindst nødvendige domæne for hver site-arkitektur.

I opsætninger som admin.example.com, shop.example.com og blog.example.com skal det f.eks. bevidst besluttes, om cookies skal være gyldige på alle underdomæner eller kun på et specifikt domæne. Et unødigt bredt cookie-omfang kan øge sandsynligheden for, at en sårbarhed på ét underdomæne påvirker sessioner på andre domæner.

Hvis du bruger multisite, bør du vurdere multisite-konstanterne i wp-config.php, domain mapping-indstillinger og SSL-konfigurationen samlet. I sådanne projekter er domæne- og SSL-planlægning også vigtig. multdomæne administration og wildcard SSL certifikat kan være relevante links her.

Anvendelig sikkerhedstjekliste til wp-config.php

Du kan periodisk gennemgå nedenstående liste på dit live WordPress-site. Det er en god vane især at gennemgå den efter installation af nye plugins, temaskift, serverflytning og mistænkelige loginforsøg.

• Opbevares en opdateret backup af wp-config.php et sikkert sted?
• Er sikkerhedsnøgler og salt-værdier unikke og tilfældige?
• Er DISALLOW_FILE_EDIT aktiv?
• Er WP_DEBUG slået fra eller i sikker logningstilstand på live-sitet?
• Kører administrationspanelet obligatorisk over HTTPS?
• Har databasebrugeren unødvendige rettigheder?
• Er tabelpræfikset i nye installationer et andet end standard wp_?
• Indeholder filtilladelser ikke farlige værdier som 777?
• Er automatiske sikkerhedsopdateringer slået til på en kontrolleret måde?
• Er SFTP, backup og SSL korrekt konfigureret på hostingkontoen?

Hyppige fejl og hvordan du undgår dem

Den hyppigste fejl med wp-config.php er at tilføje kodestumper fra nettet uden at forstå, hvad de gør. Ikke alle WordPress-sites har den samme server, tema, plugin og trafikstruktur. Derfor kan en indstilling, der fungerer problemfrit på ét site, forårsage sessionsproblemer eller opdateringsfejl på et andet.

Den anden almindelige fejl er at lade debug-output være slået til på live-sitet. Dette forringer både brugeroplevelsen og fører til lækage af teknisk information. Den tredje fejl er at efterlade en backup af wp-config.php i web-rodmappen med navne som wp-config-backup.php, wp-config-old.php. Disse filer kan downloades som ren tekst ved forkert serveropsætning. Backups bør opbevares i et område uden webadgang.

Den fjerde fejl er at sætte filtilladelser til 777 for at løse et problem og derefter ikke sætte dem tilbage. Selvom det kan synes at løse problemet på kort sigt, er det meget farligt sikkerhedsmæssigt. Den femte fejl er at aktivere FORCE_SSL_ADMIN uden at have installeret SSL; dette kan forårsage adgangsproblemer til administrationspanelet.

Hvordan opbygger man et professionelt WordPress-sikkerhedslag?

Hærdning af wp-config.php er et vigtigt skridt, men giver ikke komplet sikkerhed alene. En professionel sikkerhedstilgang bør være lagdelt. Stærk hostingisolering, opdateret PHP-version, webapplikationsfirewall, pålidelig SSL, regelmæssig backup, begrænsede administratorkonti, tofaktorautentificering og logovervågning bør overvejes samlet.

Hvis en angriber f.eks. forsøger at udnytte en pluginsårbarhed, kan WAF-laget blokere forespørgslen. Hvis en brugeradgangskode kompromitteres, træder tofaktorautentificering i kraft. Hvis en filændring finder sted, kan en hurtig gendannelse fra backup foretages. wp-config.php er i denne kæde det kritiske konfigurations- og begrænsningspunkt.

Hvis du er ved at oprette dit WordPress-site, så gå sikkerhedsfokuseret til værks fra starten: planlæg et stærkt domæne og SSL, vælg sikker hosting, skift standard tabelpræfikset, generer unikke salt-nøgler, deaktiver panelfilredigering, og aktiver regelmæssige backups. Disse grundlæggende trin forhindrer mange fremtidige problemer, før de overhovedet opstår.

Konklusion: Små indstillinger, stor sikkerhedseffekt

Avancerede sikkerhedsindstillinger i WordPress wp-config.php tilbyder praktiske og effektive tiltag, der reducerer dit sites angrebsflade. At forny salt-nøgler, deaktivere filredigering, skjule debug-output, gennemtvinge SSL, begrænse databaserettigheder og stramme filtilladelser er trin, der giver stor gevinst for de fleste WordPress-sites.

Tag dig god tid, når du implementerer disse indstillinger: tag backup, foretag ændringer én ad gangen, og test hvert trin. Når en sikker konfiguration kombineres med den rette hostinginfrastruktur og regelmæssig vedligeholdelse, bliver dit WordPress-site langt mere robust. Hvis du planlægger en mere sikker og bæredygtig infrastruktur, kan du undersøge Hostragons' WordPress hosting, SSL certifikat og domæneregistrering løsninger for at finde det rette udgangspunkt til dine behov.

Ofte stillede spørgsmål

Er det sikkert at redigere wp-config.php?

Ja, det er sikkert, når du tager korrekt backup og implementerer ændringer kontrolleret. Men en enkelt stavefejl kan påvirke siteadgangen. Tag derfor først backup af filer og database, og test derefter indstillingerne én efter én.

Hvad sker der, hvis jeg ændrer salt-nøglerne i wp-config.php?

Alle aktive brugersessioner afsluttes, og brugerne skal logge ind igen. Denne handling sletter ikke indhold og ødelægger ikke databasen. Det er et hurtigt tiltag, der især anbefales efter mistænkelig login, risiko for administratorkonto eller sikkerhedsbrud.

Skal WP_DEBUG være slået til på et live WordPress-site?

Nej. Hvis WP_DEBUG er slået til på et live-site, kan fejlmeddelelser lække teknisk information til besøgende. Den sikre tilgang er ikke at vise fejl på skærmen og kun bruge kontrolleret logning ved kortvarige behov.

Forhindrer DISALLOW_FILE_EDIT plugin- og temaopdateringer?

Nej, DISALLOW_FILE_EDIT deaktiverer kun fileditoren i administrationspanelet. Plugin- og temaopdateringer fortsætter normalt. For også at deaktivere opdateringer kræves andre og mere restriktive indstillinger.

Hvad skal filtilladelsen for wp-config.php være?

Det varierer afhængigt af serveropsætningen, men målet er at holde filen med de lavest mulige tilladelser, der ikke forhindrer drift. 777 må absolut ikke anvendes. I de fleste miljøer kan 600, 440 eller 644 fungere; site og panel skal testes efter ændringen.