403 Forbidden: oorzaken, fixes en botblokkades die monitors foppen

2026-09-04 Bijgewerkt: 2026-09-14

Een 403 Forbidden betekent dat de server het verzoek prima begreep en weigert het te bedienen, en inloggen verandert daar niets aan. Anders dan een 401, die om inloggegevens vraagt, is een 403 een beslissing: deze client, bij dit verzoek, mag het niet.

403 versus 401

RFC 9110 trekt de lijn duidelijk. Een 401 Unauthorized betekent dat authenticatie vereist is of dat de opgegeven inloggegevens niet werden geaccepteerd, en het antwoord moet een header WWW-Authenticate dragen die beschrijft hoe te authenticeren. Een 403 Forbidden betekent dat de server weigert het verzoek te autoriseren, en opnieuw authenticeren helpt niet.

De spec staat een server ook toe met 404 te antwoorden in plaats van 403 wanneer hij niet wil onthullen dat een resource überhaupt bestaat. Daarom kan een URL waarvan u weet dat hij er is, "niet gevonden" teruggeven van een gehardende server. Onderzoekt u een 403, onthoud dan dat het omgekeerde geval ook bestaat.

Wat een 403 produceert

Bestandssysteemrechten. Het webserverproces kan het bestand niet lezen of de directory niet doorlopen. Een klassieker na een handmatige bestandskopie of een herstel dat eigendom wijzigde.
Directorylisting uitgeschakeld. Een verzoek voor een map zonder indexbestand geeft 403 terug op servers geconfigureerd om listings te weigeren. Correct gedrag, verwarrende foutmelding.
Applicatie-autorisatieregels. De gebruiker is ingelogd maar mist de rol, het abonnement of het tenantlidmaatschap dat voor die resource vereist is.
IP-allow- en denylijsten. Een adminpad beperkt tot kantooradressen geeft 403 terug voor iedereen anders, inclusief wie test vanuit huis of vanaf een mobiel netwerk.
Regels van een web application firewall. Een WAF blokkeert een verzoek waarvan de URL, headers of body met een signatuur matchten. Het verzoek ziet er voor u vaak volledig onschuldig uit.
Geoblokkering. Verkeer uit sommige landen of regio's wordt bij de edge geweigerd, dus de site is prima vanaf het ene continent en verboden vanaf het andere.
Hotlinkbescherming. Een regel die verzoeken afwijst voor afbeeldingen of media waarvan de header Referer ontbreekt of naar een ander domein wijst. Verzoeken zonder referrer worden vaak per ongeluk gevangen.
Bot- en user-agentfiltering. Het verzoek wordt geblokkeerd op basis van wie de client beweert te zijn, niet wat hij vroeg. Dit is het geval dat monitoring vangt.

Het geval "403 voor monitors, 200 voor mensen"

Dit is het meest voorkomende vals alarm in uptimemonitoring, en het is geen monitoringbug. De site geeft werkelijk 403 terug, alleen niet aan browsers.

Botmanagement bij een CDN of WAF scoort elk verzoek op zijn user agent, TLS-fingerprint, headervolgorde, IP-reputatie en of het een JavaScript- of interactieve uitdaging oplost. Een geautomatiseerde HTTP-check is, per ontwerp, een geautomatiseerde client: hij draait geen JavaScript-uitdagingen en identificeert zich eerlijk. Dus wordt hij uitgedaagd of geblokkeerd terwijl uw browser er zo doorheen glijdt, en het resultaat is een site die als down waarschuwt terwijl elke mens bevestigt dat hij up is.

Twee signalen herkennen het snel: de 403 komt meteen aan in plaats van na een vertraging, wat overbelasting uitsluit, en het is consistent voor de geautomatiseerde client terwijl het nooit reproduceerbaar is in een browser op hetzelfde netwerk.

Hoe u een monitoringdienst op de allowlist zet

Bevestig dat de blokkade identiteitsgebaseerd is. Herhaal het verzoek als een gewone HTTP-client en dan met een browser-user-agentstring, en vergelijk:
```
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
curl -sS -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://example.com/
```
Verschillen de codes, dan doet een user-agentregel het.
Vind de regel die afging. WAF- en CDN-dashboards loggen geblokkeerde verzoeken met het bijbehorende regel-ID. Dat is sneller en veiliger dan raden welke regel te versoepelen.
Zet op de allowlist per IP-adres waar u kunt. Monitoringproviders publiceren de adressen die hun meetpunten gebruiken. Ze toevoegen als skipregel is precies en verzwakt de bescherming voor niemand anders.
Of zet op de allowlist per user agent. Configureer de check om een onderscheidende user agent te sturen en voeg een regel toe die hem vrijstelt. Dat is makkelijker te onderhouden dan een IP-lijst, maar behandel het als gemak, niet als beveiligingsgrens, aangezien een user agent door iedereen gekopieerd kan worden.
Geef de voorkeur aan een skipregel boven bescherming uitschakelen. Stel het monitoringpad of de -client vrij van de specifieke regel, en laat de rest van de regelset van kracht.
Test opnieuw vanuit verscheidene regio's. Een regel kan ongelijk worden toegepast over edge-locaties, dus verifieer de oplossing vanaf meer dan één plek voordat u het ticket sluit.

Een 403 repareren die niet over bots gaat

Controleer of de URL überhaupt publiek zou moeten zijn. De helft van de 403-onderzoeken eindigt met het antwoord dat de blokkade correct is.
Verifieer bestandseigendom en -rechten op het pad en elke bovenliggende directory. Het serverproces heeft uitvoerrechten nodig op directories, niet alleen leesrechten op het bestand.
Zoek naar een indexbestand als de URL een directory is, of schakel bewust een listing in als er een gewenst is.
Lees de serverconfiguratie op deny-regels, IP-beperkingen en referrer-controles op dat pad, dan de autorisatielaag van de applicatie.
Controleer de edge voor de origin. Vraag de origin rechtstreeks op. Een 403 die verdwijnt wanneer u de CDN omzeilt, is een edge-regel, geen applicatieprobleem.

De blokkade zien van buiten uw eigen netwerk

Een 403 geïntroduceerd door een WAF-update of een wijziging in rechten ziet er van binnenuit niet uit als een storing: uw sessie is geauthenticeerd, uw adres staat op de allowlist, en de pagina's die u controleert zijn degene die werken. Een geplande HTTP-check toetst de code die u verwacht op de URL's die ertoe doen, van buiten uw netwerk, dus een nieuw verboden pagina geeft meteen een waarschuwing. Geoblokkades en edge-regels verschillen per regio, dus het aantal uitkijkpunten doet ertoe: HostTracker controleert vanaf 300+ meetpunten in 158 steden, wat "verboden in sommige landen" verandert in een zichtbaar verschil tussen locaties. Is de weigering tijdelijk en gebonden aan verzoekvolume in plaats van identiteit, dan is de code meestal 429 in plaats daarvan, behandeld in de handleiding 429 Too Many Requests, en de bredere familie staat in het 4xx-overzicht.