Stenge WordPress XML-RPC: Den Raskeste Måten å Beskytte Mot Brute Force Angrep

Å stenge WordPress XML-RPC er en prosess som hindrer xmlrpc.php-filen på nettstedet ditt fra å motta forespørsel eksternt, noe som raskt reduserer brute force-forsøk, misbruk av pingback og unødvendig bot-trafikk. Hvis du ikke bruker Jetpack, WordPress mobilapp, gamle eksterne publiseringsverktøy eller en spesialtilpasset integrasjon som benytter XML-RPC, er det trygt og praktisk å stenge XML-RPC som et sikkerhetstiltak for de fleste WordPress-nettsteder. Den mest effektive metoden er å blokkere forespørselen på servernivå før WordPress prosesserer den; det vil si å hindre tilgang til xmlrpc.php med Apache, LiteSpeed, Nginx eller en WAF-regel er vanligvis mer effektivt enn å stenge det med et plugin.

I denne guiden vil du trinn for trinn finne ut hvorfor du bør stenge WordPress XML-RPC, når du ikke bør stenge det, og hvordan du sikkert kan implementere det i ulike servermiljøer. Det spiller ingen rolle om du jobber med Hostragons infrastruktur eller en annen hostingløsning; målet er å redusere angrepsflaten uten å bryte nettstedet, redusere unødvendig ressursforbruk og etablere en håndterbar sikkerhetsstandard. Hvis du leter etter et raskt og sikkert fundament når du hoster WordPress-nettstedet ditt, er WordPress hosting valget en viktig del av denne prosessen.

Hva er XML-RPC og hva brukes det til i WordPress?

XML-RPC er en eldre protokoll for ekstern kommunikasjon som lar forskjellige systemer kommunisere med hverandre ved å sende data i XML-format over HTTP. På WordPress-siden utføres denne funksjonen vanligvis via xmlrpc.php-filen i rotmappen. Historisk sett har denne filen blitt brukt for publisering av innlegg fra WordPress mobilapp, ekstern kommentaradministrasjon, pingback og interaksjon med noen tredjeparts tjenester.

I det moderne WordPress-økosystemet har REST API blitt mye mer utbredt, noe som har redusert viktigheten av XML-RPC. Likevel er filen fortsatt tilgjengelig i mange installasjoner. Dette betyr at den er lett oppdagelig for angripere, med en standard tilgangsvei og mulighet for automatisering. Spesielt kan botter som skanner tilfeldige IP-adresser prøve xmlrpc.php-adressen i løpet av minutter, selv om domenet ditt er nyopprettet. Derfor er det viktig å tenke på sikkerhetsgrunnlaget fra starten av når du lanserer ditt nye domene med Domenesjekk.

Når kan XML-RPC være nødvendig?

XML-RPC er ikke unødvendig for alle nettsteder. Noen eldre funksjoner i Jetpack, spesifikke prosesser i WordPress mobilapp, noen automatiseringstjenester eller eldre skrivebordsbloggeditorer kan ha behov for XML-RPC. I tillegg kan spesialtilpassede integrasjoner bruke xmlrpc.php for innholdslevering eller ekstern datainnhenting. Derfor er det nødvendig å sjekke arbeidsflyten på nettstedet ditt før du stenger det.

En praktisk sjekk er: Hvis du bare legger inn innhold på nettstedet ditt via wp-admin-panelet, ikke bruker Jetpack, ikke publiserer fra mobilappen, og utvikleren din ikke har installert en spesialtilpasset XML-RPC-integrasjon, er det sannsynlig at du ikke trenger XML-RPC. Mange bedriftsnettsteder, blogger, katalog nettsteder, små forretningsnettsteder og WooCommerce-butikker fungerer uten problemer med XML-RPC stengt. Hvis du derimot har kritiske prosesser som betalingsinfrastruktur og fraktintegrasjoner, er det best å teste endringen i lavtrafikktider.

Hvorfor er WordPress XML-RPC risikabelt for brute force-angrep?

Brute force-angrep er når en angriper gjentatte ganger prøver forskjellige brukernavn- og passordkombinasjoner med automatiserte verktøy. På WordPress skjer disse prøvene vanligvis via wp-login.php; men XML-RPC kan gi angriperen en mer fordelaktig vei. Noen XML-RPC-metoder tillater flere innloggingsforsøk i én enkelt HTTP-forespørsel. Spesielt system.multicall-funksjonen kan hjelpe til med å utføre hundrevis av forsøk med færre synlige forespørsel i svakt konfigurerte systemer.

For eksempel, når du prøver 500 passord via wp-login.php, ser det ut som 500 separate forespørsel, mens de samme forsøkene kan sendes med færre pakkede forespørsel via XML-RPC. Dette kan føre til at sikkerhetsplugins og enkle loggoppfølginger oppdager angrepet sent. Resultatet er økt CPU-bruk, PHP-arbeidere blir opptatt, databasen belastes med unødvendige forespørsel, og ekte besøkende får langsommere responser. I delt hosting-miljøer er dette ikke bare et sikkerhetsproblem, men også et problem med ytelse og ressursbruk.

Et annet risikoområde med XML-RPC er misbruk av pingback. Pingback-mekanismen er utformet for å informere om at et annet nettsted har lenket til innholdet ditt; men den kan misbrukes til å generere DDoS-lignende trafikk eller peke ut tredjeparts nettsteder. Derfor reduserer stenging av XML-RPC ikke bare innloggingsforsøkene; det reduserer også risikoen for misbruk knyttet til pingback.

Beslutning om å stenge XML-RPC: Rask Sammenligningstabel

Som tabellen viser, er den raskeste og mest effektive metoden å stenge XML-RPC på server- eller WAF-nivå hvis du ikke trenger det. Å bruke plugin er enkelt; men hvis angrepsforespørselen når PHP, kan ressursforbruket fortsette. Derfor bør prioriteten for nettsteder med høy trafikk, e-handel eller som er utsatt for angrep være å bruke serverregel.

Kontrolliste før du starter

Når du gjør sikkerhetsinnstillinger, er det grunnleggende prinsippet å først måle og lage en tilbakemeldingsplan. Å stenge XML-RPC er vanligvis risikofritt; men ingen endringer bør gjøres blindt på et aktivt nettsted. Nedenfor er en kontrolliste som reduserer sjansen for feil under implementeringen.

• Ha en nylig sikkerhetskopi av en fungerende fil og database tatt innen de siste 24 timene. Backup bør anses som obligatorisk før WordPress-oppdateringer, sikkerhetstiltak og plugin-endringer.
• Sjekk om du bruker Jetpack, WordPress mobilapp, eksterne publiseringsverktøy eller spesialtilpassede integrasjoner.
• Undersøk antallet xmlrpc.php-forespørsel i tilgangsloggene. Hvis du ser dusinvis eller hundrevis av forespørsel per minutt, kan du være under angrep.
• Gjennomfør endringen i lavtrafikktider. Test spesielt handlekurv, betaling og medlemskap etter endringen på WooCommerce-nettsteder.
• Definer en tilbaketruksjonsmetode. Ha tilgang til filbehandler, FTP eller SSH for å kommentere ut eller slette regelen du har lagt til.

I et profesjonelt hostingmiljø gjør regelmessig backup, oppdatert PHP-versjon, isolert kontostruktur og brannmurstøtte en stor forskjell. Du kan også referere til innholdene om Sikker Web Hosting for infrastrukturvalg og SSL-sertifikat for generell nettstedssikkerhet.

Metode 1: Stenge XML-RPC med .htaccess på Apache eller LiteSpeed

Den vanligste metoden for WordPress-nettsteder som bruker Apache og LiteSpeed er å legge til en regel i .htaccess-filen i nettstedets rotmappe for å blokkere tilgangen til xmlrpc.php. Siden LiteSpeed støtter Apache-kompatible .htaccess-regler, kan denne metoden implementeres direkte i mange hostingmiljøer. Den største fordelen er at forespørselen blir avvist før WordPress-kjernen kjører.

Trinn for trinn implementering

• Åpne filbehandleren fra hostingkontrollpanelet eller koble til public_html-katalogen via FTP.
• Finn .htaccess-filen og ta en sikkerhetskopi til datamaskinen. Hvis filen ikke er synlig, aktiver alternativet for å vise skjulte filer.
• Legg til XML-RPC blokkering regelen øverst i filen uten å slette reglene som WordPress har generert.
• Regelens logikk skal være: Avvis all tilgang til xmlrpc.php-filen.
• Lagre og sjekk domenet ditt med adressen din.com/xmlrpc.php i nettleseren.

Logikken for Apache 2.4 og LiteSpeed-miljøer er som følger: Definer Require all denied for xmlrpc.php-filen. I eldre Apache 2.2-miljøer kan tilnærmingen Deny from all brukes; men det anbefales å bruke oppdatert serverprogramvare i 2026-standard. Hvis du fortsatt jobber med en eldre Apache-versjon, er dette et tema som bør forbedres både for XML-RPC og generelt sikkerhet.

Ved en vellykket blokkering kan xmlrpc.php-adressen returnere 403 Forbidden, 404 Not Found, eller et lignende adgangsnektsvar avhengig av serverkonfigurasjonen din. Det viktigste er at siden ikke gir et svar som "XML-RPC server accepts POST requests". Hvis dette uttrykket vises, betyr det at filen fortsatt er tilgjengelig.

Metode 2: Blokkere XML-RPC-tilgang på Nginx

På Nginx fungerer ikke .htaccess; fordi Nginx ikke leser .htaccess basert på mapper. Derfor må regelen legges til i serverblokk-konfigurasjonen for nettstedet. Hvis du bruker administrert hosting, kan dette området ikke være direkte åpent for deg; i så fall kan du be supportteamet ditt om å stenge xmlrpc.php-tilgangen.

Den grunnleggende tilnærmingen på Nginx er å nekte forespørselen med location = /xmlrpc.php-blokken eller å returnere 404. For sikkerheten kan 403 brukes for å eksplisitt forby, mens 404 kan brukes for å vise at filen ikke eksisterer. 404-tilnærmingen foretrekkes ofte av administratorer som ønsker å gi mindre informasjon til botter. Etter at regelen er lagt til, må Nginx-konfigurasjonen testes, og tjenesten må lastes på nytt. En feil karakter kan føre til at hele nettstedet ikke åpnes, så denne prosessen må alltid utføres med forsiktighet.

Det er nyttig å overvåke tilgangsloggene etter endringen på VPS eller dedikerte servere som bruker Nginx. Du bør se at xmlrpc.php-forespørsel nå resulterer i 403 eller 404. Hvis det fortsetter å komme mange forespørsel fra samme IP-adresser, kan du legge til et ekstra lag med beskyttelse med fail2ban, hastighetsgrense eller WAF-regel. For mer omfattende veiledninger om serveradministrasjon kan VPS-server sikkerhet vurderes.

Metode 3: Stenge XML-RPC med Sikkerhetsplugin

For brukere som ikke ønsker å redigere tekniske filer, er sikkerhetsplugins en praktisk løsning. Plugins som Wordfence, Solid Security, All-In-One Security kan ha alternativer for å deaktivere XML-RPC, stenge pingback eller blokkere XML-RPC innloggingsforsøk. Denne metoden gir en rask oppstart, spesielt for små blogger og grunnleggende bedriftsnettsteder.

Men det er viktig å kjenne begrensningene ved plugin-tilnærmingen. Hvis pluginen blokkerer forespørselen etter at WordPress har kjørt, kan angriperens forespørsel fortsatt utløse PHP-prosessen. Dette betyr at CPU- og minneforbruket ikke er helt stoppet under intense angrep. Derfor er stenging med plugin mye bedre enn ingen tiltak; men for nettsteder som er utsatt for angrep, bør det støttes med server- eller WAF-lag.

Ting å merke seg når du bruker plugin

• Last ned sikkerhetspluginen kun fra den offisielle WordPress-plugin-katalogen eller fra produsentens offisielle nettsted.
• Unngå å bruke plugins som ikke har vært oppdatert på lang tid. Aktiv vedlikehold og kompatibilitet i 2026 er et viktig sikkerhetssignal.
• Ikke bruk flere sikkerhetsplugins for samme formål samtidig. Konflikter kan skape problemer med innlogging, caching og filtilgang.
• Test nettstedets helse, skjemaer, medlemsinnlogging og betalingsflyt etter at XML-RPC-innstillingen er gjort.
• Gå regelmessig gjennom plugin-loggene. Hvis det er kontinuerlige angrep, bør IP-basert blokkering eller WAF-regel legges til.

Metode 4: Blokkering med WAF, CDN og Hosting Brannmur

Web Application Firewall, eller WAF, er et av de mest effektive lagene for å filtrere skadelige forespørsel før de når applikasjonen. CDN-baserte løsninger som Cloudflare kan blokkere xmlrpc.php-forespørsel før de når serveren. ModSecurity eller spesifikke WAF-regler som tilbys av hosting-leverandøren din fungerer på lignende måte. Dette laget er spesielt verdifullt for å stoppe mange bot-forespørsel før de når WordPress.

I WAF-regelen må målet være klart: hvis URI-stien inneholder xmlrpc.php, blokkér forespørselen eller bruk en utfordring. Hvis du ikke helt trenger XML-RPC, er blokkering mer direkte. Hvis det er delvis behov, kan tilnærmingen være å kun tillate bestemte IP-adresser. For eksempel, hvis en automatiseringstjeneste kommer fra en fast IP, kan denne IP-en hvitelistes, mens alle andre xmlrpc.php-forespørsel avvises. Denne metoden gir en balansert tilnærming mellom sikkerhet og forretningskontinuitet.

WAF-laget gir mer mening sammen med SSL. Nettsteder som ikke bruker HTTPS har også risiko for at påloggingsinformasjon og sesjonsikkerhet kan bli kompromittert. Derfor er det viktig å kjøre hele nettstedet over HTTPS, vurdere HSTS som overskrifter og følge med på sertifikatets gyldighet. I denne sammenhengen kan SSL-sertifikat og Installasjon av gratis SSL brukes som naturlige støttende innhold.

Hvordan teste etter stengning av XML-RPC?

Etter endringen er det ikke bare nettstedets tilgang som er viktig å sjekke. Det må også sjekkes om XML-RPC er stengt, om innloggingssystemet fungerer uten problemer, om ekte brukerhandlinger er påvirket, og om det er forventede resultater i loggene. Følgende testflyt gir en praktisk og tilstrekkelig validering.

• Åpne adressen din.com/xmlrpc.php i nettleseren. Du bør forvente å få et tilgangsnekt, 404 eller tomt svar. Teksten "XML-RPC server accepts POST requests" bør ikke vises.
• Logg inn på WordPress-administrasjonspanelet med de normale brukeropplysningene dine. Bekreft at innloggingssiden fungerer uavhengig av XML-RPC.
• Test kontaktskjemaet, kommentarskjemaet, medlemskap og WooCommerce betalingsprosessen.
• Kontroller i serverens tilgangslogger hvilken tilstandskode xmlrpc.php-forespørsel returnerer. 403 eller 404 svar viser at den riktige regelen fungerer.
• Hvis du har en sikkerhetsplugin, bør du se på hendelsesloggene. Du bør se at gamle bot-forsøk har blitt redusert eller blokkert.

For en mer teknisk test kan du sende POST-forespørsel fra terminalen; men for de fleste nettstedseiere er nettleser- og loggkontroll tilstrekkelig. Hvis forbindelsen til Jetpack blir brutt etter endringen, mobilappen ikke kan publisere, eller en integrasjon gir feil, blir det tydelig at XML-RPC faktisk er nødvendig. I så fall bør man overveie IP-basert tillatelse eller hastighetsgrense-strategi i stedet for å stenge helt.

Er det nok å stenge XML-RPC? Ekstra sikkerhetstiltak

Å stenge XML-RPC er et raskt og effektivt tiltak mot brute force-angrep; men det gir ikke full sikkerhet alene. Angripere kan fortsatt prøve å logge inn via wp-login.php, REST API, svake plugins, gamle temaer eller lekkede passord. Derfor er det nødvendig å tenke på WordPress-sikkerhet i flere lag etter å ha stengt XML-RPC.

Grunnleggende tiltak som bør implementeres

• Bruk sterke passord og unike brukernavn. Å unngå å bruke admin som brukernavn er fortsatt et enkelt, men effektivt tiltak.
• Legg til to-faktor autentisering. 2FA på administrator-kontoer reduserer betydelig risikoen for passordlekkasje.
• Implementer grense for innloggingsforsøk. Bruk hastighetsgrense eller sikkerhetsplugin for wp-login.php.
• Hold WordPress-kjernen, plugins og temaer oppdatert. Gamle plugins er en av de vanligste årsakene til sikkerhetsbrudd i virkeligheten.
• Fjern unødvendige plugins og temaer. Passive, men gamle plugins kan også utgjøre en risiko i filsystemet.
• Kontroller filrettigheter. Unødvendige skrive-tillatelser øker risikoen for skadelig filopplasting.
• Ta regelmessige sikkerhetskopier og test gjenopprettingen. En backup er kun en antakelse hvis den ikke er testet.
• Bruk en pålitelig hosting-infrastruktur. Isolasjon, oppdatert PHP, WAF og backup-støtte reduserer angrepseffekten.

For eksempel, hvis du bare stenger XML-RPC og bruker et svakt administratorpassord som 123456, er den svakeste linken i sikkerhetskjeden fortsatt åpen. Tvert imot, når sterke passord, 2FA, oppdatert programvare, WAF og sikker hosting brukes sammen, kan de fleste vanlige bot-angrep effektivt stoppes. Denne tilnærmingen er også viktig for SEO i 2026; fordi nettsteder med svak sikkerhet kan oppleve skadelige omdirigeringer, generering av spam-sider og indeksforurensning, og dermed miste sin organiske synlighet.

Effekten av å stenge XML-RPC på ytelse og SEO

XML-RPC-angrep er ikke direkte en rangeringfaktor; men deres indirekte effekter er sterke. Hvis intens bot-trafikk bruker serverressurser, vil sidens responstider øke, Core Web Vitals-verdiene kan bli negative, og den virkelige brukeropplevelsen kan forringes. I tillegg kan nettsteder som ofte treffer ressursgrensen oppleve 500-feil, tidsavbruddsproblemer og nedetid. Googlebot kan også være mer forsiktig med langsomme eller feilmeldte sider.

La oss tenke på et eksempel: Normalt åpner forsiden din med 300 ms serverresponstid; men hvis xmlrpc.php får 1000 forespørsel per minutt, blir PHP-arbeiderne overbelastet, og responstiden overstiger 2 sekunder. På brukerens side kan siden bli treg, konverteringsraten synker, og indekseringsstatistikken i Google Search Console kan variere. Å stenge XML-RPC på servernivå bidrar til ytelsesstabilitet ved å stoppe denne unødvendige belastningen før den når applikasjonslaget.

Når det gjelder SEO, er et sikkert og raskt nettsted avhengig av både innholdskvalitet og teknisk infrastruktur. HTTPS, oppdatert PHP, rask disk, riktig caching, ren temastruktur og redusert angrepsflate bør vurderes sammen. Derfor bør WordPress-sikkerhetsinnstillinger være på agendaen til både systemadministratorer og SEO- og innholdsteam. Dette emnet kan støttes i Hostragons blogg med innhold om WordPress hastighetsoptimalisering og sjekkliste for teknisk SEO.

Alternativ strategier hvis du ikke kan stenge XML-RPC helt

I noen prosjekter kan ikke XML-RPC stenges helt. For eksempel kan en spesifikk mobilpubliseringsstrøm, bedriftsautomatisering eller gamle integrasjoner fortsatt være avhengige av denne protokollen. I dette tilfellet er målet ikke å la alle dører stå åpne, men å kontrollere tilgangen. Den første løsningen er å hviteliste IP-adresser. Bare de IP-adressene til betrodde tjenester får tilgang til XML-RPC, mens alle andre forespørsel blokkeres.

Det andre alternativet er å implementere hastighetsgrense. Det hindrer en bestemt IP i å sende for mange xmlrpc.php-forespørsel på kort tid. Denne metoden er ikke så presis som fullstendig stenging; men den reduserer angrepsvolumet for nettsteder som har behov for det. Den tredje løsningen er å deaktivere pingback-metodene og kun tillate nødvendige metoder. Dette krever en mer avansert konfigurasjon og bør implementeres under utviklerens kontroll.

Den fjerde løsningen er å knytte XML-RPC-tilgangen til et ekstra sikkerhetslag. For eksempel kan HTTP-basert autentisering, VPN, bedrifts-IP-begrensning eller WAF-utfordring kreves for ekstra bekreftelse. Disse tilnærmingene reduserer risikoen for offentlig tilgangspunkt. Likevel, hvis mulig, er den langsiktige løsningen å flytte gamle integrasjoner til mer moderne og kontrollerbare metoder som REST API.

Praktisk veikart for Hostragons-brukere

Hvis du eier et nettsted som hoster WordPress på Hostragons, bør du først gjøre en behovsanalyse for XML-RPC-sikkerhet, og deretter velge den metoden som er minst komplisert. For delte hosting- eller WordPress-hostingpakker kan det være tilstrekkelig å redigere .htaccess via filbehandleren for de fleste brukere. Hvis du bruker VPS eller dedikert server, kan du planlegge Nginx, Apache, LiteSpeed og WAF-lagene sammen.

Implementeringsrekkefølgen kan være som følger: Først ta en backup, deretter sjekk tjenestene som bruker XML-RPC, så gjør servernivå blokkeringen, fullfør testene og overvåk loggene i 24 timer. Hvis angrepsforsøkene fortsetter, legg til WAF-regel, IP-blokkering og grense for innloggingsforsøk. Til slutt fullfør generelle sikkerhetsinnstillinger som 2FA, oppdateringspolitikk, regelmessige sikkerhetskopier og SSL.

Denne prosessen er ikke en salgsoffensiv oppgradering, men et grunnleggende hygienetiltak. Hvis infrastrukturen din likevel gir konstante problemer på grunn av gamle PHP-versjoner, utilstrekkelige ressurser eller mangel på brannmur, kan det være fornuftig å vurdere en mer moderne hostingplan. Et optimalisert miljø for WordPress med sikkerhetslag gir både motstandskraft under angrep og forbedrer den daglige ytelsen. I denne sammenhengen gir WordPress hosting, skyserver og SSL-sertifikat naturlige henvisninger til leserne.

Ofte stilte spørsmål

Vil stenging av WordPress XML-RPC ødelegge nettstedet mitt?

I de fleste standard WordPress-nettsteder vil stengning av XML-RPC ikke ødelegge nettstedet. Administrasjonspanelet, temaet, innholdet, skjemaer og brukergrensesnittet blir vanligvis ikke påvirket. Men hvis du bruker Jetpack, WordPress mobilapp, eller har spesialtilpassede integrasjoner som bruker XML-RPC, kan det oppstå forbindelsesproblemer. Derfor bør du sjekke bruksbehovet før du stenger og teste de grunnleggende funksjonene etterpå.

Hvordan kan jeg vite om XML-RPC er stengt?

Åpne adressen din.com/xmlrpc.php i nettleseren. Hvis du ser en melding som "XML-RPC server accepts POST requests", er filen fortsatt tilgjengelig. Hvis du får 403, 404 eller tilgangsnekt, er det sannsynlig at stenge regelen fungerer.

Stopper stenging av XML-RPC brute force-angrep helt?

Det stopper stort sett brute force-forsøk relatert til XML-RPC; men det fjerner ikke all risiko for brute force. Angripere kan fortsatt prøve å logge inn via wp-login.php. Derfor bør stenging av XML-RPC kombineres med sterke passord, to-faktor autentisering, innloggingsgrense, WAF og en oppdatert plugin-politikk.

Bør jeg stenge XML-RPC hvis jeg bruker Jetpack?

Jetpack har noen funksjoner som kan trenge XML-RPC-tilkobling. Hvis du bruker Jetpack, bør du sjekke hvilke moduler du bruker før du stenger XML-RPC helt. Alternativt kan det være mer hensiktsmessig å tillate IP-adressene til Jetpack-tjenestene, blokkere alle andre xmlrpc.php-forespørsel eller definere kontrollert tilgang i WAF.

Er det bedre å stenge med plugin eller på servernivå?

For best ytelse og sikkerhet er det mer effektivt å stenge på server- eller WAF-nivå; fordi forespørselen blir avvist før WordPress og PHP kjører. Stenging med plugin er enkelt for brukere med lite teknisk kunnskap, men det kan ikke forhindre ressursforbruket helt under intense angrep. Det bør helst foretrekkes en serverregel, og hvis det ikke er mulig, en pålitelig plugin med WAF-støtte.

Kort oppsummering og neste steg

Å stenge WordPress XML-RPC er en av de raskeste måtene å redusere brute force-forsøk, misbruk av pingback og unødvendig bot-trafikk på for nettsteder som ikke trenger XML-RPC. Den mest robuste tilnærmingen er å blokkere tilgangen til xmlrpc.php på server- eller WAF-nivå, og deretter bygge lagdelt beskyttelse med innloggingssikkerhet, 2FA, oppdateringer, SSL og regelmessige sikkerhetskopier. Hvis du ønsker å se nærmere på infrastrukturen til nettstedet ditt, kan du undersøke Hostragons WordPress-fokuserte hosting- og sikkerhetsløsninger; og med en liten sjekkliste kan du ta det første steget i dag.