Is XML-RPC altijd onveilig?

Nee. De code is op zich functioneel, maar wel een aantrekkelijk doel voor brute-force-aanvallen. Open laten zonder reden is onnodig risico, uitschakelen zonder afweging breekt soms functionaliteit.

Werkt Jetpack zonder XML-RPC?

Sommige onderdelen van Jetpack werken via REST API, maar veel features (stats, backup, sommige sociale-deelfuncties) gebruiken nog XML-RPC. Volledig uitschakelen breekt dus een deel van Jetpack.

Wat als ik de WordPress-app gebruik?

De app probeert eerst REST API, valt terug op XML-RPC. Blokkeer je XML-RPC volledig, dan werkt de app op recente versies meestal nog, maar oudere apps faalden hierop. Test het in jouw situatie.

Welke methode is het veiligst?

Een combinatie van .htaccess (op webserver-niveau blokkeren) en een filter in functions.php (binnen WordPress). Dubbele laag. Een security-plugin is een derde optie maar voegt een afhankelijkheid toe.

Kan ik XML-RPC tijdelijk inschakelen voor een migratie?

Ja, haal het blok in .htaccess weg, voer de migratie uit, zet het blok terug. Wel direct na de migratie weer dichtzetten. Een week openlaten is genoeg voor brute-force-bots om binnen te komen.

Heeft de REST API dezelfde risico's?

De REST API heeft eigen beveiligingsmodellen (application passwords, nonces, capability-checks). Bij een goed geconfigureerde site is hij veiliger dan XML-RPC. Slecht geconfigureerd is elke API kwetsbaar.

XML-RPC uitschakelen WordPress: wanneer wel, niet

XML-RPC blind uitschakelen in WordPress is geen goed idee. Dat klinkt vreemd, want bijna elke security-blog zegt het tegenovergestelde. Toch zie ik regelmatig sites waar xmlrpc.php is geblokkeerd en daarna functies stilletjes zijn uitgevallen. De Jetpack-verbinding werkt niet meer. De WordPress-app op de telefoon geeft een foutmelding. Een externe koppeling die maandelijks data oppakte, faalt.

Dit artikel laat zien wanneer XML-RPC wel weg kan en wanneer niet. Een beslisboom met drie scenario’s, drie methoden om het uit te schakelen, en waarom de REST API een betere route is voor moderne integraties.

Ik werk vanuit Terneuzen aan onderhoud en hardening van WordPress-sites. XML-RPC zit op vrijwel elke installatie en is een populaire aanvalsroute voor brute-force pogingen. Wegzetten kan een quick win zijn, mits je weet wat je breekt.

Beslisboom voor XML-RPC uitschakelen in WordPress met handgetekende beslisboom in een rustige werkkamer

Wat XML-RPC is en waarom het er nog zit

XML-RPC is een oud protocol voor remote procedure calls via HTTP. In WordPress zit het sinds versie 1.5 en wordt het gebruikt voor functionaliteit die buiten de browser om de site aanstuurt. Pingbacks van andere blogs, externe blog-clients, mobiele apps, Jetpack-services.

De server-kant draait op xmlrpc.php in de root van je site. Officiële documentatie over het protocol staat in de WordPress XML-RPC Handbook.

Waarom is het een security-zorg? Drie redenen.

Brute-force versterking. Via de system.multicall-methode kan een aanvaller honderden inlogpogingen in één request stoppen. Dat omzeilt veel rate-limiting die op wp-login.php is gericht.

DDoS via pingbacks. De pingback-functionaliteit kan misbruikt worden om vanaf je site andere sites te bestoken. Je site wordt onderdeel van een aanvalsnet zonder dat je het merkt.

Verouderde codebase. Het XML-RPC-deel van WordPress krijgt minimaal onderhoud. Nieuwe features komen in de REST API. Wat oud is en niet meer actief ontwikkeld wordt, wordt op termijn een zwakke plek.

Tegelijkertijd: WordPress core verwijdert xmlrpc.php niet. Te veel bestaande integraties gebruiken het nog. Daarom moet je zelf kiezen wat je doet.

Wanneer je XML-RPC nodig hebt

Drie scenario’s waarin XML-RPC actief moet blijven, of in elk geval beperkt toegankelijk.

Jetpack en automattic-services. Jetpack gebruikt XML-RPC voor de verbinding met WordPress.com. Stats, backups via VaultPress, JetpackBoost, social sharing-features. Zonder XML-RPC werkt de helft van Jetpack niet, of geeft het verbindingsfouten. Sinds versie 7 ondersteunt Jetpack ook de REST API als alternatief, maar veel functies vallen nog terug op XML-RPC.

WordPress mobile apps. De officiële WordPress-app voor iOS en Android maakt verbinding via XML-RPC, met REST API als fallback. Beheer je je site vooral vanaf de telefoon, dan kun je XML-RPC niet volledig wegzetten.

Externe publicatie-tools. Sommige redactie-workflows publiceren via tools als MarsEdit of zelfgebouwde scripts. Die gebruiken vaak XML-RPC. Dezelfde geldt voor cross-platform publicatie-plugins die naar meerdere blogs tegelijk posten.

Voor MKB-sites die alleen via de browser worden beheerd, en die geen Jetpack of mobile app gebruiken, kan XML-RPC volledig uit. Dat is veruit het meest voorkomende geval bij mijn klanten.

WordPress mobile app en Jetpack vereisen XML-RPC voor verbinding met de WordPress site

Beslisboom in drie scenario’s

Om te bepalen wat bij jouw site past, drie scenario’s met een directe uitkomst.

Scenario 1: Solo-MKB-site, geen Jetpack, geen mobile app, alles via desktop. Uitschakelen kan volledig. Via .htaccess, een plugin of een functie in functions.php. Geen functionaliteit valt uit.

Scenario 2: Site met Jetpack of WordPress-app. Niet volledig uitschakelen. Wel beperken door alleen de bekende IP-adressen van Jetpack toe te laten, of door de system.multicall-methode uit te schakelen terwijl de rest blijft werken.

Scenario 3: Webshop of redactie-site met externe koppelingen. Eerst inventariseren welke koppelingen XML-RPC gebruiken. Vraag de leverancier of de koppeling ook via REST API werkt. Migreer waar mogelijk en zet daarna XML-RPC weg.

Twijfel je over je situatie? Open wp-admin > Tools > Site Health > Info en kijk welke connected services je hebt. Of stuur me een berichtje, daar ben ik voor.

Methode 1: uitschakelen via .htaccess

De snelste en meest betrouwbare manier is een blok in .htaccess. Dat zet de toegang op webserver-niveau weg, voordat WordPress wordt opgestart. Geen plugin nodig, geen code in het thema.

Volledig blokkeren:

apache

<Files xmlrpc.php>
    Order Allow,Deny
    Deny from all
</Files>

Of de modernere syntax voor Apache 2.4+:

apache

<Files xmlrpc.php>
    Require all denied
</Files>

Toegang beperken tot Jetpack-IP-adressen:

apache

<Files xmlrpc.php>
    Require all denied
    Require ip 192.0.64.0/18
    Require ip 122.248.245.244/32
</Files>

De Jetpack-IP-range wijzigt af en toe. Actuele lijst staat in de Jetpack-documentatie over IP-adressen. Een hardgecodeerde lijst veroudert, dus dit vraagt om periodieke controle.

Op Nginx werkt het via de server-config:

nginx

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Test na het toevoegen: ga naar https://jouwdomein.nl/xmlrpc.php. Je hoort een 403 Forbidden te zien. Krijg je de tekst “XML-RPC server accepts POST requests only”, dan staat XML-RPC nog open.

Methode 2: uitschakelen via een filter in PHP

Een tweede route is een filter in functions.php van een child-thema, of in een mu-plugin (must-use plugin in wp-content/mu-plugins/).

php

add_filter( 'xmlrpc_enabled', '__return_false' );

Deze filter stopt het verwerken van XML-RPC-calls binnen WordPress zelf. Het bestand xmlrpc.php is nog wel bereikbaar, maar geeft een foutmelding. Aanvallen die het bestand opvragen, slaan nog wel server-resources weg.

Daarom werkt deze methode beter in combinatie met .htaccess. PHP-filter voor de WordPress-laag, .htaccess voor de webserver-laag.

Wil je alleen de pingback-methode uitschakelen en de rest behouden? Een fijnere filter:

php

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
});

Dit is nuttig als je Jetpack actief houdt maar de pingback-DDoS-route wilt sluiten.

Methode 3: via een security-plugin

Wordfence, iThemes Security (nu Solid Security) en Sucuri bieden allemaal een schakelaar om XML-RPC uit te zetten. Dat is voor wie geen .htaccess of code wil aanraken.

Voordeel: één klik. Nadeel: je voegt een afhankelijkheid toe. Schakel je de plugin uit, dan is XML-RPC weer open. En de plugin moet draaien (en dus PHP-resources gebruiken) bij elke request.

In mijn ervaring is .htaccess de schoonste oplossing voor sites die geen XML-RPC nodig hebben. Plugins zijn handig voor wie de gradaties (alleen Jetpack toelaten, alleen pingback weg) wil regelen via een UI.

WordPress REST API als moderne vervanging voor XML-RPC met /wp-json endpoint en JSON-response

REST API als modern alternatief

De REST API zit sinds WordPress 4.7 in core en biedt dezelfde functionaliteit als XML-RPC, plus veel meer. Het is moderner, beter onderhouden en gebaseerd op JSON in plaats van XML.

Voor nieuwe integraties is REST API de juiste keuze. Authenticatie via application passwords, een ingebouwde feature sinds WordPress 5.6. Of via OAuth en JWT voor complexere setups.

Wat REST API niet doet: pingbacks. Die functionaliteit zit alleen in XML-RPC. Voor moderne sites is dat geen verlies, omdat de meeste pingback-implementaties tegenwoordig spam zijn.

Migratie van XML-RPC naar REST API:

Vraag de externe partij of hun koppeling REST API ondersteunt
Test in een staging-omgeving voor migratie
Voer de switch door en monitor logs op fouten
Schakel daarna XML-RPC veilig uit

Dit is vaak een halve dag werk voor een gemiddelde site. Voor klanten op Onderhoud Plus valt dit binnen de doorontwikkelingsuren. Bij Onderhoud Basis reken ik het apart per uur.

Brute-force in logs herkennen

Of XML-RPC actief wordt aangevallen, zie je in de access-logs. Patronen om naar te kijken:

Veel POST-requests naar /xmlrpc.php van dezelfde IP-range
Requests met body-content die wp.getUsersBlogs of system.multicall bevatten
Een verhoogde server-load die samenvalt met deze requests

Bij Hostinger en de meeste shared-hosters kun je access-logs downloaden via het paneel. Op een VPS staan ze meestal in /var/log/nginx/ of /var/log/apache2/.

Een ruwe grep om verdachte requests te tellen:

bash

grep "POST /xmlrpc.php" access.log | wc -l

Krijg je honderden hits per uur, dan is dat een teken dat XML-RPC actief wordt geprobeerd. Tijd om actie te ondernemen.

Wat ik doe op een onderhoudscontract

Bij de start van een WordPress onderhoudscontract loop ik altijd na of XML-RPC nodig is. Bij de meeste MKB-klanten kan het uit. Dat is een quick win die ik gewoon doe, geen extra factuur.

Heb je Jetpack of de WordPress-app, dan beperk ik de toegang in plaats van volledig blokkeren. Bij Onderhoud Plus (€175 per maand) kijk ik elk kwartaal of de externe IP-adressen nog kloppen, want Jetpack wijzigt af en toe.

Geen 24/7-support. Spoedwerk reken ik tegen €105 per uur. Voor wie zelf aan de slag wil maar twijfelt over de juiste route: een uur intake (€70) levert vaak een duidelijk plan op.

Heb je een vraag over jouw setup? Stuur me je URL en kort welke plugins of apps je gebruikt. Ik reageer binnen 4 uur op werkdagen. Meer artikelen staan in de categorie website beveiliging.