Hoe u de WordPress REST API uitschakelt

De WordPress REST API is een krachtige interface waarmee externe applicaties, thema's en plug-ins kunnen interageren met de data van uw site. Standaard stelt WordPress een aantal openbare eindpunten beschikbaar die iedereen zonder authenticatie kan bevragen. Hoewel dit nuttig is voor headless-opzetten en integraties van derden, opent het ook de deur naar informatielekken, met name rond gebruikersgegevens.

Wat de WordPress REST API standaard blootstelt

Wanneer de REST API volledig toegankelijk is, retourneren verschillende eindpunten data die de meeste site-eigenaren liever privé zouden houden. De meest misbruikte eindpunten zijn onder meer:

• /wp-json/wp/v2/users: retourneert een lijst van alle gebruikers die ten minste één bericht hebben gepubliceerd, inclusief gebruikersnaam, weergavenaam, gebruikers-ID, avatar-URL en archieflink van de auteur.
• /wp-json/wp/v2/users/1: retourneert gedetailleerde informatie over een specifieke gebruiker op basis van ID. Aanvallers beginnen vaak met ID 1 omdat dit doorgaans het beheerdersaccount is.
• /wp-json/wp/v2/posts: somt gepubliceerde berichten op, samen met auteursinformatie.
• /wp-json/wp/v2/pages: somt alle gepubliceerde pagina's op, wat de interne sitestructuur kan onthullen.
• /wp-json/: het root-eindpunt zelf onthult alle geregistreerde routes en geeft aanvallers een routekaart van de mogelijkheden van uw site en geïnstalleerde plug-ins.

Het eindpunt /wp/v2/users is voor de meeste sites de grootste zorg. Aanvallers gebruiken het voor gebruikersopsomming en verzamelen geldige gebruikersnamen die zij vervolgens in brute-force-aanmeldaanvallen gebruiken. Zelfs als u sterke wachtwoorden gebruikt, neemt het blootstellen van gebruikersnamen één laag verdediging weg.

Waarom u de REST API niet volledig moet uitschakelen

Het kan verleidelijk zijn de REST API volledig te blokkeren, maar dat zal verschillende kernfuncties van WordPress kapotmaken. De Gutenberg-blokeditor leunt zwaar op REST-API-aanroepen om blokdata te laden, inhoud op te slaan en media te beheren. Schakelt u de API volledig uit, dan zal Gutenberg niet laden en kunt u geen berichten of pagina's bewerken.

Naast Gutenberg vertrouwen veel populaire plug-ins op de REST API voor hun functionaliteit:

• Contact Form 7: gebruikt in nieuwere versies REST-API-eindpunten voor de afhandeling van formulierinzendingen.
• WooCommerce: vertrouwt op REST-API-routes voor winkelwagenoperaties, checkoutverwerking en de beheerinterface.
• Yoast SEO: gebruikt REST-API-aanroepen voor zijn metabox- en inhoudsanalysefuncties in de editor.
• Jetpack: vereist REST-API-toegang voor zijn verbinding met WordPress.com-diensten.

De juiste aanpak is selectieve beperking: blokkeer de openbare toegang tot gevoelige eindpunten en houd de API beschikbaar voor geauthenticeerde gebruikers en het WordPress-beheergedeelte.

Beperk de REST API tot ingelogde gebruikers

De effectiefste methode is authenticatie te vereisen voor alle REST-API-verzoeken. Voeg deze code toe aan het functions.php-bestand van uw thema, of beter nog, aan een aangepaste site-specifieke plug-in:

add_filter('rest_authentication_errors', function($result) {
    // If a previous authentication check already passed or failed, respect it
    if (true === $result || is_wp_error($result)) {
        return $result;
    }

    // Block unauthenticated requests
    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            'You are not currently logged in.',
            array('status' => 401)
        );
    }

    return $result;
});

Deze aanpak blokkeert alle REST-API-toegang voor bezoekers die niet zijn ingelogd. Gutenberg, WooCommerce en andere plug-ins blijven normaal werken omdat hun verzoeken vanuit geauthenticeerde beheersessies komen. Bezoekers die /wp-json/wp/v2/users proberen te bereiken, ontvangen een 401-fout in plaats van gebruikersgegevens.

Houd in gedachten: gebruikt uw site een headless-frontend of heeft u een publieke functie die data via de REST API ophaalt (bijvoorbeeld een live-zoekfunctie die op de REST API draait), dan zal deze methode die functie kapotmaken. In zulke gevallen past de selectieve aanpak hieronder beter.

Schakel selectief alleen het users-eindpunt uit

Wilt u de REST API toegankelijk houden voor publiek gebruik maar specifiek gebruikersopsomming voorkomen, dan kunt u alleen de gebruikerseindpunten verwijderen:

add_filter('rest_endpoints', function($endpoints) {
    // Remove the users list endpoint
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    // Remove the single user endpoint
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P[\d]+)']);
    }
    return $endpoints;
});

Dit laat alle andere REST-API-routes functioneel terwijl het specifiek de aanvalsvector voor gebruikersopsomming blokkeert. Het is een goed compromis voor sites die openbare REST-API-toegang nodig hebben voor zoeken, inhoudsbevragingen of andere functies, maar gebruikersgegevens willen beschermen.

Verwijder de REST-API-discoverylink uit HTML

WordPress voegt een <link rel="https://api.w.org/">-tag toe in de HTML-head en een Link-koptekst in HTTP-responses. Deze vertellen geautomatiseerde tools waar de REST API te vinden is. Hoewel het verwijderen van deze tags de API niet daadwerkelijk uitschakelt (de eindpunten reageren nog steeds op hun gebruikelijke URL's), vermindert het wel de vindbaarheid:

// Remove the REST API link from the HTML head
remove_action('wp_head', 'rest_output_link_wp_head');

// Remove the REST API link from XML-RPC responses
remove_action('xmlrpc_rpc_methods', 'rest_output_link_wp_head');

// Remove the Link header from HTTP responses
remove_action('template_redirect', 'rest_output_link_header', 11);

Deze stap is het beste in combinatie met een van de bovenstaande beperkingsmethoden, niet op zichzelf. Het verwijderen van de linktag zonder de eigenlijke eindpunten te beperken is beveiliging door obscuriteit, wat minimale echte bescherming biedt.

Een plug-in gebruiken om REST-API-toegang te beheren

Voegt u liever geen aangepaste code toe, dan bieden verschillende plug-ins een gebruikersinterface voor het beheren van REST-API-toegang:

• Disable WP REST API: blokkeert alle REST-API-toegang voor niet-geauthenticeerde verzoeken met een eenvoudige schakelaar. Verdere configuratie is niet nodig na activering.
• WP REST API Controller: geeft u fijnmazige controle over welke eindpunten openbaar zijn en welke authenticatie vereisen, zodat u sommige routes kunt toestaan en andere kunt blokkeren.

De plug-in-aanpak is eenvoudiger te beheren maar voegt een afhankelijkheid toe. Wordt de plug-in tijdens een update gedeactiveerd of verwijderd, dan is uw REST API weer volledig openbaar. De aanpak op codebasis is betrouwbaarder voor langetermijnbescherming.

Uw REST-API-beperkingen testen

Verifieer na het toepassen van uw wijzigingen of zij correct werken. Open een incognito-browservenster (zodat u niet bent ingelogd) en probeer deze URL's op uw site te bereiken:

• https://yoursite.com/wp-json/wp/v2/users
• https://yoursite.com/wp-json/wp/v2/users/1
• https://yoursite.com/wp-json/

Werkt uw beperking, dan dienen deze een 401-fout of een lege response te retourneren in plaats van gebruikersgegevens. Log vervolgens in op uw WordPress-beheergedeelte en bevestig dat de Gutenberg-editor, uw formulieren en eventuele WooCommerce-functionaliteit nog steeds werken zoals verwacht.

Verifieer met InspectWP

Voer na het implementeren van uw wijzigingen een nieuwe InspectWP-scan uit op uw site. De beveiligingssectie van uw rapport toont of de REST API openbaar toegankelijk is en of het users-eindpunt data retourneert. Werkt de beperking correct, dan rapporteert InspectWP de API als niet toegankelijk of het user-eindpunt als beperkt.