403 Forbidden: wat de toegang tot je site blokkeert

Wat de fout betekent

Een 403 is geen storing: de server heeft het verzoek ontvangen, begrepen en besloten het niet te beantwoorden. De browser toont een pagina met “403 Forbidden”, “Toegang geweigerd” of de foutpagina van de site. Op een site van iemand anders is de reden meestal een keuze van de eigenaar: afgeschermde inhoud, een uitgesloten land of netwerk, een geblokkeerde VPN of IP-adres, te veel verzoeken in korte tijd. Je kunt alleen opnieuw proberen vanaf een ander netwerk, zonder VPN, na een paar minuten; blijft het, dan is het zo bedoeld.

Op je eigen site ligt het anders: een plotselinge 403, op alle pagina’s of in één map, komt bijna altijd door een verkeerd recht, een regel in een .htaccess, een beveiligingsregel die een gewoon verzoek voor een aanval aanzag, of een firewall. De rest van dit artikel gaat over dat geval.

Veelvoorkomende oorzaken op de eigen site

1. Rechten of eigenaar van de bestanden. Na een upload via SFTP, een teruggezette back-up of een andere PHP-gebruiker kan de webserver de bestanden niet lezen (bijvoorbeeld 600 in plaats van 644, mappen 700 in plaats van 755, een andere eigenaar dan de gebruiker van de webserver).
2. Een regel in .htaccess. Deny from all, Require all denied, een te brede IP-blokkade of een regel uit een tutorial die alles dichtzet. Geldt ook voor de .htaccess-bestanden in submappen.
3. Geen indexbestand. De map bevat geen index.html of index.php en Options -Indexes verbiedt een overzicht: Apache antwoordt 403 in plaats van een bestandslijst.
4. ModSecurity of de WAF. Een regel van de applicatiefirewall blokkeert een verzoek met woorden, tekens of velden die hem verdacht lijken: het opslaan van een bericht met een stuk code, een formulier met een URL erin, een upload.
5. Firewall of geoblokkade. Het paneel van de hostingprovider, een beveiligingsplugin of fail2ban heeft je IP-adres geblokkeerd na een paar verkeerde logins, of een heel land.
6. Cloudflare-regels. Een WAF-regel, een hoog beveiligingsniveau, een landblokkade of een “challenge” waar een bot (ook een monitoringdienst) niet doorheen komt.
7. Hotlinkbescherming. Afbeeldingen antwoorden 403 als ze vanaf een ander domein worden opgevraagd, soms ook vanaf je eigen domein, als de regel niet alle vormen van het domein bevat.

Als het je eigen site is: eerst controleren

Open de Website down checker: die zegt of de 403 ook vanaf onze locatie in Europa komt of alleen bij jou. Alleen bij jou: het is een blokkade van je IP-adres of je netwerk (oorzaak 5 of 6). Overal: ga verder met het foutlog, dat bij een 403 bijna altijd de precieze reden noemt.

# Apache: de reden van de 403 staat in het foutlog
sudo tail -n 50 /var/log/apache2/error.log

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# kan de webserver het bestand lezen?
ls -la /var/www/example.com/public/
namei -l /var/www/example.com/public/index.php

Zo lees je het log: client denied by server configuration wijst op een toegangsregel in .htaccess of de vhost; Permission denied of (13)Permission denied: access to / denied op de bestandsrechten; Directory index forbidden by Options directive op de map zonder indexbestand; ModSecurity: Access denied with code 403 met een regel-id op de WAF; in nginx directory index of "/var/www/…" is forbidden of open() … failed (13: Permission denied).

Oplossingen

1. Rechten en eigenaar herstellen

Voor een gewone site: bestanden 644, mappen 755, alles in eigendom van de gebruiker waaronder de webserver of PHP draait (vaak www-data, of je hostinggebruiker):

cd /var/www/example.com/public
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chown -R www-data:www-data .

Op shared hosting heeft het klantenpaneel meestal een functie “rechten herstellen”. Nooit 777: dat zet de site open voor iedereen op dezelfde machine.

2. De .htaccess corrigeren

Zoek de regels die de toegang weigeren en zet ze in commentaar of beperk ze:

grep -rn -iE "deny from|require all denied|require ip|order allow" /var/www/example.com/public --include=.htaccess

Weet je niet waar een regel vandaan komt, hernoem het bestand dan naar .htaccess.off, laad de pagina opnieuw en zet, als de 403 verdwijnt, de regels één voor één terug.

3. Een indexbestand toevoegen of een overzicht toestaan

Moet de map een pagina tonen, voeg dan index.html of index.php toe, of geef de juiste naam op met DirectoryIndex. Moet de map juist bestanden opsommen (een downloadmap), vervang Options -Indexes dan door Options +Indexes, alleen voor die map.

4. ModSecurity en WAF: de regel uitsluiten, niet alles uitzetten

Haal de id van de regel uit het log en schakel hem alleen uit voor het pad dat het nodig heeft:

<LocationMatch "/wp-admin/post.php">
    SecRuleRemoveById 941100
</LocationMatch>

Op shared hosting doe je hetzelfde vanuit het klantenpaneel (onderdeel ModSecurity of WAF), vaak per domein. De WAF voor de hele site uitzetten haalt een nuttige bescherming weg: kies liever een gerichte uitzondering.

5. Het IP-adres, het land of de bot deblokkeren

Controleer, in deze volgorde: de beveiligingsplugin van WordPress (geblokkeerde IP-adressen, landblokkade), fail2ban op de server (sudo fail2ban-client status, daarna sudo fail2ban-client set naam-jail unbanip 203.0.113.5), de firewall in het paneel van de hostingprovider, en bij Cloudflare de WAF-regels en het beveiligingsniveau. Moet een monitoringdienst de site blijven controleren, zet dan zijn user agent of zijn IP-adressen bij de uitzonderingen in plaats van de bescherming voor iedereen te verlagen.

6. Hotlinkbescherming

De regel moet alle vormen van je domein toestaan en ook verzoeken zonder Referer:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com/ [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F]

Als het probleem bij je hostingprovider ligt

Is het log niet toegankelijk en zijn rechten en .htaccess in orde, dan zit de blokkade in het paneel, de WAF of de firewall van de provider. Stuur dit bericht:

Goedemorgen, sinds ongeveer 10:00 uur (UTC) antwoordt mijn website example.com met “403 Forbidden” op alle pagina’s, ook vanaf verschillende netwerken. De bestandsrechten (644/755) en de .htaccess zijn correct en ik heb zelf niets gewijzigd. Kunt u nagaan of een regel van ModSecurity, de firewall of de geoblokkade aan uw kant mijn domein blokkeert, en mij de regel uit het log noemen?

Zodat het niet opnieuw gebeurt

Een plotselinge 403 volgt bijna altijd op een handeling: een herstelde back-up, een update van een beveiligingsplugin, een nieuwe regel. Een HTTP-controle van buitenaf merkt het bij de eerste ronde, omdat een 403 geen 200 is, en waarschuwt je vóór je bezoekers. Voor een WordPress-site houdt het WordPress onderhoud op aanvraag updates, plugins en beveiligingsmeldingen in de gaten, zonder contract. Blokkeert niet een regel maar een limiet op het aantal verzoeken? Dan is het een 429 Too Many Requests. Antwoordt de site met een serverfout en niet met een weigering? Lees dan de uitleg bij 500 Internal Server Error.

Down? Wij fixen het. Op je eigen server of op shared hosting met SSH-toegang herstelt de Quick Fix kleine configuratiefouten zoals verkeerde rechten of een regel te veel in de .htaccess, met eerst een back-up, tegen een vaste prijs, 24 uur per dag, ook in het weekend; de Deep Fix neemt WAF, firewall en applicatieregels voor zijn rekening, per blok van 15 minuten; de schatting is de bovengrens.