Een 403 Forbidden in WordPress is een van de weinige foutmeldingen die precies zegt wat er gebeurt en niets over waarom. De server heeft uw verzoek ontvangen, begrepen, en besloten het niet uit te voeren. Geen storing, geen overbelasting: een weigering.
Die weigering kan van vier verschillende lagen komen: van uw hostingpartij, van een beveiligingsplugin, van de bestandsrechten of van WordPress zelf. Hieronder de oorzaken op volgorde van hoe vaak we ze tegenkomen, met per stuk wat u eraan doet.
403 Forbidden in WordPress: eerst uitzoeken wat er wordt geweigerd
Dat scheelt de helft van het zoekwerk. Stel uzelf drie vragen:
- Krijgt u de melding op de hele site of op één pagina? De hele site wijst naar de server of het htaccess-bestand. Eén pagina wijst naar een plugin of een rechtenprobleem op een specifiek bestand.
- Krijgt u hem alleen op wp-admin, of ook op de voorkant? Alleen in het beheerscherm betekent bijna altijd een beveiligingsmaatregel of een IP-blokkade.
- Krijgen anderen hem ook? Vraag iemand buiten uw kantoor om de site te openen, of gebruik uw telefoon op mobiel internet in plaats van wifi. Werkt het daar wel, dan is uw eigen IP-adres geblokkeerd, en dat is verreweg de meest voorkomende oorzaak.
Met die drie antwoorden weet u meestal al in welke richting u moet zoeken.
De zes gangbare oorzaken van een 403
Oorzaak 1: uw eigen IP-adres is geblokkeerd
Beveiligingsplugins blokkeren een IP-adres na een aantal mislukte inlogpogingen. Heeft u drie keer een verkeerd wachtwoord getypt, dan zet de plugin u er tijdelijk uit. Vaak duurt dat twintig minuten tot een uur en lost het zich vanzelf op.
Wat u kunt doen: wacht een uur, of open de site via mobiel internet om te bevestigen dat het hieraan ligt. Blijft het aanhouden, dan moet iemand met toegang tot de bestanden de plugin tijdelijk uitzetten door de map te hernoemen. Zo’n blokkade is standaardgedrag van beveiligingsplugins en geen teken dat uw site besmet is.
Oorzaak 2: bestandsrechten die niet kloppen
Elk bestand op uw server heeft rechten die bepalen wie het mag lezen of aanpassen. Staan die verkeerd, dan weigert de server toegang, ook aan gewone bezoekers.
De gangbare instelling is 755 voor mappen en 644 voor bestanden. Staat een map op 777, dan is dat niet alleen onveilig maar bij sommige servers ook een directe reden voor een 403. Dit gebeurt vaak na een handmatige verhuizing of nadat iemand met een bestandsbeheerder heeft zitten schuiven. De uitleg met de juiste waarden staat bij de juiste bestandsrechten voor een WordPress-site.
Oorzaak 3: een beschadigd htaccess-bestand
Het htaccess-bestand stuurt hoe de webserver met verzoeken omgaat. Plugins schrijven erin, en soms gaat dat mis, bijvoorbeeld als twee plugins tegelijk regels toevoegen.
De test is eenvoudig. Hernoem het bestand via uw bestandsbeheerder of FTP naar htaccess-oud. Werkt de site weer, dan zat het daar. Ga daarna in WordPress naar Instellingen en dan Permalinks en klik op Wijzigingen opslaan zonder iets aan te passen; WordPress maakt dan een schoon bestand aan. Vergeet dat laatste niet, anders krijgt u foutpagina’s op al uw subpagina’s. De uitgebreide werkwijze staat bij het herstellen van een beschadigd htaccess-bestand.
Oorzaak 4: de firewall van uw hosting
Vrijwel elke Nederlandse hostingpartij heeft een firewall op serverniveau, en die kan verzoeken tegenhouden die er verdacht uitzien. Een klassiek voorbeeld: u plakt een tekst met bepaalde tekens in een pagina en krijgt bij het opslaan een 403. De firewall herkent het patroon als een aanvalspoging, terwijl u gewoon een stuk code in een tekstblok zette.
Dit lost u niet zelf op. Bel of mail uw hostingpartij met het exacte tijdstip van de melding en het adres van de pagina; zij kunnen in hun logboek precies zien welke regel is afgegaan en die aanpassen. Vermeld het tijdstip echt, want zonder dat duurt het zoeken veel langer.
Oorzaak 5 en 6: plugins en de indexinstelling
Een plugin die te streng staat. Beveiligingsplugins hebben instellingen die hele mappen afschermen. Zet in een testomgeving, of desnoods heel kort op de live site, alle plugins uit en kijk of de melding weg is. Zo ja, zet ze één voor één weer aan. Werk daarbij in kleine stappen en noteer na elke stap wat u ziet.
Een ontbrekende indexpagina. Krijgt u de 403 alleen op een specifieke map, dan ontbreekt daar waarschijnlijk een indexbestand terwijl de server het tonen van mapinhoud verbiedt. Dat is meestal geen probleem maar een correcte instelling; u linkt dan gewoon naar een adres dat niet bedoeld is om te openen.
Wat u niet moet doen
Twee adviezen die op internet circuleren en die u kunt negeren.
Zet geen rechten op 777. Dit lost de melding soms op en opent tegelijk uw site voor iedereen die er iets in wil schrijven. Het is de digitale variant van uw voordeur openzetten omdat de sleutel klemt.
Verwijder niet zomaar het htaccess-bestand. Hernoem het, zodat u het terug kunt zetten. Er kunnen doorverwijzingen in staan die u kwijt bent zodra u het weggooit.
En maak eerst een back-up voordat u aan bestanden komt. Dat klinkt als een standaardzin, maar bij een 403 wordt er vaak in bestanden gerommeld door mensen die er niet dagelijks mee werken.
Wanneer u het uit handen geeft
Heeft u de eerste drie oorzaken uitgesloten en bent u er nog niet, dan wordt het snel technisch. Op dat punt is doorgaan met proberen risicovoller dan het probleem zelf, zeker als u met bestandsrechten of serverinstellingen aan de slag gaat.
Voor een ervaren beheerder is een 403 doorgaans binnen een half uur te herleiden, omdat die in de serverlogboeken kan zien welke regel de weigering veroorzaakte. Dat is dan ook het eerste wat er bij het oplossen van foutmeldingen op een WordPress-site gebeurt: niet gokken, maar het logboek erbij pakken. Vraagt iemand dat niet op maar begint hij meteen met rechten aanpassen, dan is dat geen goed teken.
Praktische eerste stap voor u: probeer de site te openen op uw telefoon met wifi uit. Werkt hij daar wel, dan weet u binnen dertig seconden dat het om een blokkade van uw eigen IP-adres gaat en niet om iets ernstigs aan uw site.
