En 403 Forbidden-fejl betyder, at serveren modtog requesten, forstod den og nægtede at besvare den. I modsætning til en 401 hjælper det ikke nødvendigvis at logge ind: serveren siger, at netop denne klient, fra denne adresse, med disse rettigheder, ikke må få denne ressource. Årsagen er næsten altid en regel, ikke et nedbrud: filrettigheder, en manglende indeksfil, en deny-regel i serverkonfigurationen, en firewall eller bot-beskyttelse, en IP- eller landeblokering eller en konto uden den rette rolle. Ejere af sites finder reglen i fejlloggen eller i firewallens hændelseslog; besøgende kan for det meste kun ændre det, de selv sender.
403 vs. 401 vs. 404
KodeHvad serveren sigerHvad der hjælper401 UnauthorizedHvem er du? Send loginoplysninger.At logge ind eller en gyldig API-nøgle eller token403 ForbiddenJeg ved, hvad du vil have, og det får du ikke.Andre rettigheder, en anden adresse eller en anden request404 Not FoundHer er ingenting.Den rigtige adresse
Servere følger ikke altid lærebogen. Nogle svarer 404 i stedet for 403 for at skjule, at en privat side findes, og nogle svarer 403 for filer, der mangler: en privat storage-bucket kan fx svare 403 for et objekt, der ikke findes, når klienten ikke har lov til at liste bucketens indhold. Resten finder du i oversigten over HTTP-statuskoder.
Typiske årsager
Fil- og mapperettigheder. Webserverens bruger kan ikke læse filen eller åbne mappen, ofte efter en upload eller et deploy, der kopierede filerne som en anden bruger.
Ingen indeksfil. En request til en mappe uden index.html eller index.php på en server, hvor mappevisning er slået fra, svarer 403. Et mislykket deploy, der efterlod mappen tom, gør det samme.
Deny-regler. En deny all i nginx, en Require all denied i Apache eller en regel i .htaccess, der blokerer en sti, en filtype eller en user agent.
En firewall eller bot-beskyttelse. En WAF, et CDN’s bot-beskyttelse eller et sikkerhedsplugin vurderer, at requesten ser automatiseret eller ondsindet ud, og blokerer den, nogle gange med en challenge-side.
IP- og landeblokeringer. Den besøgendes adresse, netværk eller land står på en blokeringsliste, eller siden er begrænset til et kontornetværk eller en VPN.
Manglende rettigheder. Den besøgende er logget ind, men rollen giver ikke adgang til siden, eller en API-nøgle mangler scope til endpointet.
Udløbne eller forkerte signerede links. Downloadlinks med en signatur eller en udløbstid svarer 403, når de er udløbet.
Hotlink-beskyttelse. Billeder eller filer, der hentes fra et andet site eller uden den forventede Referer, afvises.
Hvad besøgende kan prøve
Tjek adressen. Et link, der ender i en mappe i stedet for en side, eller en forkert stavet sti kan ramme en mappe, serveren ikke vil vise.
Log ind, eller log ind med den rigtige konto. Nogle sites viser 403 til besøgende, der ikke er logget ind, eller til konti uden adgang.
Ryd sitets cookies, og genindlæs. En gammel session eller en forældet challenge-cookie kan få en firewall til at blive ved med at afvise dig.
Skift netværk. Slå en VPN eller proxy fra, eller til, eller prøv mobildata. Delte adresser og datacenteradresser bliver oftere blokeret end hjemmeforbindelser.
Slå udvidelser fra for sitet. Nogle privatlivsudvidelser ændrer headers på måder, der udløser en firewall.
Kontakt ejeren af sitet, med tidspunktet og et eventuelt referencenummer fra fejlsiden. Det nummer gør det muligt for dem at finde den præcise regel.
Sådan finder og løser ejere af sites fejlen
Find først ud af, hvem der svarede. Se på fejlsiden og response-headerne: et CDN eller en firewall giver sig som regel til kende med en side i sit eget design, en Server-header eller et request-ID. Er det din webserver, står årsagen i dens fejllog. Er det CDN’et eller WAF’en, står den i dens hændelseslog.
Rettigheder og indeksfiler
På Linux-servere skal mapper som regel have 755 og filer 644, ejet af den bruger, webserveren eller PHP kører som. Tjek, før du ændrer noget, og løs aldrig en 403 med 777, som lader alle brugere på serveren skrive til dit site:
ls -la /var/www/example.com/public
find /var/www/example.com/public -type d -exec chmod 755 {} +
find /var/www/example.com/public -type f -exec chmod 644 {} +
nginx logger “directory index of … is forbidden”, når en mappe ikke har nogen indeksfil; Apache logger, at den ikke kan finde et indeks, og at mappevisning er slået fra. Tjek, at dit deploy har lagt filerne der, hvor serverens document root peger hen.
Serverregler
nginx logger “access forbidden by rule” for en deny, og Apache logger “client denied by server configuration” for en Require-regel. Søg i konfigurationen og i hver .htaccess på stien efter den matchende regel. I WordPress omskriver det kernedelen af .htaccess, når du gemmer permalink-indstillingerne, og sikkerhedsplugins tilføjer deres egne blokeringer dér og i deres indstillinger.
Firewalls, CDN’er og sikkerhedsplugins
Find den blokerede request i hændelsesloggen ud fra tidspunkt, adresse eller request-ID, se hvilken regel der matchede, og afgør, om reglen er forkert, eller om requesten faktisk var uønsket. Tilføj undtagelser for bestemte adresser eller stier i stedet for at slå en regel fra for hele sitet. Test efter en ændring i firewallen fra et netværk uden for kontoret, da din egen adresse måske står på en allowlist.
Hvorfor en monitor får 403, når din browser ikke gør
Et typisk tilfælde: sitet virker for dig, men din oppetidsmonitor rapporterer 403. Som regel er intet gået i stykker. Noget foran sitet behandler tjekket som en bot, for det er det:
Bot-beskyttelse. CDN’er og WAF’er udfordrer klienter, der ikke kører JavaScript eller ser automatiserede ud. En browser klarer udfordringen; det kan en monitor ikke, så den får en 403 eller en challenge-side.
Datacenteradresser. Monitorer tjekker fra servere, og nogle regler blokerer hostingnetværk som standard.
Landeblokeringer. Et site, der kun tillader sit hjemland, blokerer en monitor, der tjekker fra udlandet.
Rate-regler. Nogle firewalls svarer 403 i stedet for 429, når en klient sender for mange requests.
Løsningen er at sætte monitoren på allowlisten, helst ud fra dens IP-adresser, da alle kan kopiere en user agent. Løs det ikke ved at acceptere 403 som “oppe” for hele sitet: så går en reel blokering af dine besøgende ubemærket hen. Hvis en side virkelig skal blive bag beskyttelsen, så overvåg et health check-endpoint uden for den. Guiden til at reducere falske alarmer dækker andre årsager til alarmer, der ikke er nedbrud.
403-fejl og Uptimecheck
En HTTP(S)-monitor i Uptimechecks oppetidsovervågning tæller som standard statusser fra 200 til 399 som oppe, så en 403 tæller som nede. Et ekstra tjek bekræfter det, før du får en alarm, og hændelsen forklarer, hvad der svarede: når 403’en eller en challenge-side kommer fra Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence eller AWS WAF, nævner den tjenesten og hvad du skal tillade dér. Tjek af websites kommer fra Stockholm i Sverige med en user agent, der indeholder “Uptimecheck”. Sådan tillader du Uptimecheck gennem en firewall viser vores adresser med færdige regler til Cloudflare, sikkerhedsplugins til WordPress og nginx, og hvorfor en monitor kan være nede, når sitet virker dækker de andre årsager.
Vil du vide, om et site overhovedet svarer? Den gratis Is it down?-tjekker tæller ethvert svar under 500, også en 403, som oppe: serveren svarede, selv om den afviste.
Skeln et blokeret tjek fra et reelt nedbrud. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.