WordPress XML-RPC Uitschakelen: De Snelste Maatregel tegen Brute Force Aanvallen

Het uitschakelen van WordPress XML-RPC betekent dat je voorkomt dat het bestand xmlrpc.php op je website externe verzoeken kan ontvangen. Dit helpt brute force pogingen, pingback misbruik en onnodig botverkeer snel te verminderen. Gebruik je geen Jetpack, de officiële WordPress mobiele app, oudere externe publicatietools of een custom integratie die XML-RPC nodig heeft? Dan is het uitschakelen van XML-RPC voor de meeste WordPress-sites een veilige en praktische beveiligingsstap. De meest effectieve aanpak is het blokkeren van verzoeken al op serverniveau, vóórdat WordPress gestart wordt. Met een regel in Apache, LiteSpeed, Nginx of een WAF kun je de toegang tot xmlrpc.php afsnijden. Dit werkt doorgaans beter dan het simpelweg uitschakelen met een plugin.

In deze gids leggen we uit waarom je XML-RPC zou moeten uitschakelen, in welke gevallen je dat juist niet moet doen en hoe je dit veilig toepast in verschillende serveromgevingen. Of je nu gebruikmaakt van Hostragons infrastructuur of een andere hostingprovider, het doel is om zonder je site te breken het aanvalsvlak te verkleinen, onnodig verbruik van servercapaciteit te beperken en een hanteerbare veiligheidsstandaard neer te zetten. Wil je een snelle en veilige basis voor je WordPress website? Dan is ook je keuze voor WordPress hosting een belangrijke factor in dit proces.

Wat is XML-RPC en wat doet het in WordPress?

XML-RPC is een ouder communicatieprotocol waarmee verschillende systemen via HTTP XML-geformatteerde data uitwisselen. In WordPress gebeurt dit meestal via het bestand xmlrpc.php in de hoofdmap. Historisch gezien werd dit bestand gebruikt om berichten te publiceren vanuit de WordPress mobiele app, om op afstand reacties te beheren, voor pingbacks en voor interactie met enkele externe diensten.

In de moderne WordPress-wereld is de REST API veel gangbaarder geworden, waardoor de rol van XML-RPC is afgenomen. Toch is xmlrpc.php in veel installaties nog steeds bereikbaar. Dit maakt het voor aanvallers een makkelijk te vinden en standaard doelwit, dat geautomatiseerd aangevallen kan worden. Vooral bots die willekeurige IP-ranges scannen, proberen vaak binnen enkele minuten al toegang te krijgen tot het xmlrpc.php-adres, zelfs bij een net geregistreerde domeinnaam. Daarom is het verstandig om bij het live zetten van een nieuwe website via Domeinsopzoeking direct aan beveiliging te denken.

Wanneer is XML-RPC eigenlijk nodig?

XML-RPC is niet per definitie overbodig voor elke site. Sommige oudere Jetpack-functies, bepaalde acties in de WordPress mobiele app, automatiseringsdiensten of oude desktop blog editors kunnen nog afhankelijk zijn van XML-RPC. Ook maatwerk integraties kunnen gebruikmaken van xmlrpc.php voor content publicatie of data-uitwisseling op afstand. Controleer daarom altijd eerst je workflows voordat je het uitschakelt.

Een praktische check: als je alleen binnenkomt via het wp-admin dashboard, geen Jetpack gebruikt, niet publiceert via de mobiele app en je ontwikkelaar geen speciale XML-RPC integraties heeft ingesteld, dan heb je waarschijnlijk geen XML-RPC nodig. Corporate sites, blogs, cataloguswebsites, kleine ondernemingen en veel WooCommerce winkels functioneren vaak prima met XML-RPC uitgeschakeld. Heb je echter kritische processen zoals betalingsverkeer of verzendintegraties die afhankelijk zijn van XML-RPC, test dan de wijziging buiten piekuren om problemen te voorkomen.

Waarom vormt WordPress XML-RPC een risico voor brute force aanvallen?

Een brute force aanval probeert met automatische tools combinaties van gebruikersnamen en wachtwoorden uit. Meestal gebeurt dit via wp-login.php, maar XML-RPC kan aanvallers een voordeliger route bieden. Sommige XML-RPC methodes staan namelijk toe dat meerdere inlogpogingen in één HTTP-verzoek worden gebundeld. Vooral de system.multicall functie kan bij zwak geconfigureerde systemen honderden pogingen in minder zichtbare verzoeken verpakken.

Ter illustratie: 500 wachtwoordpogingen via wp-login.php lijken 500 losse verzoeken, terwijl via XML-RPC diezelfde hoeveelheid pogingen in veel minder verzoeken kan worden verwerkt. Dit maakt het voor beveiligingsplugins en simpele log monitoring lastiger om de aanval snel te detecteren. Het gevolg is dat de CPU zwaar belast raakt, PHP workers bezet raken, de database onnodig wordt belast en echte bezoekers langzamer reageren. Op shared hosting is dit niet alleen een veiligheidsprobleem, maar ook een issue op het gebied van performance en resourcegebruik.

Ook pingback misbruik is een risicogebied van XML-RPC. Pingbacks zijn bedoeld om aan te geven dat een andere website naar jouw content linkt, maar kunnen misbruikt worden om DDoS-achtige verkeerspieken te veroorzaken of om externe sites te targeten. Het uitschakelen van XML-RPC vermindert dus niet alleen brute force pogingen, maar beperkt ook dit soort misbruik.

Vergelijkingstabel: manieren om XML-RPC uit te schakelen

Zoals de tabel toont, is de snelste en krachtigste aanpak om XML-RPC uit te schakelen op server- of WAF-niveau, mits je het niet nodig hebt. Plugins zijn makkelijk, maar laten het verzoek meestal nog door naar PHP, waardoor het verbruik blijft bestaan. Bij sites met veel verkeer, webshops of doelwitten van aanvallen verdient een serverregel dan ook de voorkeur.

Checklist vóór je begint

Beveiligingsinstellingen pas je verantwoord toe door eerst te meten en een terugvalplan te maken. Het uitschakelen van XML-RPC is meestal risicoloos, maar voer geen blinde wijzigingen uit op een live site. Deze checklist verkleint de kans op fouten tijdens de uitvoering.

• Zorg dat je een werkende back-up hebt van bestanden en database, gemaakt in de laatste 24 uur. Back-ups zijn verplicht bij updates, beveiligingsaanpassingen en pluginwijzigingen.
• Controleer of je Jetpack, de WordPress mobiele app, een externe publicatietool of een custom integratie gebruikt die XML-RPC nodig heeft.
• Bekijk in de toeganglogs hoeveel xmlrpc.php-verzoeken er binnenkomen. Honderden per minuut kan duiden op een aanval.
• Voer de wijziging uit tijdens rustige uren. Test daarna vooral WooCommerce winkelmand, betaalproces en gebruikersregistraties.
• Zorg dat je een manier hebt om de wijziging ongedaan te maken. Denk aan commentaarregels in configuratiebestanden, FTP- of SSH-toegang.

Professionele hosting met regelmatige backups, actuele PHP-versies, isolatie van accounts en firewallondersteuning maakt een groot verschil. Voor meer informatie over infrastructuurkeuze kun je ook Veilige Web Hosting en voor algemene siteveiligheid SSL certificaat raadplegen.

Methode 1: XML-RPC uitschakelen via .htaccess op Apache of LiteSpeed

De meest gebruikte methode bij Apache en LiteSpeed is het toevoegen van een regel in het .htaccess-bestand in de rootfolder die de toegang tot xmlrpc.php blokkeert. LiteSpeed ondersteunt dezelfde .htaccess-regels als Apache, waardoor deze methode in veel hostingomgevingen direct toepasbaar is. Het grote voordeel is dat het verzoek wordt geblokkeerd voordat WordPress draait.

Stapsgewijze instructies

• Open het bestandbeheer in je hosting control panel, of maak verbinding via FTP en navigeer naar de public_html map.
• Zoek het .htaccess-bestand en maak een backup. Staat het bestand niet zichtbaar? Zet dan de optie om verborgen bestanden te tonen aan.
• Voeg bovenaan het bestand, zonder bestaande WordPress regels te verwijderen, de regel voor het blokkeren van XML-RPC toe.
• De regel moet ervoor zorgen dat alle verzoeken naar xmlrpc.php geweigerd worden.
• Sla het bestand op en controleer in je browser of je bij domein.nl/xmlrpc.php een toegangsfout (403 Forbidden of 404 Not Found) krijgt.

Voor Apache 2.4 en LiteSpeed kun je de volgende regel gebruiken: Require all denied voor xmlrpc.php. Op oudere Apache 2.2 servers zie je soms nog Deny from all. Het verdient aanbeveling om in 2026 een recent serverplatform te gebruiken. Als je een verouderde Apache-versie draait, is dat sowieso een aandachtspunt voor je algemene beveiliging.

Bij een succesvolle blokkade zie je geen tekst zoals “XML-RPC server accepts POST requests”. Als die wel verschijnt, is XML-RPC nog bereikbaar.

Methode 2: XML-RPC blokkeren in Nginx

Nginx werkt niet met .htaccess-bestanden; de regels moeten daarom in de server block configuratie worden toegevoegd. Bij beheerde hosting heb je hier mogelijk geen directe toegang toe. Vraag in dat geval je hostingprovider om xmlrpc.php te blokkeren.

De basisaanpak is het toevoegen van een location = /xmlrpc.php blok dat verzoeken weigert of een 404 teruggeeft. Je kunt kiezen voor een 403 (verboden) of een 404 (niet gevonden) statuscode. De 404 optie geeft bots minder informatie en wordt daarom vaak aanbevolen. Na toevoeging moet de configuratie getest worden en Nginx opnieuw worden geladen. Een foutje kan de hele website onbereikbaar maken, dus wees voorzichtig.

Als je een VPS of dedicated server hebt met Nginx, controleer dan na wijziging de toeganglogs. Je moet zien dat verzoeken naar xmlrpc.php nu met 403 of 404 worden beantwoord. Blijven er pogingen vanaf hetzelfde IP komen? Dan kun je extra maatregelen nemen met fail2ban, rate limiting of een WAF. Voor meer serverbeheer tips zie ook VPS serverbeveiliging.

Methode 3: XML-RPC uitschakelen met een beveiligingsplugin

Voor gebruikers die geen serverbestanden willen aanpassen is een beveiligingsplugin een handige optie. Plugins zoals Wordfence, Solid Security en All-In-One Security bieden vaak opties om XML-RPC uit te schakelen, pingbacks te blokkeren of inlogpogingen via XML-RPC te beperken. Dit is een snelle start voor kleine blogs en basis zakelijke sites.

Let op: als de plugin het verzoek pas na het starten van WordPress blokkeert, wordt het PHP-proces toch nog belast. Dit betekent dat bij grote aanvallen CPU- en geheugengebruik niet volledig stopt. Een plugin is dus beter dan niets, maar bij drukke sites of doelwitten van aanvallen is een server- of WAF-regel aan te raden.

Tips bij het gebruik van plugins

• Download beveiligingsplugins alleen van de officiële WordPress plugin directory of de officiële website van de maker.
• Kies plugins die recent zijn bijgewerkt en actief onderhouden worden. In 2026 is dat een belangrijk teken van betrouwbaarheid.
• Gebruik niet meerdere beveiligingsplugins tegelijk voor dezelfde functie om conflicten te voorkomen.
• Test na het instellen van XML-RPC blokkades de sitegezondheid, formulieren, gebruikersinlog en betaalprocessen goed.
• Controleer regelmatig de logs van je beveiligingsplugin. Bij aanhoudende aanvallen kun je IP’s blokkeren of een WAF-regel toevoegen.

Methode 4: Blokkeren via WAF, CDN of hosting firewall

Een Web Application Firewall (WAF) is één van de meest effectieve lagen om schadelijke verzoeken te filteren voordat ze bij de applicatie komen. CDN’s zoals Cloudflare kunnen bijvoorbeeld alle xmlrpc.php-verzoeken blokkeren voordat ze je server bereiken. Ook ModSecurity of andere WAF-regels die je hostingprovider aanbiedt werken op dezelfde manier. Dit is vooral waardevol om grote hoeveelheden botverkeer te stoppen.

De regel in de WAF moet specifiek zijn: blokkeer of stel een challenge in voor elke URI die xmlrpc.php bevat. Als je XML-RPC helemaal niet nodig hebt, is blokkeren het beste. Heb je deels behoefte, dan kun je bijvoorbeeld alleen bepaalde IP-adressen toestaan. Bijvoorbeeld een automatiseringsdienst met een vast IP krijgt toegang, alle andere verzoeken worden geweigerd. Dit is een goede balans tussen veiligheid en bedrijfscontinuïteit.

WAF werkt het beste in combinatie met HTTPS. Sites zonder beveiligde verbinding lopen extra risico’s op diefstal van inloggegevens en sessies. Daarom is het verstandig om naast XML-RPC blokkades je hele site via HTTPS te draaien, HSTS-headers toe te passen en certificaatvervaldata in de gaten te houden. Daarbij kunnen SSL certificaat en Gratis SSL Installatie je verder helpen.

Hoe test je of XML-RPC succesvol is uitgeschakeld?

Na het aanbrengen van de wijziging is het belangrijk om meer te controleren dan alleen of je site nog online is. Is XML-RPC echt uitgeschakeld? Werkt het inlogsysteem nog? Zijn normale gebruikersacties niet beïnvloed? Bekijk ook de logs. Deze praktische checklist helpt je controleren.

• Ga in je browser naar domein.nl/xmlrpc.php. Je verwacht een toegangsfout (403), een 404 of een lege pagina. De tekst “XML-RPC server accepts POST requests” mag niet zichtbaar zijn.
• Log in op je WordPress dashboard met je gebruikersnaam en wachtwoord. Controleer of het loginproces losstaat van XML-RPC.
• Test contactformulieren, reacties, gebruikersregistratie en WooCommerce betaalprocessen.
• Bekijk de serverlogs en controleer of verzoeken naar xmlrpc.php met 403 of 404 worden beantwoord. Dit bevestigt dat de regels werken.
• Als je een beveiligingsplugin hebt, kijk dan in de logs of eerdere botpogingen zijn gestopt of geblokkeerd.

Voor gevorderden kan een POST-verzoek via terminal worden gedaan, maar voor de meeste site-eigenaren is browser- en logcontrole voldoende. Mocht Jetpack bijvoorbeeld niet meer werken, de mobiele app niet meer kan publiceren of een integratie fouten geeft, dan heb je waarschijnlijk XML-RPC toch nodig. Overweeg dan in plaats van volledig blokkeren een IP-whitelist of rate limiting.

Is XML-RPC uitschakelen genoeg? Andere veiligheidsmaatregelen

Het uitschakelen van XML-RPC is een snelle en effectieve maatregel tegen brute force aanvallen, maar het biedt geen volledige beveiliging. Aanvallers kunnen ook via wp-login.php, de REST API, zwakke plugins, verouderde thema’s of gelekte wachtwoorden proberen binnen te komen. Daarom is het belangrijk om na het uitschakelen van XML-RPC je WordPress beveiliging in lagen te denken.

Belangrijke aanvullende maatregelen

• Gebruik sterke wachtwoorden en unieke gebruikersnamen. Het vermijden van ‘admin’ als gebruikersnaam blijft een simpele maar effectieve maatregel.
• Voeg tweefactorauthenticatie (2FA) toe. Vooral voor beheerders vermindert dit het risico op wachtwoorddiefstal aanzienlijk.
• Beperk het aantal inlogpogingen. Gebruik rate limiting of beveiligingsplugins voor wp-login.php.
• Houd WordPress core, plugins en thema’s altijd up-to-date. Verouderde plugins zijn een van de meest voorkomende inbraakpunten.
• Verwijder ongebruikte plugins en thema’s. Ook passieve, maar verouderde software kan risico’s opleveren.
• Controleer bestandsrechten. Te ruime schrijfrechten vergroten het risico op kwaadaardige uploads.
• Maak regelmatig backups en test de herstelprocedure. Een backup die niet getest is, is eigenlijk waardeloos.
• Kies betrouwbare hosting met isolatie, actuele PHP-versies, WAF en backupondersteuning. Dit verkleint de impact van aanvallen.

Als je alleen XML-RPC uitschakelt maar vervolgens een zwak wachtwoord als “123456” gebruikt, blijft de beveiligingsketen zwak. Omgekeerd zorgt een combinatie van sterk wachtwoord, 2FA, actuele software, WAF en een veilige hostingomgeving ervoor dat de meeste bots niet eens een kans krijgen. Deze aanpak is ook relevant voor SEO in 2026: slecht beveiligde sites kunnen slachtoffer worden van schadelijke redirects, spam pagina’s of indexeringsproblemen, wat je organische zichtbaarheid schaadt.

Effect van XML-RPC uitschakelen op performance en SEO

XML-RPC aanvallen zijn geen directe rankingfactor, maar hun neveneffecten zijn significant. Een hoge botbelasting put je server uit, waardoor pagina’s trager laden, Core Web Vitals verslechteren en de gebruikerservaring afneemt. Ook kunnen timeouts, 500-fouten en onderbrekingen voorkomen. Googlebot kan langzamere of foutieve pagina’s terughoudender crawlen.

Een voorbeeld: je homepage laadt normaal binnen 300 ms, maar als xmlrpc.php 1000 verzoeken per minuut ontvangt, raken PHP workers vol en stijgt de laadtijd naar meer dan 2 seconden. Dit vertraagt de site, verlaagt conversies en veroorzaakt onregelmatige crawlstatistieken in Google Search Console. Het blokkeren van XML-RPC op serverniveau voorkomt deze onnodige belasting voordat deze de applicatie raakt.

SEO-technisch is een veilige en snelle website afhankelijk van meer dan alleen contentkwaliteit. HTTPS, actuele PHP-versies, snelle opslag, caching, schoon thema en een verkleind aanvalsvlak zijn ook doorslaggevend. Daarom hoort WordPress beveiliging ook op de agenda van SEO- en contentteams. Hostragons blog ondersteunt dit met artikelen over WordPress snelheid optimalisatie en technische SEO controlelijst.

Alternatieven als XML-RPC niet volledig uitgeschakeld kan worden

Voor sommige projecten is het niet mogelijk om XML-RPC helemaal uit te schakelen. Bijvoorbeeld bij een specifieke mobiele publicatiestroom, bedrijfsautomatisering of legacy integraties die hier nog van afhankelijk zijn. In dat geval is het doel om de toegang te controleren in plaats van volledig open te laten.

Een eerste optie is IP-whitelisting. Alleen vertrouwde IP-adressen krijgen toegang tot XML-RPC, alle anderen worden geweerd.

Een tweede optie is rate limiting. Hiermee zorg je dat een IP niet te veel xmlrpc.php verzoeken in korte tijd kan doen. Dit is minder streng dan volledig blokkeren, maar vermindert wel de kans op aanvallen.

Derde optie is het uitschakelen van pingback-methodes en het toestaan van alleen noodzakelijke XML-RPC functies. Dit vereist een geavanceerdere configuratie en is geschikt voor ontwikkelaars.

Een vierde optie is het toevoegen van een extra beveiligingslaag voor XML-RPC toegang, zoals HTTP Basic Auth, VPN-toegang, een IP-restrictie of een WAF-challenge. Zo beperk je het risico van een publiek beschikbare endpoint. De beste lange termijn oplossing blijft echter om legacy integraties te migreren naar de REST API of andere moderne, beter controleerbare methoden.

Handige stappen voor Hostragons gebruikers

Heb je een WordPress site bij Hostragons? Begin dan met een analyse van je behoefte aan XML-RPC en kies de minst complexe effectieve methode. Op shared hosting of WordPress hosting is het aanpassen van .htaccess vaak voldoende. Gebruik je een VPS of dedicated server? Dan kun je Nginx, Apache, LiteSpeed en WAF-regels combineren voor optimale bescherming.

De volgorde van aanpak is: maak eerst een backup, controleer welke diensten XML-RPC gebruiken, blokkeer vervolgens server-side, test goed en monitor de logs 24 uur lang. Blijven er aanvalspogingen? Voeg dan WAF-regels, IP-blokkades en loginlimieten toe. Rond af met tweefactorauthenticatie, updatebeleid, backups en SSL-configuratie.

Dit is geen commerciële upgrade maar een basis hygiëne stap. Kom je toch regelmatig technische problemen tegen door verouderde PHP-versies, te weinig resources of gebrek aan firewall? Overweeg dan een moderner hostingpakket. Een WordPress omgeving die is geoptimaliseerd voor veiligheid en performance biedt weerstand tegen aanvallen en verbetert de dagelijkse stabiliteit. Bekijk ook WordPress hosting, cloud server en SSL certificaat voor extra tips en ondersteuning.

Veelgestelde vragen

Breekt het uitschakelen van WordPress XML-RPC mijn site?

Voor de meeste standaard WordPress sites veroorzaakt het uitschakelen van XML-RPC geen problemen. Het beheerderspaneel, thema’s, content, formulieren en bezoekersfunctionaliteit blijven doorgaans ongewijzigd werken. Gebruik je Jetpack, de WordPress mobiele app of een custom integratie die XML-RPC nodig heeft? Dan kunnen er verbindingsproblemen ontstaan. Controleer daarom altijd eerst of je het nodig hebt en test de belangrijkste functies na het uitschakelen.

Hoe weet ik of XML-RPC uit staat?

Open domein.nl/xmlrpc.php in je browser. Als je een melding ziet zoals “XML-RPC server accepts POST requests” dan is het nog actief. Krijg je een 403 Forbidden, 404 Not Found of een lege pagina? Dan is het waarschijnlijk uitgeschakeld. Voor zekerheid kun je ook de serverlogs bekijken en controleren welke statuscode xmlrpc.php-verzoeken terugkrijgen.

Is XML-RPC uitschakelen voldoende om brute force te stoppen?

Het stopt grotendeels brute force aanvallen via XML-RPC, maar niet alle brute force risico’s. Aanvallers kunnen nog via wp-login.php proberen binnen te komen. Daarom moet je ook sterke wachtwoorden, 2FA, loginlimieten, WAF en een updatebeleid toepassen voor een volledige beveiligingsstrategie.

Gebruik ik Jetpack, moet ik dan XML-RPC uitzetten?

Sommige Jetpack functionaliteiten zijn afhankelijk van XML-RPC. Gebruik je Jetpack, controleer dan eerst welke modules actief zijn en of deze afhankelijk zijn van XML-RPC. In plaats van volledig uitschakelen kun je ook alleen Jetpack IP’s toegang geven of de toegang via WAF gecontroleerd regelen.

Is uitschakelen via plugin of via server beter?

Uitschakelen via server- of WAF-regel geeft de beste performance en veiligheid omdat het verzoek geweigerd wordt voordat WordPress en PHP opstarten. Plugins zijn makkelijker voor minder technische gebruikers, maar bij zware aanvallen blijft het serververbruik hoger. Kies waar mogelijk serverregels, anders een betrouwbare plugin met WAF-ondersteuning.

Kort samengevat en volgende stappen

Het uitschakelen van WordPress XML-RPC is een van de snelste manieren om brute force aanvallen, pingback misbruik en onnodig botverkeer te verminderen op sites die het niet gebruiken. De sterkste aanpak is het blokkeren van xmlrpc.php op server- of WAF-niveau, gecombineerd met inlogbeveiliging, 2FA, updates, SSL en regelmatige backups voor een gelaagde bescherming. Wil je je hostingomgeving verbeteren? Verken dan Hostragons WordPress-specifieke hosting en beveiligingsopties en begin vandaag nog met een kleine checklist voor je huidige site.