Praktisk guide til WordPress sikkerhed

Forstå trusselsbilledet i WordPress

De fleste WordPress-kompromitteringer skyldes ikke, at selve WordPress-kernen er usikker i sig selv, men at angrebsfladen bliver udvidet gennem sårbare plugins, forældede temaer, svage adgangskoder, dårlig rollefordeling eller usikre serverindstillinger. For WooCommerce-sites bliver risikoen større, fordi der ofte behandles kundeoplysninger, ordrer, e-mails og integrationsdata i samme miljø.

En praktisk sikkerhedsstrategi bør skelne mellem fire situationer: generel risikoreduktion, kendte men ikke nødvendigvis udnyttede sårbarheder, aktivt misbrug observeret i logs og et bekræftet kompromis. Den skelnen er vigtig, fordi den afgør, om du skal planlægge vedligeholdelse, hasteopdatere, blokere trafik eller isolere et miljø og gennemføre incident response.

Start med opdateringer og versionsstyring

Sikkerhedsopdateringer er det mest effektive grundlag for risikoreduktion. WordPress core, plugins, temaer, PHP-version og serverpakker bør holdes opdateret efter en fast proces. Især plugins med mange installationer bliver hurtigt mål for automatiseret scanning, når en sårbarhed er offentlig kendt.

Vedligehold en komplet oversigt over installerede plugins, temaer og deres formål
Fjern deaktiverede eller ubrugte komponenter i stedet for blot at lade dem ligge
Test opdateringer i staging, især på WooCommerce-sites med betalings- eller fragtilføjelser
Planlæg rutiner for både applikationsopdateringer og serveropdateringer
Dokumentér hvilke ændringer der blev lavet, hvornår og med hvilket resultat

Hvis et plugin ikke længere vedligeholdes, bør det vurderes som en sikkerhedsrisiko, også selv om der endnu ikke er observeret misbrug. Det samme gælder custom kode, som ikke længere har en ejer eller testproces.

Adgangskontrol og begrænsning af privilegier

Mange angreb lykkes ikke gennem avanceret udnyttelse, men via kompromitterede loginoplysninger. Derfor bør administratoradgang begrænses stramt. Tildel kun roller med de nødvendige rettigheder, og undgå at alle redaktører eller bureaubrugere får administratorstatus af bekvemmelighed.

Brug unikke adgangskoder og aktiver multifaktorlogin, hvis løsningen understøtter det
Begræns antallet af administratorbrugere
Gennemgå brugerlister regelmæssigt og fjern gamle konti
Sørg for, at hostingpanel, SFTP, database og WordPress ikke deler samme adgangskode
Begræns filadgang på serveren efter princippet om mindst mulige privilegier

Brute force mod wp-login.php og xmlrpc-relaterede loginforsøg ses ofte i almindelige hostingmiljøer. Det gør rate limiting, botbeskyttelse og eventuel WAF-filtrering relevant, især på sites med høj synlighed eller kendte login-URL’er.

WordPress hardening på fil- og applikationsniveau

Hardening reducerer konsekvensen af fejl og gør misbrug vanskeligere. Det erstatter ikke opdateringer, men giver lagdelt forsvar. Typiske tiltag er beskyttelse af konfigurationsfiler, deaktivering af unødvendig filredigering i administrationen og korrekt filstruktur i webroden.

I wp-config.php kan du typisk deaktivere indbygget filredigering med:
define('DISALLOW_FILE_EDIT', true);

På mange installationer giver det mening at sikre, at wp-config.php ikke er direkte tilgængelig via webserveren, og at mappe- og filrettigheder ikke er mere åbne end nødvendigt. Rettigheder skal dog tilpasses det konkrete hostingmiljø, så automatiske opdateringer og cache-funktioner fortsat virker korrekt.

Hvis uploads-mappen bliver misbrugt til at placere eksekverbar kode, er det ofte et tegn på enten en plugin-sårbarhed, kompromitteret adminadgang eller for brede serverindstillinger. I nogle miljøer kan man blokere PHP-eksekvering i uploads-kataloget, men implementeringen afhænger af Apache, Nginx eller kombineret proxy-opsætning og bør testes grundigt.

Firewall, WAF og Cloudflare i praksis

En WAF kan filtrere kendte mønstre i ondsindet trafik, reducere støj fra bots og blokere simple udnyttelsesforsøg mod login, XML-RPC og udsatte plugin-endpoints. Den bør ses som et ekstra lag og ikke som erstatning for patching. Hvis et sårbart plugin er installeret, er den korrekte løsning stadig opdatering, midlertidig deaktivering eller leverandørpatch.

Cloudflare eller tilsvarende reverse proxy-tjenester kan hjælpe med botbeskyttelse, caching og filtrering før trafikken rammer origin-serveren. I driften er det vigtigt at sikre korrekt håndtering af besøgendes IP-adresser i logs og applikation, så blokering, rate limiting og audit-data ikke baseres på proxy-IP’er alene.

Aktivér kun regler, du forstår konsekvensen af
Overvåg falske positiver på checkout, login og formularer
Bekræft at origin-serveren ikke kan omgås direkte, hvis proxyen skal være effektiv
Log ændringer i firewall-regler som en del af driftsprocessen

Backup er kun værdifuld, hvis gendannelse er testet

WordPress backup bør omfatte både filer og database. For WooCommerce er det særligt vigtigt at forstå forskellen mellem en daglig backup og behovet for kortere gendannelsespunkter, hvis ordredatarisikoen er høj. En backupstrategi skal beskrive frekvens, opbevaring, retention, kryptering og ansvar for restore-test.

Tag backup før plugin-opdateringer, temaændringer og større PHP-skift
Opbevar mindst én kopi uden for samme server eller hostingkonto
Test gendannelse i staging, ikke kun at backupjobbet rapporterer succes
Dokumentér hvor lang tid en restore tager, og hvilke trin der kræves efter gendannelse

En utestet backup er et håb, ikke en kontrolleret beredskabsplan. Ved malware-hændelser skal man også vurdere, om backupen allerede indeholder skadelig kode, og hvor langt tilbage man skal gå for at finde et rent gendannelsespunkt.

Logning, overvågning og fejlfinding

Sikker drift kræver synlighed. Uden logs bliver både angreb og driftsfejl vanskelige at forstå. Mindst tre lag er relevante: webserverlogs, PHP error log og applikationsnære hændelser som login, plugin-fejl og ændringer i filer eller indstillinger.

Ved fejlfinding kan WordPress logging typisk aktiveres i wp-config.php med en defensiv opsætning som:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

I produktion bør fejl som udgangspunkt ikke vises til slutbrugeren. Fejlvisning kan afsløre filstier, plugin-navne eller interne detaljer. Fejl bør i stedet sendes til log, hvor de kan gennemgås sikkert. PHP error log er ofte central ved problemer efter opdatering til nyere PHP-versioner, hvor deprecated funktioner eller typefejl bliver tydelige.

Serverovervågning bør som minimum følge svartider, CPU, RAM, diskplads, processer, HTTP-fejl og certifikatudløb. Et sikkerhedsproblem kan i praksis først blive synligt som performance-afvigelse, pludselig høj PHP-belastning eller mange POST-requests mod et endpoint.

Sådan opdager du tegn på WordPress malware

Malware i WordPress viser sig sjældent kun som en tydelig advarsel. Typiske symptomer er uautoriserede redirects, ukendte adminbrugere, ændrede kernefiler, spamindhold, uventede cron-jobs, nye PHP-filer i uploads eller trafikmønstre, der ikke passer med normal drift.

Sammenlign WordPress core-filer med rene versionsfiler
Undersøg nyligt ændrede filer i webroden og uploads
Gennemgå active plugins og mu-plugins for ukendte komponenter
Kontrollér databasen for injicerede scripts i widgets, options og indholdsblokke
Gennemgå administratorbrugere, cron-hændelser og planlagte jobs

Hvis et kompromis er sandsynligt, bør miljøet isoleres, før oprydning begynder. Det kan være nødvendigt at sætte siden i vedligeholdelsestilstand, begrænse adgang via webserver eller midlertidigt blokere offentlig trafik. Derefter bør man genskabe fra en kendt ren backup eller genopbygge installationen systematisk med rene filer og roterede legitimationsoplysninger.

PHP, webserver og SSL/TLS som del af sikkerheden

WordPress sikkerhed afhænger også af platformen under applikationen. En understøttet PHP-version reducerer risiko fra kendte fejl og giver bedre kompatibilitet med moderne kode. På serverniveau bør unødvendige funktioner, svage standardindstillinger og uklare rettigheder gennemgås som del af driftsoverlevering.

SSL/TLS skal være korrekt implementeret, så administration, checkout og almindelig brugertrafik går over HTTPS. For webshops er det især vigtigt at undgå blandet indhold, fejl i omdirigeringer og certifikater, der udløber uden varsling. HSTS og andre strammere politikker kan være relevante, men bør indføres kontrolleret og testes mod afhængigheder som eksterne scripts, CDN og underdomæner.

En praktisk driftsrutine måned for måned

Gennemgå og installer sikkerhedsrelevante opdateringer efter test
Kontrollér backupstatus og gennemfør periodisk restore-test
Læs PHP error log, webserverfejl og sikkerhedshændelser siden sidste gennemgang
Valider brugeradgange og fjern konti, der ikke længere er nødvendige
Undersøg performance-afvigelser, fordi de kan dække over bots, fejl eller ressourcespild
Kontrollér certifikater, DNS-relaterede ændringer og proxy- eller firewall-regler

Denne type rutine er mere værdifuld end store engangsindsatser. WordPress sikkerhed er i høj grad disciplineret drift: korte reaktionstider på ændringer, tydelig dokumentation og faste kontroller, der gør det lettere at opdage afvigelser tidligt.

Afslutning

En praktisk guide til WordPress sikkerhed bør ende samme sted, som arbejdet begynder: med proces frem for enkeltværktøjer. Den robuste løsning er kombinationen af opdateringer, mindst mulige privilegier, lagdelt beskyttelse, testede backups, brugbar logning og et hostingmiljø, der bliver vedligeholdt aktivt. Når sikkerhedsarbejdet kobles tæt til den daglige drift, bliver det lettere både at forebygge kompromittering, fejlfinde hurtigere og bevare stabile websites og webshops over tid.