WordPress Mapstructuur Beveiliging: Toegang tot de "wp-includes" Map Blokkeren

WordPress mapstructuur beveiliging is het meest effectief door directe toegang tot PHP-bestanden in de "wp-includes" map te blokkeren en directory listing uit te schakelen, in plaats van de hele map volledig te weren. De map wp-includes bevat immers essentiële JavaScript-, CSS- en andere statische bestanden die nodig zijn voor het functioneren van de WordPress-kern. Het volledig blokkeren van deze map kan de website, de editor of plugin-functionaliteiten verstoren. De juiste aanpak is om bij Apache gebruik te maken van .htaccess regels, en bij Nginx via een location directive in de serverconfiguratie, waarmee directe PHP-toegang wordt geblokkeerd. Controleer daarna met 403/404 responses en uitgebreide tests of alles goed werkt.

Een veelgemaakte fout in WordPress beveiliging is het enkel vertrouwen op een sterk wachtwoord of beveiligingsplugin. Hackers scannen namelijk vaak naar verouderde plugins, onjuiste bestandsrechten, open directory listings en mappen met kernbestanden. De wp-includes map is daarbij een belangrijk doelwit. In deze gids lees je hoe je in een echte hostingomgeving de toegang tot wp-includes kunt beperken, welke regels problemen kunnen veroorzaken, voorbeelden voor Apache en Nginx, testmethoden en een checklist voor onderhoud. Voor een veiliger WordPress-onderkomen kun je ook onze WordPress hosting en voor de algemene beveiliging SSL certificaat overwegen.

Wat is de wp-includes map en waarom is deze bescherming nodig?

De wp-includes map is een van de hoofddirectories die de basisbibliotheken van de WordPress-kern bevatten. Het omvat onder andere de themasystemen, blokeditor, REST API componenten, media verwerking, klassen, functies en diverse JavaScript-bestanden. Simpel gezegd is wp-includes als de motorruimte van WordPress; het is geen plek waar bezoekers rechtstreeks toegang toe moeten hebben.

Een normale bezoeker hoeft bijvoorbeeld nooit de URL site.nl/wp-includes/ te openen. Toch kunnen in de broncode statische assets uit deze map geladen worden, zoals standaard scriptbestanden, emoji scripts of editorcomponenten. Daarom is het cruciaal om de beveiliging zo in te richten dat statische bestanden blijven werken, maar directe toegang tot PHP-bestanden wordt geblokkeerd.

Deze onderscheidende aanpak vormt de kern van professionele WordPress mapstructuur beveiliging. Willekeurig mappen blokkeren kan aanvankelijk veilig lijken, maar leidt vaak tot witte pagina’s, een kapotte admin interface, niet werkende blokeditors of verstoorde themaweergave. Het doel is om de benodigde bestanden te beschermen en tegelijkertijd het aanvalsvlak te verkleinen.

Wat levert het blokkeren van wp-includes toegang op?

Het blokkeren van directe uitvoering van PHP-bestanden in de wp-includes map stopt niet alle aanvallen, maar vermindert het risico aanzienlijk. Vooral bij geïnfecteerde sites proberen aanvallers vaak kwaadaardige PHP-bestanden te uploaden of bestaande bestanden via de URL te benaderen. Door directe webtoegang tot deze PHP-bestanden te verbieden bouw je een extra beveiligingslaag in.

De voordelen zijn onder andere:

• Beperking van directe oproepen naar kern PHP-bestanden via URL’s.
• Indien directory listing aanstaat, voorkomt het dat bezoekers de inhoud van de map zien.
• Vermindert onnodige informatielekken bij automatische botscans.
• Biedt bescherming op webserverniveau, ook zonder beveiligingsplugin.
• Versterkt gelaagde beveiliging in combinatie met WAF, SSL, actuele PHP-versies en juiste bestandsrechten.

Belangrijk is te beseffen dat dit slechts één laag in de beveiliging is. Als plugins verouderd zijn, admin-wachtwoorden zwak zijn of FTP-accounts gecompromitteerd zijn, is dit niet voldoende. Beveiliging is een samenspel van hosting, applicatiebeheer, gebruikersbeheer en regelmatig onderhoud. Voor een solide fundament kun je onze Veilige Web Hosting en extra domeinbeveiligingsopties in Domeinbeveiliging bekijken.

Veelvoorkomende fouten bij het blokkeren van wp-includes

De hele map blokkeren

De meest gemaakte fout is het volledig blokkeren van alle HTTP-verzoeken naar wp-includes met een 403 status. Dit lijkt logisch, maar omdat WordPress sommige statische bestanden vanuit deze map laadt, kan dit onverwachte problemen geven. Bijvoorbeeld, de blokeditor kan niet laden, JavaScript bestanden werken niet, of er ontstaan kleine maar belangrijke ontwerpafwijkingen aan de voorkant.

Regels live zetten zonder testen

Een kleine fout in .htaccess of Nginx configuratie kan een 500 Internal Server Error veroorzaken. Vooral bij drukbezochte sites is het riskant om direct live aanpassingen door te voeren. Maak eerst een backup, test zo mogelijk in een staging omgeving en ga daarna gecontroleerd live. Bij Hostragons kun je bijvoorbeeld gebruikmaken van Web Hosting Backup voor back-ups en staging.

Volledig vertrouwen op beveiligingsplugins

Beveiligingsplugins zijn nuttig, maar serverniveau regels werken eerder en efficiënter. Als Apache of Nginx een verzoek al blokkeert voordat PHP wordt aangeroepen, verbruik je minder serverbronnen. Daarom mag je serverregels niet negeren, ook niet als je plugins gebruikt.

Checklist voor je begint

Voordat je wp-includes toegang beperkt, is een goede voorbereiding essentieel om storingen te voorkomen. Deze checklist is vooral aanbevolen voor live WordPress sites:

• Maak een backup van de huidige .htaccess of Nginx configuraties.
• Update WordPress-kern, thema’s en plugins naar de nieuwste versies.
• Zorg dat je PHP-versie ondersteund en veilig is.
• Controleer bestandsrechten: mappen meestal 755, bestanden 644.
• Beperk schrijfrechten op kritieke bestanden zoals wp-config.php en .htaccess.
• Plan cache-opschoning na wijzigingen als je cache, CDN of beveiligingsplugins gebruikt.
• Maak een testlijst voor cruciale pagina’s zoals admin dashboard, homepage, berichten, contact en checkout.

Deze voorbereiding kost zo’n 10-15 minuten, maar voorkomt urenlange downtime die door een verkeerde regel kan ontstaan. Bij zakelijke sites is het verstandig om dit tijdens rustige uren te doen.

wp-includes PHP-toegang blokkeren via .htaccess op Apache

Op Apache shared hosting is de meest gebruikte methode via het .htaccess bestand. Door de juiste regels toe te voegen in het .htaccess bestand in de hoofdmap van WordPress, kun je directe PHP-aanroepen in wp-includes blokkeren. Maak vooraf altijd een kopie van het bestand, lokaal of via je hostingpaneel.

Aanbevolen .htaccess regel

Onderstaande regel blokkeert directe PHP-toegang in wp-includes, maar laat statische bestanden werken:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

De logica is simpel: als de URL begint met wp-includes en eindigt op .php, wordt het verzoek geweigerd. Hierdoor zijn PHP-bestanden in die map niet via de browser bereikbaar, terwijl .js, .css, .png en andere statische bestanden nog gewoon laden. Dit biedt een veilige balans voor de frontend en backend.

Directory listing uitschakelen

Een andere belangrijke instelling is het uitschakelen van directory listing. Staat dit aan, dan kunnen bezoekers mappen bekijken zonder een indexbestand. Voeg deze regel toe aan je hoofd .htaccess bestand:

Options -Indexes

Deze regel zorgt ervoor dat mappen zonder indexbestand niet als lijst worden getoond. Meestal staat dit standaard uit, maar het is goed om dit te controleren als onderdeel van je beveiligingsbeleid.

Testen na aanpassing

Voer na het toevoegen van de regels de volgende tests uit:

• Open siteadres.nl/wp-includes/ - er mag geen directory listing zichtbaar zijn.
• Probeer een bekend PHP-bestand uit wp-includes direct te laden - je moet een 403 of 404 krijgen.
• Controleer homepage, blogposts en het admin dashboard op fouten.
• Gebruik browser devtools om in Console en Network tab te zoeken naar 404/403 fouten.
• Maak cache leeg als je caching, CDN of beveiligingsplugins gebruikt.

Als alles werkt, kun je de regels in productie houden. Bij een 500 error verwijder je de regels en zet je de backup terug.

wp-includes PHP toegang blokkeren bij Nginx

Op Nginx servers werkt .htaccess niet. Hier moet je de blokkade toevoegen in de siteconfiguratie, meestal in het serverblok. Hiervoor heb je SSH-toegang en kennis van serverbeheer nodig. Bij twijfel kun je het beste contact opnemen met je hosting provider.

Aanbevolen Nginx locatieblok

De basale regel ziet er zo uit:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

Deze directive blokkeert alle PHP-bestanden in wp-includes. Vergeet niet de configuratie te testen met:

nginx -t

Als dit succesvol is, herlaad je Nginx met:

systemctl reload nginx

Herstarten is minder gewenst omdat reload actieve verbindingen niet onderbreekt. Bij live sites is het aan te raden dit in rustige periodes te doen.

Let op bij Nginx

• Voeg de regel toe in het juiste serverblok, zeker als je meerdere sites op één server hebt.
• Maak testen pas na het leegmaken van CDN cache of reverse proxy cache.
• Zorg dat PHP-FPM alleen de juiste bestanden afhandelt.
• Controleer access.log en error.log voor foutmeldingen na wijziging.

De volgorde van locatieblokken in Nginx is cruciaal; zorg dat deze regel niet conflicteert met permalink- of PHP-verwerkingsregels van WordPress.

Vergelijking van methoden

Onderstaande tabel vat de belangrijkste manieren samen om toegang tot wp-includes te beperken:

In de praktijk levert een combinatie van bovenstaande methodes de beste beveiliging. Bijvoorbeeld een .htaccess regel op Apache, correcte bestandsrechten, een actuele WordPress-kern, SSL en regelmatige back-ups vormen samen een gelaagde verdedigingslinie. Omdat ook firewall en isolatie op hostingniveau belangrijk zijn, maken Zakelijk Hosting pakketten het verschil bij kritieke sites.

Bestandsrechten en eigenaarschap

Het blokkeren van wp-includes is onvolledig als bestandsrechten niet goed zijn ingesteld. De algemeen geaccepteerde instellingen in WordPress zijn 755 voor mappen en 644 voor bestanden. Deze rechten geven de webserver leesrechten zonder onnodig schrijfrecht. Sommige hostingomgevingen hebben afwijkende gebruikers- en groepsinstellingen, check daarom ook de aanbevelingen van je hostingprovider.

777 rechten zijn een groot beveiligingsrisico, omdat iedereen dan kan schrijven. Mappen die beschrijfbaar moeten zijn, zoals wp-content/uploads, moeten alsnog PHP-uitvoering blokkeren. Voor wp-includes geldt dat deze map normaal gesproken alleen door WordPress updates beschrijfbaar is, niet door gebruikers.

Tijdens een beveiligingsaudit kun je controleren of deze waarden gelden:

• wp-includes map: meestal 755
• PHP-bestanden in wp-includes: meestal 644
• wp-config.php: bij voorkeur 600 of zo beperkt mogelijk volgens hosting
• .htaccess: meestal 644 zonder onnodige schrijfrechten

Deze instellingen kunnen per server verschillen. Verkeerde rechten kunnen ervoor zorgen dat je site niet kan updaten of bestanden niet kan lezen. Controleer na wijzigingen de WordPress gezondheid en error logs.

Doen beveiligingsplugins dit ook?

Beveiligingsplugins zoals Wordfence of iThemes Security kunnen automatisch hardening regels voorstellen. Ze bieden bescherming tegen brute force, wijzigingen aan bestanden, malware scans en login beveiliging. Maar wat ze precies doen met betrekking tot wp-includes verschilt.

Sommige plugins passen automatisch .htaccess aan, anderen beschermen alleen op applicatieniveau. Omdat applicatieniveau bescherming pas werkt als het verzoek tot aan PHP komt, is serverniveau blokkade meestal effectiever. Daarom is een professionele aanpak een combinatie van plugin en serverconfiguratie.

Als je een beveiligingsplugin gebruikt, controleer dan het volgende:

• Of de plugin .htaccess of Nginx regels toevoegt of aanpast.
• Dat dubbele regels geen conflicten veroorzaken.
• Of beveiligingsinstellingen na updates ongewijzigd blijven.
• Monitor de performance, cache en serverbronnen na wijzigingen.

Meerdere beveiligingsplugins tegelijk gebruiken is vaak geen goed idee. Firewall- en rewrite regels kunnen conflicteren en leiden tot prestatieverlies of false positives.

wp-includes beveiliging testen: een praktische aanpak

Je weet pas zeker dat alles werkt als je niet alleen de site kunt openen. Volg deze 7-stappen test die toepasbaar is voor kleine bedrijfswebsites tot e-commerce projecten:

• 1. Open de homepage in een incognito venster en check op visuele afwijkingen.
• 2. Bezoek een blogpost, categoriepagina en zoekresultatenpagina.
• 3. Log in op wp-admin en open de blokeditor en mediabibliotheek.
• 4. Check in de browser developer tools het Console-tabblad op fouten.
• 5. Controleer in het Network-tabblad of statische bestanden uit wp-includes niet onnodig geblokkeerd worden.
• 6. Probeer een PHP-bestand in wp-includes direct te openen; je verwacht een 403 of 404.
• 7. Bekijk de server error logs op nieuwe of terugkerende fouten.

Deze test duurt ongeveer 5 minuten en ontdekt snel configuratiefouten. Bij sites met WooCommerce of betaalprocessen moet je ook winkelwagen, checkout en gebruikersaccount extra controleren. Zelfs een kleine JavaScript storing kan de conversie verminderen.

Aanvullende WordPress mapstructuur beveiligingsmaatregelen

De bescherming van wp-includes is een goed begin, maar WordPress beveiliging moet breder worden gezien. De volgende maatregelen verminderen het aanvalsvlak verder:

• Verberg liever niet de WordPress versie, maar houd de kern up-to-date.
• Verwijder ongebruikte thema’s en plugins volledig.
• Maak admin gebruikersnamen moeilijk te raden.
• Gebruik tweestapsverificatie (2FA).
• Beperk of schakel XML-RPC uit als je het niet gebruikt.
• Pas rate limiting of extra verificatie toe op wp-login.php.
• Implementeer automatische dagelijkse back-ups en test het herstel.
• Gebruik overal HTTPS; zonder SSL zijn inloggegevens kwetsbaar.

SSL sluit wp-includes zelf niet af, maar beschermt sessies, formulierdata en admin verkeer. Daarom is SSL altijd een van de eerste beveiligingslagen in WordPress handleidingen. Plaats hier bijvoorbeeld natuurlijke links naar kocht SSL certificaat en Gratis SSL Installatie.

Wanneer professionele hulp inschakelen?

Voor een eenvoudige Apache shared hosting is het toevoegen van een .htaccess regel meestal goed te doen. Maar bij speciale Nginx setups, multisite netwerken, WooCommerce winkels, drukke nieuwssites of bedrijfsportalen is professionele ondersteuning aan te raden. Beveiligingsregels moeten technisch correct én betrouwbaar zijn voor de continuïteit van de site.

Overweeg hulp in de volgende situaties:

• Je host meerdere WordPress sites op dezelfde server.
• Je gebruikt Nginx, Varnish, CDN en WAF tegelijk.
• Na wijzigingen nemen 403, 404 of 500 fouten toe.
• De site is eerder geïnfecteerd geweest met malware.
• Je draait een systeem met betalingen, lidmaatschap of persoonsgegevens.

Een veilige hostingomgeving, goede isolatie, regelmatige back-ups en deskundige ondersteuning zijn onzichtbare maar cruciale onderdelen van WordPress beveiliging. Kijk bij het kiezen van hosting niet alleen naar opslag, maar ook naar back-upmogelijkheden, firewall, PHP versie ondersteuning, SSL beheer en supportkwaliteit. Onze Hostragons hosting pakketten en WordPress Site Verhuizing artikelen kunnen hierbij helpen.

Conclusie

De juiste manier om toegang tot de wp-includes map te beperken is niet door de hele map te blokkeren, maar door directe webtoegang tot PHP-bestanden daarin te verbieden en directory listing uit te schakelen. Met .htaccess regels voor Apache of location directives voor Nginx is dit snel te realiseren. Maak altijd eerst een backup, test daarna de front- en backend grondig.

Samengevat: zorg dat statische bestanden blijven werken, beperk PHP toegang, schakel directory listing uit, controleer bestandsrechten en houd je site up-to-date. Voor een veiliger en beter beheersbaar WordPress platform kun je de hosting-, domein- en SSL-oplossingen van Hostragons bekijken en waar nodig ondersteuning inschakelen.

Veelgestelde vragen

Is het veilig om de wp-includes map volledig te blokkeren?

Dat wordt meestal afgeraden. In wp-includes zitten belangrijke JavaScript, CSS en statische bestanden die WordPress nodig heeft. Een volledige blokkade kan de site of het admin dashboard verstoren. Een veiliger aanpak is alleen directe toegang tot PHP-bestanden in deze map te blokkeren.

Wat moet ik doen bij een 500 error na toevoegen van .htaccess regels?

Verwijder eerst de recent toegevoegde regels of herstel het backup .htaccess bestand. Controleer daarna de syntax van de regels. Als het probleem blijft, raadpleeg dan de hosting error logs of neem contact op met technische support.

Werkt .htaccess ook op Nginx servers?

Nee. .htaccess wordt alleen ondersteund door Apache en LiteSpeed. Op Nginx moet je soortgelijke beperkingen aanbrengen in de serverconfiguratie via location regels, en de configuratie testen met nginx -t.

Maakt deze maatregel mijn WordPress site volledig veilig?

Nee. Het blokkeren van PHP-toegang in wp-includes is een belangrijke beveiligingslaag, maar niet genoeg op zichzelf. Update regelmatig, gebruik sterke wachtwoorden, tweestapsverificatie, SSL, back-ups, firewalls en correcte bestandsrechten voor optimale beveiliging.

Moet ik deze regels toevoegen als ik al een beveiligingsplugin gebruik?

Dat hangt af van wat de plugin doet. Sommige plugins voegen zelf .htaccess regels toe, anderen werken alleen op applicatieniveau. Serverniveau blokkade van PHP toegang is meestal sterker, dus het combineren van plugin en serverregels is aan te raden mits er geen conflicten ontstaan.