🔒 WordPress-sikkerhet i 2026: en komplett guide til nettstedbeskyttelse

Et WordPress-nettsted blir hacket, ikke fordi motoren er «full av hull». Det blir hacket fordi eieren utsatte en plugin-oppdatering, satte passordet admin123 og lot xmlrpc.php stå åpen. Automatiserte boter skanner internett kontinuerlig.

De bryr seg ikke om du selger håndlagde lys eller driver en nettbutikk. De vil finne og utnytte sårbarheten. Innloggings-brute force, SQL-injeksjon, shell-opplasting via en sårbar plugin, alt dette foregår døgnet rundt.

Den gode nyheten: du kan bygge grunnleggende beskyttelse på en kveld, uten dyp teknisk kunnskap. Nedenfor finner du et utprøvd sett med tiltak, fra installasjon av en brannmur til manuell herding av serveren. Alt som beskrives her, bruker vi på våre egne prosjekter.

💡 Rask oversikt:

• Installer en brannmur: BBQ eller Wordfence, den første forsvarslinjen blokkerer de fleste angrep før de i det hele tatt når WordPress.
• Steng typiske inngangspunkter: xmlrpc.php, REST API for uautentiserte brukere, mappelisting, filredigeringsverktøyet i administrasjonspanelet.
• Konfigurer automatiske oppdateringer for kjerne, temaer og plugin-er. En utdatert plugin-versjon er den viktigste angrepsvektoren.
• Ta en sikkerhetskopi som lagres UTENFOR serveren. Uten en sikkerhetskopi betyr gjenoppretting etter et hack at du må installere WordPress på nytt fra bunnen av.
• Aktiver tofaktorautentisering for alle administratorer. Et passord kan gjettes; en ekstra faktor kan det ikke.

Hvor de treffer først: typiske angrepsvektorer

De fleste ser for seg en hacker som sitter ved en terminal og manuelt gjetter administratorpassordet. Virkeligheten er mer prosaisk: praktisk talt alle angrep utføres av boter som følger et skript. De leter etter kjente sårbarheter i plugin-er og temaer, banker på xmlrpc.php, skanner /wp-content/uploads/ etter kjørbare PHP-filer.

De viktigste angrepsvektorene mot WordPress:

• Utdaterte plugin-er og temaer. Ifølge rapporter fra Sucuri brukte omtrent 40% av hackede nettsteder en utdatert versjon av CMS-et, en plugin eller et tema på infeksjonstidspunktet. Utviklere tetter hull med patcher, men bare hvis du tar i bruk disse patchene.

• Svake passord. Brute force-angrep prøver titusenvis av kombinasjoner i minuttet. Et passord på 6 tegn uten spesialtegn knekkes umiddelbart.

• Usikker hosting. Billig delt hosting sparer på kontoisolering: hvis et nabonettsted på serveren blir hacket, kan angrepet smitte over på ditt.

• For vide skrivetillatelser. Når webserveren kan skrive til enhver fil, får et shell lastet opp via et hull full kontroll over nettstedet.

Å forstå disse vektorene er halve forsvaret. Den andre halvdelen er konkret handling.

Nivå 1: rask beskyttelse du kan sette opp på en halvtime

Det er her du bør starte i dag. Hver handling tar minutter, krever ingen kodeendringer og vil ikke ødelegge nettstedet ditt.

Installer en brannmur: BBQ Firewall

BBQ Firewall er en plugin av Jeff Starr som fungerer etter «sett og glem»-prinsippet. Ingen innstillinger, ingen inngrep i .htaccess eller databasen. Den blokkerer rett og slett ondsinnede URL-forespørsler før de når WordPress: eval(), base64_decode, overdrevent lange strenger, injeksjonsforsøk.

Pluginen veier under 10 KB og skaper ingen belastning. Samtidig fanger den opp SQL-injeksjon, XSS, opplasting av kjørbare filer og angrep via «dårlige» referrers.

I praksis installeres BBQ ofte OPPÅ Wordfence eller Solid Security; de løser ulike problemer og kommer ikke i konflikt. En brannmur på forespørselsnivå pluss en fullverdig sikkerhetsplugin gir deg lagdelt forsvar.

Aktiver tofaktorautentisering

Et passord kan gjettes, avlyttes eller kjøpes i en dump av lekke databaser. En ekstra faktor, en engangskode fra en autentiseringsapp, ødelegger hele matematikken bak brute force-angrep.

WordPress har ingen innebygd 2FA. Den enkleste veien er å installere Solid Security (tidligere iThemes Security) eller Wordfence. Begge inkluderer 2FA i gratisversjonen. Etter aktivering går du til Sikkerhet → Innstillinger → Tofaktorautentisering og aktiverer det for administratorrollen.

Disse samme plugin-ene lukker et dusin flere sårbarheter ut av boksen:

• Solid Security: endrer innloggings-URL-en (/wp-admin → din unike slug), setter en grense for innloggingsforsøk, skanner filer for endringer, blokkerer IP-er etter en serie mislykkede innlogginger, sjekker plugin-er og temaer for kjente sårbarheter.

• Wordfence: Web Application Firewall med automatisk oppdaterte regler, skanner for skadevare, brute force-beskyttelse, sanntids trafikkovervåking. Den er spesielt god til å rense et allerede hacket nettsted: den finner bakdører, modifiserte kjernefiler, skjult spam.

Du trenger bare ÉN av dem. På våre prosjekter installerer vi Wordfence + BBQ: den første gir en WAF og skanner, den andre kutter bort søppelforespørsler før de i det hele tatt kommer nær.

Deaktiver xmlrpc.php

XML-RPC er et grensesnitt for eksternt arbeid med WordPress via mobilapper og trackbacks. I dag trenger de aller fleste nettsteder det ikke, likevel er det fortsatt et av de mest angrepne punktene: boter bruker xmlrpc.php til å brute force-passord og gjennomføre DDoS-angrep.

Du kan deaktivere det på to måter. Den raske måten, via en plugin: Solid Security gjør det med ett klikk. Den skikkelige måten, på servernivå, i .htaccess:

1
<Files xmlrpc.php>
2
Order Deny,Allow
3
Deny from all
4
</Files>

Legg til denne blokken i rot-.htaccess og glem xmlrpc. Hvis du bruker WordPress-mobilappen eller eksterne tjenester som trenger XML-RPC, sjekk først om de fungerer uten. I 2026 dekker alternativer, REST API med autentisering, nesten alle scenarioer.

Deaktiver mappelisting

Åpne вашсайт.com/wp-content/uploads/ i nettleseren din. Hvis du ser en liste over filer, har du et problem. Mappelisting viser nettstedets struktur til alle som gidder å se etter.

Løsningen: én linje i .htaccess:

1
Options -Indexes

Legg også til en tom index.php i alle mistenkelige mapper: /wp-content/uploads/, temaer, utvidelser som mangler sin egen index.php.

Deaktiver filredigering i administrasjonspanelet

WordPress leveres med muligheten til å redigere tema- og utvidelsesfiler .php direkte fra administrasjonspanelet: Utseende → Temafilredigering og Utvidelser → Utvidelsesfilredigering. Praktisk, helt til noen uautoriserte får tilgang til administrasjonspanelet. Da blir det et ferdig verktøy for å laste opp et shell.

Legg til én konstant i wp-config.php:

1
define('DISALLOW_FILE_EDIT', true);

Det er alt. Redigeringsverktøyet forsvinner fra administrasjonspanelet. Bruk FTP/SFTP for å redigere filer, mindre praktisk, men sikrere.

Nivå 2: manuell WordPress-herding

Følgende tiltak går litt dypere: de krever redigering av konfigurasjonsfiler og forståelse av serverstrukturen. Resultatet er et nettsted som boter går forbi fordi de ikke ser WordPress i det.

Oppdater sikkerhetssalter

Salter, sikkerhetsnøkler og salter, åtte linjer i wp-config.php som krypterer autentiseringsinformasjonskapsler. Å endre dem logger alle ut umiddelbart, inkludert en potensiell angriper med en stjålet økt.

Gå til api.wordpress.org/secret-key/1.1/salt/, kopier den genererte blokken og erstatt den tilsvarende seksjonen i wp-config.php med den. Tar ett minutt. Gjør dette når du mistenker et kompromiss.

Endre databasetabellprefikset

Som standard heter alle WordPress-tabeller wp_posts, wp_users og wp_options. SQL-injeksjoner er ofte skreddersydd for standardprefikset.

På en fersk installasjon, spesifiser et ikke-standard prefiks i wp-config.php:

1
$table_prefix = 'wp83x_';

For et eksisterende nettsted er det vanskeligere å endre det: du må gi nytt navn til tabeller i databasen og oppdatere verdier i usermeta og options. Ikke forsøk dette uten solide phpMyAdmin- og SQL-ferdigheter, risikoen for å ta ned nettstedet er for høy.

Flytt wp-config.php over webroten

wp-config.php inneholder databasepassordet og krypteringsnøkler. Hvis webserveren ved et uhell serverer den som ren tekst, noe som skjer under en mislykket PHP-oppdatering, får angriperen alt.

Løsning: flytt wp-config.php ett nivå over nettstedets rotkatalog, for eksempel fra /public_html/ til hjemmemappen for hostingen. WordPress ser automatisk etter konfigurasjonen i den overordnede katalogen, koden vil ikke slutte å virke.

Skjul WordPress-versjonen

Generator-meta-taggen <meta name="generator" content="WordPress X.X.X"> i sidekilden er en gave til boter. De matcher versjonen mot en database med kjente sårbarheter og slår til med presisjon.

Fjern generatoren via functions.php:

1
// Remove the WordPress generator meta tag from the page source code
2
function no_generator() {
3
    return '';
4
}
5
add_filter('the_generator', 'no_generator');

Funksjonen no_generator() returnerer en tom streng i stedet for standard versjonsutdata. Filteret the_generator fanger opp utdataene fra meta-taggen og alle dens variasjoner, for feeds, RSS og REST API-et.

Slett også readme.html og liesmich.html fra installasjonsroten, de avslører også versjonen. Etter en WordPress-oppdatering kan disse filene dukke opp igjen, sjekk én gang i måneden.

Konfigurer HTTP-sikkerhetsheadere

HTTP-responsheadere forteller nettleseren hvordan innhold skal håndteres. Riktig konfigurerte sikkerhetsheadere blokkerer clickjacking, XSS og innholdsforfalskning.

Et minimalt sett for WordPress, legg til disse linjene i .htaccess:

1
Header set X-Frame-Options "SAMEORIGIN"
2
Header set X-Content-Type-Options "nosniff"
3
Header set Referrer-Policy "strict-origin-when-cross-origin"
4
Header set X-XSS-Protection "1; mode=block"

Utvidelsen HTTP Headers lar deg gjøre det samme via administrasjonspanelet hvis du helst ikke vil røre serverkonfigurasjonen.

For avansert konfigurasjon, bruk Content Security Policy. Men merk: en feilaktig CSP ødelegger administrasjonspanelet, skriftlasting og utvidelsesfunksjonalitet. Rull den ut gradvis, start med Content-Security-Policy-Report-Only-modus.

Begrens filtillatelser

Tillatelser, den siste forsvarslinjen. Hvis en angriper laster opp en fil, men ikke kan kjøre den, stopper angrepet opp.

Grunnleggende regler:

• Mapper: 755, eier leser, skriver, kjører; gruppe og andre leser og kjører.
• Filer: 644, eier leser og skriver, andre bare leser.
• wp-config.php: 400, bare eieren leser.
• .htaccess: 444, skrivebeskyttet for alle, hvis WordPress ikke redigerer den automatisk.

Unngå absolutt 777. Ja, noen utvidelser ber om 777 på wp-content/uploads/. Ikke gi det. 755 på mappen og 644 på filer inni er nok for medieopplastinger.

Hva du skal gjøre hvis nettstedet allerede er hacket

Et hack oppdages på forskjellige måter: en omdirigering til et kasino, spam-utsendelse, et banner med «Dette nettstedet kan være hacket» i Googles søkeresultater, en klage fra hostingleverandøren. Rekkefølgen på handlinger:

• Endre alle passord umiddelbart: WordPress-admin, FTP/SFTP, database, vertskapskontrollpanel. Start med det siste. Hvis hackeren er i vertskapskontrollpanelet, vil de bare opprette en ny admin.

• Gjenopprett nettstedet fra en sikkerhetskopi tatt FØR hacket. En nylig sikkerhetskopi tatt etter kompromisset inneholder mest sannsynlig en bakdør. Hvis det ikke finnes noen sikkerhetskopi, neste steg.

• Installer Wordfence og kjør en full skanning. Utvidelsen vil finne modifiserte kjernefiler, mistenkelig kode, skjulte bakdører. Slett alt skanneren flagget, og erstatt deretter WordPress-kjernen med en fersk kopi: «Installer på nytt»-knappen under Dashbord → Oppdateringer.

• *Sjekk wp-content/uploads/ for .php-filer.* De hører ikke hjemme der. Enhver .php-fil i opplastingsmappen er nesten helt sikkert et shell.

Se videoen over, den bryter ned typiske WordPress-sikkerhets-feil og hvordan du fikser dem, fra svake passord til feil filtillatelser.

• Koble til ekstern overvåking. Sucuri, en skytjeneste med WAF og et responsteam. WAF-en filtrerer trafikk før den når serveren. Ved et innbrudd rydder Sucuri-teamet nettstedet i løpet av timer. Prisen starter på $199/år for grunnpakken med opprydding og overvåking. Ikke gratis, men når et nettsted genererer inntekter, koster nedetid mer.

Sørg for å registrere nettstedet ditt i Google Search Console. Hvis Google oppdager skadelig kode, får du et varsel før nettstedet faller ut av søkeresultatene.

Beskyttelse mot løsepengevirus: hvorfor sikkerhetskopier løser alt

Løsepengevirus krypterer nettstedets filer og krever løsepenger. WordPress-nettsteder er et hyppig mål: ordrer, kundedatabaser, innhold. Å miste alt over natten er et reelt scenario uten en sikkerhetskopi.

Tre regler:

• Sikkerhetskopi utenfor serveren. Sky eller en separat FTP. UpdraftPlus og Duplicator automatiserer overføringen.
• Brannmur og skanner. Wordfence + BBQ blokkerer ondsinnede filopplastinger på forespørselsstadiet.
• Kun offisielle kilder. WordPress.org-katalogen og utviklernettsteder med et godt rykte. Ingen «gratis» temaer fra torrents.

Automatisk overvåking av filintegritet

Beskyttelse på tjenersiden, ikke en engangshandling. Sett sammen sjekker i et shell-skript på cron, én gang om dagen, resultater til e-post:

1
SITE_ROOT="/absolute/path/to/public_html"
2
 
3
find "$SITE_ROOT" -mtime -1 -name "*.php" \
4
    -printf '%TY-%Tm-%Td %TT\t%p\n' >> /tmp/file-changes.log
5
 
6
find "$SITE_ROOT" -mtime -7 -name "*.php" \
7
    | xargs grep -l -i "eval\|base64_decode\|iframe\|file_get_contents" \
8
    >> /tmp/suspicious-code.log
9
 
10
find "$SITE_ROOT/wp-content/uploads" -name "*.php" -print \
11
    >> /tmp/php-in-uploads.log
12
 
13
find /home -type d -perm 0777 >> /tmp/perms.log
14
find /home -type f -perm 0777 >> /tmp/perms.log
15
 
16
mailx -s "Webserver File Audit $(date +%F)" admin@example.com \
17
    < /tmp/suspicious-code.log

Skriptet kjøres én gang daglig via cron. Den første blokken find -mtime -1 viser PHP-filer endret siste døgn, den primære inntrengningsdetektoren. Den andre ser etter shell-signaturer: eval, base64_decode, skjulte iframes. Den tredje fanger PHP i opplastingsmappen, der legitim PHP aldri hører hjemme. Den fjerde finner filer og mapper med 777-rettigheter. Resultatet sendes til e-post. Proaktiv overvåking fanger et inntrenging på et tidlig stadium, før Google legger merke til det og utestenger nettstedet fra søkeresultatene.

Sucuri: en skybrannmur for når du ikke har tid til å skru

Slik fungerer det: trafikk går gjennom Sucuris skyproxy med en WAF, ondsinnede forespørsler blokkeres før de når hostingen. Nettstedet laster raskere takket være CDN-et. Nøkkelfunksjoner: en WAF med sanntidssignaturer, DDoS-beskyttelse, automatisk opprydding av skadevare.

Pakker starter på $199/år. Det finnes ingen gratisversjon, men Sucuri-skannerpluginen sjekker filer for endringer uten WAF-en. For et kommersielt nettsted er det en berettiget investering. For en personlig blogg er Wordfence + BBQ nok.

⁉️🤔 FAQ

Er WordPress i seg selv sikkert?

WordPress-kjernen gjennomgås av hundrevis av utviklere og sikkerhetsrevisorer. Problemet er ikke kjernen; problemet er utdaterte utvidelser, temaer fra upålitelige kilder og passord som 123456. Regelmessige oppdateringer pluss en grunnleggende brannmur gir tilstrekkelig beskyttelse for de fleste nettsteder.

Kan jeg klare meg uten sikkerhetsutvidelser?

Det kan du, hvis du er villig til å manuelt konfigurere en brannmur på servernivå: iptables, mod_security, 7G/8G Firewall i .htaccess, spore CVE-er for hver utvidelse og skrive cron-skript for overvåking. For alle andre er installasjon av Wordfence eller Solid Security én time kontra dusinvis av timer med manuelt arbeid.

Er oppdateringer nødvendige hvis en brannmur er på plass?

Ja, absolutt. En brannmur blokkerer angrep utenfra, men hvis en utvidelse med et kjent sikkerhetshull er installert, vil det før eller siden bli funnet en angrepsvektor som brannmuren ikke fanger opp. Oppdatering av alle WordPress-komponenter er grunnmuren som andre tiltak virker med halv styrke uten.

Hvilken sikkerhetsutvidelse bør jeg velge?

For minimal beskyttelse: BBQ Firewall, blokkerer ondsinnede URL-forespørsler, null konfigurasjon. For full beskyttelse: Wordfence, WAF, skanner, tofaktorautentisering, beskyttelse mot brute force-angrep, alt i gratisversjonen. Kombinasjonen BBQ + Wordfence dekker begge lag uten konflikter.

Hva med REST API-et, bør jeg deaktivere det?

REST API-et er nødvendig for WordPress for Gutenberg-blokkredigereren, en rekke utvidelser og eksterne integrasjoner. Å deaktivere det fullstendig vil ødelegge administrasjonspanelet. Begrens i stedet tilgangen: la bare offentlige endepunkter være åpne for uautentiserte brukere. Utvidelsen REST API Toolbox lar deg fleksibelt konfigurere tilgang uten kirurgiske inngrep.

Hvor ofte bør jeg skanne nettstedet for virus?

Automatisk, daglig via cron-skript: sjekke etter endrede filer, se etter .php i opplastinger. Manuelt, én gang i måneden: gå inn i Wordfence, kjør en full skanning, sjekk utvidelseslisten for forlatte utvidelser. Ingen oppdateringer på over ett år, slett eller erstatt.

Kan jeg miste Google-rangeringer på grunn av et hack?

Det kan du, og raskt. Google skanner nettsteder for ondsinnet kode og flagger infiserte med en advarsel i søkeresultatene. Hvis hacket ikke fikses innen noen få uker, blir nettstedet avindeksert. Registrer nettstedet ditt i Google Search Console, så får du et varsel om problemet så snart det oppdages.

Vil det å bytte host hjelpe med å forhindre hack?

Delvis. Kvalitetshosting legger til sine egne lag: kontoisolering, nettverksovervåking, automatisk oppdatering av PHP. Men hosting beskytter ikke mot en lekk utvidelse du installerte selv, eller passordet qwerty. Sikkerhet er en lagkake: hosting pluss oppdateringer pluss brannmur pluss tilgangsrettigheter pluss sikkerhetskopier.

WordPress-sikkerhet: hvor du bør starte i dag

Hovedregelen for WordPress-sikkerhet er å ikke prøve å takle alt på én gang. Start med tre steg:

• Hvis det ikke finnes noen brannmur, installer BBQ Firewall. Ett minutt.
• Hvis det ikke finnes sikkerhetskopier utenfor serveren, sett opp UpdraftPlus med skyopplasting. Ti minutter.
• Hvis tofaktorautentisering ikke er aktivert for administratorer, aktiver det via Wordfence. Fem minutter.

Kom så tilbake til listen ovenfor: deaktiver xmlrpc, oppdater salter, deaktiver filredigereren, konfigurer sikkerhetsheadere. Ett punkt om dagen, og i løpet av en uke vil nettstedet ditt være en størrelsesorden bedre beskyttet enn det var i går.

Hvilke sikkerhetstiltak fungerer allerede på ditt nettsted? Fortell meg i kommentarene, jeg er nysgjerrig på å sammenligne tilnærminger.