In beveiligingsrapporten duikt hij regelmatig op als aandachtspunt: de open interface waarmee externe programma’s uw site kunnen uitlezen. Wie de WordPress REST API afschermen wil, krijgt online vooral het advies om hem helemaal uit te zetten. Dat kan, en het is bijna altijd een slecht idee, want u sloopt er de blokeditor en de helft van uw plugins mee.

Er is een verstandiger route: begrijpen wat er open staat, kijken wat daarvan werkelijk gevoelig is, en alleen dat deel dichtzetten. Dat kost een half uur en levert meer op dan een botte blokkade.

Wat de REST API is en waarom hij er is

Sinds WordPress 4.7 heeft elke site een reeks adressen onder /wp-json/ waarmee software gegevens kan opvragen en aanleveren. Het is de moderne manier waarop WordPress met zichzelf en met de buitenwereld praat.

Wat er allemaal op leunt:

  • De blokeditor. Elke keer dat u een pagina opslaat, gaat dat via deze interface. Zet u hem helemaal uit, dan kunt u niets meer bewerken.
  • De mobiele app van WordPress en de meeste externe publicatietools.
  • WooCommerce-koppelingen met boekhoudpakketten, voorraadsystemen en verzendpartijen.
  • Formulierplugins, paginabouwers en veel beveiligingsplugins, die hun eigen schermen erop bouwen.
  • Zoekmachines en analysediensten die soms via deze weg informatie ophalen.

Kortom: het is geen los onderdeel dat u zomaar kunt uitschakelen, maar een centrale zenuw. Dat verklaart ook waarom het advies om hem te blokkeren zo hardnekkig is: het dateert uit de tijd dat WordPress nog met de oude editor werkte en er inderdaad weinig van afhing. Sinds de blokeditor de standaard is, geldt dat advies niet meer, en toch staat het nog in veel oudere handleidingen die online blijven rondzwerven.

Wat er werkelijk open staat

Zonder in te loggen kan iedereen op internet een aantal adressen opvragen. Typ eens uwdomein.nl/wp-json/ in uw browser en kijk wat er terugkomt. In de praktijk zijn dit de gevoelige punten.

De gebruikerslijst. Op /wp-json/wp/v2/users staat bij veel sites een overzicht van accounts, inclusief de inlognaam. Dat is de belangrijkste reden om iets te doen: een aanvaller hoeft dan alleen nog het wachtwoord te raden. Hetzelfde probleem speelt bij het lekken van namen via de auteur-url, en beide gaten wilt u tegelijk dichten.

De volledige inhoud van berichten en pagina’s, inclusief concepten in sommige configuraties. Voor een gewone site is dat niet erg; de inhoud staat toch al op internet.

Instellingen van plugins die hun eigen adressen toevoegen zonder goede controle op wie er mag kijken. Dit is in de praktijk de grootste bron van echte lekken.

Wat er níet in staat: wachtwoorden, betaalgegevens en klantorders. Die zitten achter een verplichte aanmelding. De REST API is dus zelden een acuut gevaar, maar wel een bron van informatie die aanvallers gebruiken om hun werk te richten.

Gericht afschermen in vier stappen

  1. Blokkeer de gebruikerslijst voor niet-ingelogde bezoekers. Dit is de maatregel met verreweg het meeste effect en het minste risico. Vrijwel elke beveiligingsplugin heeft er een vinkje voor; anders is het een paar regels in een klein eigen pluginbestand.
  2. Sluit gasten uit waar dat kan. Bij een site zonder koppelingen, zonder app en zonder webshop kunt u de hele interface afsluiten voor bezoekers die niet zijn ingelogd. De editor blijft dan gewoon werken, want u bént ingelogd. Test dit wel eerst.
  3. Laat de adressen open die iets nodig hebben. Een contactformulier, een reserveringssysteem of een chatvenster praat vaak vanuit de browser van de bezoeker. Sluit u alles dicht, dan werken die niet meer.
  4. Zet een snelheidslimiet op de interface. Duizend aanvragen per minuut op hetzelfde adres is geen normaal gebruik. Een limiet vangt dat af zonder dat u hoeft te kiezen tussen open en dicht.

Testen: het deel dat wordt overgeslagen

Na elke aanpassing loopt u dit lijstje af, bij voorkeur op een testomgeving:

  • Een pagina openen, wijzigen en opslaan in de editor.
  • Een afbeelding uploaden naar de mediabibliotheek.
  • Het contactformulier versturen en controleren of de mail aankomt.
  • Bij een webshop: een testbestelling plaatsen en kijken of de koppeling met uw boekhouding of verzendpartij nog loopt.
  • De site openen in een incognitovenster en kijken of er niets ontbreekt in beeld.

Gaat er iets stuk, dan merkt u dat meestal niet meteen maar pas dagen later, wanneer een koppeling stilletjes is gestopt. Noteer daarom in uw eigen administratie wat u heeft aangepast en wanneer. Dat scheelt bij een latere storing een hoop zoekwerk, zoals u ziet in de aanpak om een conflict tussen plugins op te sporen.

Wanneer u hier niets aan hoeft te doen

Eerlijk is eerlijk: voor een eenvoudige bedrijfssite met één beheerder en een sterk wachtwoord is dit geen prioriteit. De gebruikerslijst afschermen is nuttig, de rest is verfijning. Uw tijd is beter besteed aan updates, een geteste back-up en een tweede stap bij het inloggen. Wie eerst de REST API dichttimmert en daarna de plugins een half jaar niet bijwerkt, heeft per saldo niets gewonnen.

Draait u wel een webshop, een ledensite of een site met meerdere redacteuren, dan is het de moeite waard. Daar valt echt iets te halen, en daar zijn ook de meeste koppelingen actief die u niet zomaar kunt blokkeren. Zo’n afweging maken en de wijziging daarna netjes testen hoort bij het structureel afschermen van een WordPress-site; bij WebMaintor zetten we de gebruikerslijst standaard dicht en kijken we per site of er meer nodig is.

Concrete volgende stap: open uwdomein.nl/wp-json/wp/v2/users in een incognitovenster. Ziet u daar uw inlognamen staan, dan weet u meteen wat uw eerste maatregel wordt.