WordPress hardening i praksis: sådan reducerer du angrebsfladen på driftkritiske websites og webshops

Hardening er risikoreduktion, ikke en garanti

Hardening betyder at gøre et system vanskeligere at misbruge. I WordPress-kontekst handler det om at begrænse, hvad en angriber kan opnå, hvis et login kompromitteres, et plugin har en sårbarhed, eller en bot målretter brute force mod wp-login.php eller XML-RPC. Den praktiske værdi ligger i lagdelt forsvar: sikre opdateringer, mindst mulige privilegier, filintegritet, backup, logning og afgrænset netværksadgang. WordPress’ egen vejledning om Hardening WordPress er et godt grundlag, men i drift bør anbefalingerne omsættes til konkrete kontrolpunkter.

1. Start med angrebsfladen: temaer, plugins og brugere

Den største angrebsflade på mange installationer er ikke kerneplatformen, men tredjepartskode og brugerrettigheder. Hvert aktivt plugin og tema øger kompleksiteten. På WooCommerce-sites er det særligt vigtigt at gennemgå checkout-, betalings-, import- og medlemskabsplugins, fordi de ofte håndterer følsomme data eller eksponerer formularer mod internettet.

Fjern plugins og temaer, der ikke bruges. Inaktive komponenter kan stadig udgøre en risiko, hvis de ligger installeret og er sårbare.
Begræns antallet af administratorer, og brug redaktør- eller shop manager-roller, hvor det er tilstrækkeligt.
Gennemgå gamle brugere, API-integrationer og servicekonti kvartalsvist.
Undgå at genbruge administrator-konti til dagligt indholdsarbejde.

For WooCommerce bør roller og integrationer gennemgås lige så stramt som selve login-adgangen. WooCommerce anbefaler også sikker drift med fokus på opdateringer, adgangskontrol og sikre miljøer i deres security best practices. Det er især relevant for shops med flere ansatte, eksterne bureauer eller ERP-forbindelser.

2. Opdateringer skal styres, ikke udsættes

Mange kompromitteringer skyldes kendte sårbarheder i ældre plugin- eller temaversioner. Derfor bør sikkerhedsopdateringer behandles som drift, ikke som ad hoc-arbejde. Det betyder stagingmiljø, dokumenteret ændringsproces, backup før ændring og efterfølgende kontrol af frontend, login, checkout, cronjobs og integrationer.

Tag altid fil- og databasebackup før opdateringer, især på webshops.
Test opdateringer i staging, når sitet har specialkode, betalingsmoduler eller komplekse caches.
Prioritér opdateringer, der lukker dokumenterede sårbarheder, over kosmetiske forbedringer.
Følg changelogs og officielle sikkerhedsmeddelelser for WordPress-kernen, plugins og hostingmiljøet.

Hvis du arbejder med CVE-referencer, bør versioner og datoer kun bruges, når de kan verificeres i officielle advisories eller troværdige leverandørmeddelelser. I praksis betyder det, at et sikkerhedsfix først bør kommunikeres internt som aktiv risiko, når den tekniske kilde er bekræftet.

3. Beskyt login-fladen med flere lag

Brute force mod wp-login.php og xmlrpc.php er stadig et almindeligt driftsproblem. Målet er ikke kun at stoppe kompromittering, men også at reducere unødig belastning på PHP og databasen. Her er Cloudflare, WAF og rate limiting ofte mere effektive end kun et lokalt WordPress-plugin, fordi trafikken kan filtreres, før den rammer origin-serveren.

Aktivér stærke adgangskoder og multifaktor-autentifikation for administratorer.
Indfør rate limiting på login-endpoints og følsomme formularer.
Begræns adgang til wp-admin via IP-lister, VPN eller SSO, hvis driftsmodellen tillader det.
Deaktivér eller begræns XML-RPC, hvis det ikke bruges af legitime integrationer.

Cloudflare dokumenterer både fejlfinding i WAF og opsætning af rate limiting i deres dokumentation om WAF troubleshooting og rate limiting rulesets. I praksis bør du teste regler i log- eller simuleringsfase først, så legitime administratorer og checkout-brugere ikke bliver blokeret ved en fejl.

4. Hærd filsystemet og PHP-eksekvering

En klassisk følge af kompromitterede sites er ondsindede PHP-filer placeret i upload-mapper eller i skjulte undermapper under wp-content. Derfor bør hardening også omfatte filrettigheder, eksekveringskontrol og tydelig adskillelse mellem kode og brugerindhold. Uploads bør ikke kunne afvikle vilkårlig PHP-kode.

Sørg for korrekte filrettigheder efter princippet om mindst mulige privilegier.
Undgå at webserverbrugeren har skriveadgang til hele applikationen.
Blokér PHP-eksekvering i upload-mapper, hvis webserveropsætningen tillader det.
Hold brugerdefineret kode i versionsstyring, så ændringer kan spores og genskabes.

Eksempel for Nginx-konfiguration, der afviser PHP-kørsel i uploads:
location ~* /wp-content/uploads/.*.php$ {
    deny all;
    return 403;
}

Konfigurationen skal testes i staging før udrulning, fordi enkelte plugins kan være bygget forkert og forvente eksekvering i mapper, der burde være dataområder. Hvis en sådan afhængighed findes, er det normalt et tegn på dårlig arkitektur og bør vurderes kritisk.

5. Brug logs aktivt: uden logning bliver fejlfinding gætteri

Når et site returnerer 500-fejl, hvide sider, intermitterende checkout-fejl eller uventede redirects, er PHP- og webserverlogs ofte den hurtigste vej til årsagen. PHP’s egen dokumentation om diagnostic errors og error reporting understreger, at fejl skal logges sikkert og ikke vises åbent i produktion.

Vis ikke detaljerede PHP-fejl til besøgende i produktion.
Log fejl til fil eller central logløsning med passende adgangskontrol.
Overvåg access logs for gentagne 401, 403, 404 og POST-anmodninger mod login- og XML-RPC-endpoints.
Korrelér applikationsfejl med deploys, plugin-opdateringer og ændringer i cache eller firewall.

Sikker grundidé i produktion:
display_errors = Off
log_errors = On
error_reporting = E_ALL

I WordPress kan du supplere med applikationsnær fejlfinding, men undgå at lade debug-output være aktivt permanent på live-sitet. Fejllogs er især vigtige på WooCommerce-installationer, hvor fejl i sessions, object cache, cronjobs eller tredjeparts-API’er kan være vanskelige at opdage uden systematisk loganalyse.

6. Backup er kun værdifuld, hvis gendannelse er testet

Backup omtales ofte som en checklistepost, men i drift er det en gendannelsesdisciplin. En brugbar WordPress-backup skal mindst omfatte database, uploads, temaer, plugins, specialkode og centrale konfigurationsfiler. På webshops bør du desuden kende konsekvensen af datatab mellem backup-tidspunkt og gendannelse, især for ordrer og kundedata.

Opbevar backups uden for samme server eller konto som produktionen.
Test gendannelse til staging med faste intervaller.
Dokumentér restore-proceduren, så den kan udføres under tidspres.
Fastlæg retention efter forretningsbehov og datamængde.

Ved malware-hændelser er backup ikke altid nok. Hvis kompromitteringen har været til stede længe, kan backup-kæden også være forurenet. Derfor bør gendannelse kombineres med filgennemgang, nulstilling af credentials, opdatering af sårbare komponenter og validering af bruger- og administratorlister.

7. Overvågning og baseline gør drift mere forudsigelig

Mange driftsproblemer bliver først opdaget af kunderne. Det er for sent. Basal serverovervågning bør omfatte oppetid, svartider, CPU, RAM, disk, databaseforbindelser, PHP workers og fejlrate. På WordPress-sites med høj belastning kan ændringer i cache, bottrafik eller cronjob-adfærd hurtigt forværre performance og skabe sekundære sikkerhedsproblemer som timeout ved checkout eller mislykkede webhooks.

Etabler baseline for normal CPU-, RAM- og svartidsprofil.
Mål login-fejl, 5xx-fejl og usædvanlige trafikspidser.
Gennemgå cronjobs, kø-systemer og eksterne API-kald ved pludselige performancefald.
Kombinér overvågning med alarmer, der er justeret, så de giver signal og ikke støj.

Hvis du bruger persistent object cache, kan den forbedre svartider markant, men den kan også komplicere fejlfinding ved cache-inkonsistens. Se også vores interne guide WordPress Object Cache – Skal du vælge Redis eller Memcached? for driftsmæssige overvejelser omkring cachelag.

8. SSL, TLS og sikre forbindelser er grundlaget for resten

Et WordPress-site bør altid køre over HTTPS, og administrative områder, login og checkout må ikke være tilgængelige uden kryptering. SSL/TLS løser ikke sårbarheder i applikationen, men det beskytter transportlaget og er et minimumskrav for sikker drift, især ved login, formularer og transaktioner.

Hvis du mangler en praktisk introduktion til certifikater og HTTPS, kan du læse vores interne artikel SSL certifikat guide. I driftssammenhæng bør du desuden kontrollere automatisk certifikatfornyelse, mixed content efter migreringer og korrekt håndtering af reverse proxy eller CDN foran origin-serveren.

9. Når skaden er sket: en sikker hændelsesprocedure

Ved mistanke om WordPress malware eller kompromittering bør første mål være afgrænsning og bevisbevarelse, ikke hurtig kosmetisk oprydning. Sæt sitet i vedligeholdelsestilstand, begræns adgang hvis nødvendigt, tag kopi af filer og logs, og kortlæg ændringer i administratorbrugere, cronjobs, uploads og ukendte PHP-filer. Derefter følger patching, credential-rotation, gendannelse og validering.

Skift adgangskoder til WordPress, hostingpanel, database, SFTP/SSH og relaterede API-nøgler.
Opdater eller fjern den komponent, der sandsynligvis muliggjorde kompromitteringen.
Sammenlign filsystemet med kendte gode versioner fra versionsstyring eller rene pakker.
Kontrollér brugertabeller, planlagte opgaver, .htaccess, wp-config.php og uploads for uautoriserede ændringer.

Hvis problemet er spamkonti eller misbrug af registreringsformularer, kan målrettet botbeskyttelse og strammere registreringsflow være mere effektivt end brede blokeringer. Se også den interne vejledning Sådan stopper du spam brugerregistrering i WordPress som supplement til login- og formularbeskyttelse.

Konklusion

Effektiv WordPress hardening kræver en driftsmæssig tilgang. Det er kombinationen af hurtige sikkerhedsopdateringer, begrænset adgang, kontrolleret PHP-eksekvering, gode logs, testede backups, WAF og overvågning, der gør forskellen. For WordPress- og WooCommerce-miljøer er målet ikke kun at undgå kompromittering, men at gøre fejl, misbrug og nedbrud hurtigere at opdage, lettere at afgrænse og sikrere at rette. Den mest robuste løsning er derfor sjældent et enkelt sikkerhedsplugin, men en dokumenteret og gentagelig driftspraksis.