Beskyt dit WordPress Site

Hvad testen indeholder

Denne sikkerhedstest analyserer en WordPress-installations opsætning, headers, filadgang og konfiguration for at identificere svagheder, misconfigurations og forbedringsmuligheder. Nedenfor gennemgås alle testområder med forklaring.

WordPress-detektion

Testen analyserer HTML-output for at afgøre, om websitet kører WordPress, ved at lede efter karakteristiske elementer som wp-content, wp-includes og generator-meta-tags. Dette afgør, om de efterfølgende WordPress-specifikke tests er relevante.

WordPress versionskontrol

Hvis WordPress detekteres, forsøger testen at udtrække versionsnummeret. Versionen sammenholdes med den nyeste tilgængelige fra WordPress.org API. Uforældede installationer er en væsentlig risiko, fordi ældre versioner ofte indeholder kendte sikkerhedshuller.

Herudover tjekkes versionen specifikt op imod CVE-2026-63030 / CVE-2026-60137 (“wp2shell”) – en kritisk, aktivt udnyttet sårbarhedskæde i WordPress-kernen, der giver uautoriseret fjernkørsel af kode via REST API’ets batch-endpoint, uden krav om login eller sårbare plugins. Sites på version 6.9.0–6.9.4 eller 7.0.0–7.0.1 er fuldt sårbare og markeres Kritisk med opfordring til øjeblikkelig opdatering til 6.9.5/7.0.2 eller nyere. Sites på 6.8.0–6.8.5 er ramt af den underliggende SQL-injection-del af kæden og bør opdatere til 6.8.6 eller nyere. Dette tjek er uafhængigt af den generelle “er kernen forældet”-vurdering, da alvoren her er markant højere end en almindelig manglende opdatering.

SSL/HTTPS og certifikatkontrol

Analysen tjekker om websitet benytter HTTPS. Hvis ja, hentes certifikatets metadata direkte fra serveren: udsteder, gyldighedsperiode og eventuelle udløbsadvarsler. Manglende eller udløbende certifikater kan kompromittere data mellem bruger og server.

Caching og CDN

Testen analyserer HTTP-headere for tegn på edge- og page-caching samt brug af CDN-lag. Der kigges efter typiske headers som CF-Cache-Status (Cloudflare), X-Cache, X-LiteSpeed-Cache, X-Var­nish, Age m.fl. Hvis der registreres cache-HIT-responser, indikerer det, at websitet udnytter en effektiv cache- eller CDN-konfiguration, hvilket reducerer svartid og serverbelastning. Manglende cache-indikatorer betyder ikke nødvendigvis, at der slet ikke er caching, men at det ikke kan bekræftes via standard-headere udefra. Bemærk, at testen kun vurderer HTTP-baseret caching (edge/page cache) og ikke kan se server-interne mekanismer som Redis eller anden persistent object cache.

HTTP → HTTPS-omdirigering

Testen tilgår websitet direkte via http:// og kontrollerer, om serveren automatisk omdirigerer (301/302/307/308) til https://. Dette adskiller sig fra selve SSL-tjekket, som kun bekræfter, at certifikatet er gyldigt, hvis brugeren allerede er på en https-adresse. Uden en tvungen omdirigering risikerer besøgende, links og bots at ende på en usikker forbindelse, selvom certifikatet er korrekt opsat.

HSTS (Strict-Transport-Security)

Testen kontrollerer om HSTS-headeren er sat, og om den har en tilstrækkelig max-age, samt om includeSubDomains og eventuelt preload er aktiveret. HSTS tvinger browseren til kun at bruge HTTPS og forhindrer downgrade-angreb som SSL Stripping.

Server- og PHP-versionslækage

Testen undersøger Server– og X-Powered-By-headerne. Hvis disse indeholder specifikke versionsnumre (fx Apache- eller PHP-version), får en angriber let overblik over hvilke kendte sårbarheder der potentielt kan udnyttes. Det anbefales at skjule denne information via hosting-panel, serverkonfiguration eller expose_php = Off.

WP_DEBUG og synlige PHP-fejl

HTML-output scannes for synlige PHP-fejl (Notice, Warning, Deprecated), som indikerer fejlkonfiguration og læk af intern information. Testen tjekker også om debug.log er offentligt tilgængelig — en ofte overset risiko.

debug.log synlighed

Testen forsøger at indlæse wp-content/debug.log. Hvis den kan tilgås, kan følsomme oplysninger såsom databasefejl, stioplysninger og plugin-fejl være lækket.

Permissions-Policy header

Denne moderne header styrer adgangen til funktioner som kamera, mikrofon, geolocation og bevægelsessensorer. Mangler headeren, kan browseren potentielt give flere tilladelser end nødvendigt.

Content-Security-Policy (CSP)

Testen gennemgår websitets CSP og vurderer, om den er sat, samt om den indeholder svækkelser som 'unsafe-inline' eller 'unsafe-eval'. CSP beskytter mod XSS og clickjacking. Testen straffer dog ikke moderne WordPress-opbygninger med Elementor, som bruger 'unsafe-inline' og 'unsafe-eval'.

Primære sikkerhedsheadere

• X-Content-Type-Options: Forhindrer MIME-sniffing.
• Referrer-Policy: Kontrollerer hvor mange referrer-oplysninger browseren sender.
• X-Frame-Options: Legacy clickjacking-beskyttelse.
• X-XSS-Protection: Legacy header som moderne browsere ignorerer.

Moderne browserisolation (COOP, COEP, CORP)

Disse headere beskytter mod avancerede angreb som Spectre og styrer om websitet må dele browsing-kontekst med andre websites.

• Cross-Origin-Opener-Policy (COOP)
• Cross-Origin-Embedder-Policy (COEP)
• Cross-Origin-Resource-Policy (CORP)

Cookies og sessionbeskyttelse

Session- og login-cookies analyseres for tre vigtige flags:

• Secure – må kun sendes over HTTPS
• HttpOnly – må ikke læses via JavaScript (forhindrer XSS misbrug)
• SameSite – reducerer CSRF-angreb

XML-RPC adgang

XML-RPC har historisk været et mål for brute-force og DDoS-angreb. Testen sender en forespørgsel til xmlrpc.php og bekræfter et gyldigt XML-RPC-svar (ikke blot at filen returnerer indhold), for at undgå falske positiver fra tilpassede fejl- eller blokeringssider. Solid Security og andre plugins styrer ofte dette.

Følsomme filer

Testen forsøger at detektere om kritiske filer som wp-config.php, .htaccess, readme.txt, readme.html og install.php utilsigtet returnerer HTTP 200 med reelt indhold. Eksponerede filer kan afsløre credentials eller versionsinformation.

.git-mappe eksponering

Testen tjekker om .git/config er offentligt tilgængelig. Dette opstår typisk, når et Git-repository ved en fejl uploades sammen med sitets filer ved deploy. Er mappen åben, kan en angriber ofte downloade hele kildekoden og commit-historikken, herunder tidligere versioner af filer der kan indeholde nøgler eller adgangskoder.

.env-fil eksponering

Testen tjekker om en .env-fil er offentligt tilgængelig i webroden. Sådanne filer bruges ofte af Composer- eller dotenv-baserede plugins/temaer til at gemme miljøvariabler og kan indeholde database-adgangskoder, API-nøgler og andre hemmeligheder, hvis de ikke er korrekt beskyttet mod direkte webadgang.

Brugerenumerering via ?author=1

Testen tilgår /?author=1 og undersøger, om WordPress omdirigerer til en URL af typen /author/brugernavn/. Dette er en klassisk metode til at afsløre gyldige brugernavne (typisk administratorens), som efterfølgende kan bruges i brute-force-angreb mod login. Tjekket er uafhængigt af, om REST API’ets brugerliste er lukket, da metoden udnytter WordPress’ egen forfatter-arkivfunktion.

Directory browsing

Tjekker om der er åben mappelisting i wp-content/uploads. Det kan give angribere indsigt i filstrukturer og uforventede uploads.

REST API (generel adgang)

Testen undersøger om /wp-json/ er offentligt tilgængelig. Det er normalt for WordPress, men det giver indblik i plugins, endpoints og serverinformation.

REST API – brugerliste

Specifikt analyseres /wp-json/wp/v2/users. Hvis endpointet returnerer offentlige brugerlister, kan angribere bruge det til “username harvesting”. Hvis det returnerer 401/403 er det korrekt beskyttet.

security.txt

Tjekker om /.well-known/security.txt findes. Der angives kontaktinformation for sikkerhedsresearchere, og filen er et moderne “best practice” signal for ansvarlig sikkerhedshåndtering.