Het eerste wat ik bij een 403 op wp-admin wil vaststellen is dat dit niet hetzelfde probleem is als een 403 aan de voorkant van je site, en dat de volgorde van waarschijnlijke oorzaken anders ligt. De voorkant laadt prima. De pagina's renderen voor bezoekers. De blokkade is chirurgisch: elk verzoek naar wp-admin/, wp-login.php of admin-ajax.php geeft 403 Forbidden, en niets anders. Die asymmetrie is precies waarom dit artikel los staat van 403 Forbidden aan de WordPress-voorkant.
Waar dit artikel wel en niet over gaat
Dit artikel gaat over het geval dat je publieke site gewoon werkt, maar je een 403 krijgt zodra je het beheergebied raakt. Valt de 403 ook aan de voorkant, of op één specifieke afbeelding of map op de publieke site, dan zit je in de front-end-variant en is 403 Forbidden in WordPress het juiste artikel. De vijf mechanismen hieronder overlappen qua naam met die van de voorkant, maar de volgorde van waarschijnlijkheid is omgedraaid en de diagnose loopt anders. Het beheergebied zit nu eenmaal achter extra beschermlagen die bezoekers nooit triggeren.
Wat "403 op wp-admin" eigenlijk betekent
Een 403 Forbidden-respons betekent dat de server het verzoek wel begrijpt, maar besloot het niet uit te voeren. Volgens RFC 9110 §15.5.4 is een 403: "the server understood the request but refuses to authorize it". Op het WordPress-beheergebied kan die weigering komen uit één van drie lagen vóór WordPress (een WAF, de webserver zelf, of een directory-niveau toegangsregel) of uit één van twee lagen daaronder (bestandsrechten of een hotlink-regel die op admin-ajax.php afgaat). PHP draait niet. WordPress ziet het verzoek niet. De blokkade gebeurt nog voordat WordPress je überhaupt kan inloggen.
Dat ene gegeven is wat dit onderscheidt van "geen toegang tot wp-admin" zonder 403. Reageert WordPress nog wél, ook al is dat met een redirect, dan hebben de lagen ervoor het verzoek toegelaten. Voor de stille variant lees je geen toegang tot wp-admin zonder foutmelding.
De vijf mechanismen achter een wp-admin-only 403
1. Een WAF of ModSecurity-regel blokkeert POST-verkeer naar wp-login.php of wp-admin
Dit is de topoorzaak op de admin-variant, sterker nog dan op de voorkant. WAF's hangen strengere regelsets aan adminpaden, omdat dat de plek is waar credential stuffing, brute force en authenticated exploits binnenkomen. Een POST naar wp-login.php draagt een gebruikersnaam en een wachtwoord, en dat triggert form-handling regels. Een POST naar admin-ajax.php draagt geserialiseerde data, en dat triggert deserialisatie-pattern checks. De OWASP Core Rule Set, die de meeste managed hosting WAF's in een of andere vorm meeleveren, scoort beide standaard als verhoogd risico, en een verzoek dat boven de drempel komt, wordt met een 403 afgewezen voordat WordPress het ziet.
De signatuur is dat de voorkant laadt, maar dat elke loginpoging of elke actie binnen wp-admin/ een 403 oplevert. Soms haalt de pagina nog wel het loginformulier en valt de 403 pas bij submit. Soms valt de 403 op de URL zelf, voordat het formulier überhaupt rendert. In beide gevallen draagt de respons meestal een generieke blokpagina (Cloudflare, Sucuri, Wordfence Central, of de eigen WAF van je host) en niks wat op WordPress lijkt.
2. Een webserver-toegangsregel blokkeert verzoeken naar /wp-admin/ of wp-login.php
De webserver zelf kan een pad weigeren te serveren voordat er ook maar applicatielogica draait. Op Apache betekent dat een Require all denied-directive, een ouderwets Deny from all-blok, of een RewriteRule ... [F]-regel die op het beheergebied gericht staat. Op nginx betekent dat een allow en deny-paar in een location /wp-admin/-blok, of een return 403 binnen datzelfde blok, allebei te vinden in de reference van ngx_http_access_module.
De versie die ik het vaakst tegenkom is een IP-allowlist die ooit door iemand is neergezet om de admin dicht te zetten en daarna nooit meer is aangeraakt. Die allowlist werkt prima totdat je IP verandert, je van netwerk wisselt, je provider je adres roteert, of je vanaf een ander kantoor probeert in te loggen. Ineens krijg jij 403 op de admin (en alleen jij), terwijl het voor de IP's op de lijst nog gewoon werkt. De blokkade staat los van of je een account hebt of wat je wachtwoord is, want hij valt voordat WordPress überhaupt geladen wordt.
3. Een .htaccess-deny binnen /wp-admin/ weigert toegang (alleen Apache)
Dit is hetzelfde mechanisme als oorzaak 2, maar met een nauwere scope. WordPress levert standaard een .htaccess in de site-root mee, maar plugins, security-tools en oude hardening-tutorials hebben de gewoonte om een tweede .htaccess rechtstreeks in wp-admin/ te zetten met een Require-blok, een IP-allowlist of een <Files wp-login.php>-blok dat de toegang beperkt. Het verschil is belangrijk voor je diagnose: de regel zit in een ander bestand, en de root-.htaccess hernoemen helpt niks. Je moet specifiek binnen wp-admin/ kijken.
De signatuur is dat de voorkant gezond is, de root-.htaccess er normaal uitziet, en de 403 alleen verdwijnt als je het .htaccess-bestand binnen wp-admin/ hernoemt of weghaalt. nginx leest helemaal geen .htaccess-bestanden, dus deze oorzaak speelt op een nginx-host niet. Draai je op nginx (of nginx voor PHP-FPM), sla deze dan over en spring naar oorzaak 2 of oorzaak 4.
4. Bestandsrechten op wp-admin/ of de bestanden erin kloppen niet
Als de webserver-user een bestand niet kan lezen, kan hij het niet serveren, en dan geeft Apache of nginx een 403 terug. De WordPress file permissions-documentatie noemt 755 voor mappen en 644 voor bestanden, en zegt expliciet dat te strenge waarden serverfouten produceren omdat de webserver niet bij het bestand kan. Een migratie die de verkeerde eigenaar meenam, een hardening-script dat alles op 600 zette, of een handmatige chmod 700 wp-admin/ levert een 403 op voor elk bestand binnen het beheergebied terwijl de voorkant prima blijft draaien. WordPress serveert de voorkant via index.php in de site-root en het beheergebied via bestanden binnen wp-admin/, en die paden vallen allebei onder hun eigen rechten.
De signatuur is dat de 403 elk bestand onder wp-admin/ raakt, de voorkant werkt, en de error log van de server Permission denied-regels bevat die bestanden binnen wp-admin/ noemen. Dit is de oorzaak die het vaakst per ongeluk als WAF-probleem wordt aangezien, want vanuit de browser ziet het er identiek uit. De aanwijzing zit in de error log.
5. Een hotlink- of referrer-regel weigert verzoeken naar admin-ajax.php
Hotlink-protectieregels kijken naar de Referer-header op binnenkomende verzoeken en wijzen alles af wat niet van je eigen domein komt. Ze zijn bedoeld om andere sites te beletten je afbeeldingen te embedden. Ze gaan af en toe ook af op admin-ajax.php, omdat admin-ajax-verzoeken een Referer meedragen die naar de adminpagina wijst die ze afvuurde. Een referrer-regel die jouw front-end-domein wel kent maar het adminpad zelf niet, kan zo'n verzoek behandelen alsof het van buitenaf komt. Het resultaat is dat saves in de blockeditor, AJAX-acties van plugins en elke handeling die admin-ajax.php gebruikt 403 geven, terwijl de adminpagina zelf gewoon laadde.
De signatuur is dat het dashboard rendert, maar dat specifieke acties (een bericht opslaan, een tab wisselen op een plugin-instellingenpagina, of wat dan ook dat op de achtergrond admin-ajax.php aanroept) een 403 opleveren in het netwerk-tabblad van de devtools. De HTML laadde prima. De XHR niet. Dit is de zeldzaamste van de vijf oorzaken op deze lijst, maar het levert wel een bijzonder verwarrend foutbeeld op: de admin ziet er gezond uit totdat je er iets mee probeert te doen.
Wat deze 403 níet is
Deze sectie voorkomt het meeste verspilde zoekwerk. Een 403 op wp-admin lijkt op een aantal andere login-problemen, maar het mechanisme eronder is bij elk anders, en het juiste artikel om te lezen is dat dus ook.
- Het is geen algemene, site-brede 403. Geeft de voorkant óók een 403, of zit het probleem op één specifieke pagina of asset op de publieke site? Dan zit je in 403 Forbidden in WordPress. Dat artikel behandelt WAF's tegen de voorkant, bestandsrechten op
wp-content/,.htaccess-regels in de site-root, ontbrekende directory-indexen en hotlink-protectie op assets. De volgorde van waarschijnlijkheid is anders, en het fix-pad ook. - Het is geen login- of wachtwoord-probleem. Een 403 valt voordat WordPress je inloggegevens controleert. Het inlogformulier verschijnt of normaal en geeft een 403 op submit, of komt helemaal niet in beeld. Er is geen "wachtwoord onjuist", want er is nooit een wachtwoord gecheckt. Krijg je wél een zichtbare melding van WordPress dat je inloggegevens niet kloppen, dan heeft de server het verzoek doorgelaten en zit je in de familie waarom je niet kunt inloggen in WordPress.
- Het is geen cookie-probleem. Een cookie-probleem produceert een redirect-loop of een stille bounce terug naar
wp-login.phpna een geslaagde submit. Er valt nergens in die keten een 403. Past dat bij jouw symptoom (je logt in, het formulier accepteert je, en je belandt zonder melding terug op het inlogscherm), lees dan cookies geblokkeerd of niet ondersteund in WordPress en het artikel over de WordPress login redirect loop. - Het is niet de stille no-access-variant. "Geen toegang tot
wp-adminzonder foutmelding" betekent dat de server een 200 OK teruggeeft en WordPress zelf besluit je niks te tonen. Er staat helemaal geen foutcode op de lijn. Kom je op de admin-URL uit en zie je een blanco pagina, een redirect naar de voorkant, of een halfgerenderd dashboard, lees dan geen toegang tot wp-admin zonder foutmelding. De diagnose is compleet anders, omdat geen enkele beschermlaag vóór WordPress erbij betrokken is. - Het is niet "Sorry, je hebt geen toestemming om deze pagina te bekijken". Die melding komt vanuit WordPress zelf, nadat je al ingelogd bent. De login-pipeline is geslaagd, de cookies zijn aangekomen, en een capability-check op een specifiek adminscherm heeft je geweigerd. Lees Sorry, you are not allowed to access this page in WordPress oplossen. Dat is een rechten-melding ín de applicatie, niet een 403 uit de laag ervoor.