En 403 Forbidden-feil betyr at serveren tok imot forespørselen, forsto den og nektet å svare på den. I motsetning til en 401 hjelper det ikke nødvendigvis å logge inn: serveren sier at denne klienten, fra denne adressen, med disse tillatelsene, ikke får tilgang til denne ressursen. Årsaken er nesten alltid en regel, ikke et krasj: filtillatelser, en manglende indeksfil, en deny-regel i serverkonfigurasjonen, en brannmur eller bot-beskyttelse, en IP- eller landblokkering, eller en konto uten riktig rolle. Nettstedseiere finner regelen i feilloggen eller i brannmurens hendelseslogg; besøkende kan stort sett bare endre det de selv sender.
403 vs. 401 vs. 404
KodeHva serveren sierHva som hjelper401 UnauthorizedHvem er du? Send påloggingsinformasjon.Å logge inn, eller en gyldig API-nøkkel eller token403 ForbiddenJeg vet hva du vil ha, og du får det ikke.Andre tillatelser, en annen adresse eller en annen forespørsel404 Not FoundDet finnes ingenting her.Riktig adresse
Servere følger ikke alltid læreboka. Noen svarer 404 i stedet for 403 for å skjule at en privat side finnes, og noen svarer 403 for filer som mangler: en privat lagringsbøtte kan for eksempel svare 403 for et objekt som ikke finnes, når klienten ikke har lov til å liste innholdet i bøtta. Oversikten over HTTP-statuskoder har resten.
Vanlige årsaker
Fil- og mappetillatelser. Webserverens bruker kan ikke lese filen eller åpne mappen, ofte etter en opplasting eller en deploy som kopierte filene som en annen bruker.
Ingen indeksfil. En forespørsel etter en mappe uten index.html eller index.php, på en server der mappelisting er slått av, gir 403. En mislykket deploy som etterlot mappen tom, gjør det samme.
Deny-regler. En deny all i nginx, en Require all denied i Apache eller en regel i .htaccess som blokkerer en sti, en filtype eller en user agent.
En brannmur eller bot-beskyttelse. En WAF, et CDNs bot-beskyttelse eller en sikkerhetsutvidelse vurderer forespørselen som automatisert eller ondsinnet og blokkerer den, noen ganger med en utfordringsside.
IP- og landblokkeringer. Den besøkendes adresse, nettverk eller land står på en blokkeringsliste, eller siden er begrenset til et kontornettverk eller en VPN.
Manglende rettigheter. Den besøkende er logget inn, men rollen gir ikke tilgang til siden, eller en API-nøkkel mangler tilgangen (scope) som endepunktet krever.
Utløpte eller feil signerte lenker. Nedlastingslenker med signatur eller utløpstid svarer 403 når de har gått ut.
Hotlink-beskyttelse. Bilder eller filer som hentes fra et annet nettsted, eller uten forventet Referer, blir avvist.
Hva besøkende kan prøve
Sjekk adressen. En lenke som ender i en mappe i stedet for en side, eller en feilskrevet sti, kan treffe en mappe serveren ikke vil liste.
Logg inn, eller logg inn med riktig konto. Noen nettsteder viser 403 til besøkende som ikke er innlogget, eller til kontoer uten tilgang.
Slett nettstedets informasjonskapsler og last inn siden på nytt. En gammel økt eller en utdatert utfordringscookie kan gjøre at en brannmur fortsetter å avvise deg.
Bytt nettverk. Slå VPN eller proxy av, eller på, eller prøv mobildata. Delte adresser og adresser fra datasentre blokkeres oftere enn hjemmetilkoblinger.
Slå av utvidelser for nettstedet. Noen personvernutvidelser endrer headere på måter som utløser en brannmur.
Si fra til nettstedseieren, med tidspunktet og eventuelt referansenummer som feilsiden viser. Med det nummeret kan de finne nøyaktig hvilken regel det gjelder.
Slik finner og fikser nettstedseiere feilen
Finn først ut hvem som svarte. Se på feilsiden og svarheaderne: et CDN eller en brannmur oppgir som regel seg selv, med en side i egen stil, en Server-header eller en forespørsels-ID. Er det din egen webserver, står årsaken i feilloggen dens. Er det CDN-et eller WAF-en, står den i hendelsesloggen der.
Tillatelser og indeksfiler
På Linux-servere trenger mapper vanligvis 755 og filer 644, eid av brukeren som webserveren eller PHP kjører som. Sjekk før du endrer noe, og løs aldri en 403 med 777, som lar alle brukere på serveren skrive til nettstedet ditt:
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 mangler indeksfil; Apache logger at den ikke finner noen indeks og at mappelisting er slått av. Sjekk at deployen la filene der serverens document root peker.
Serverregler
nginx logger «access forbidden by rule» for en deny, og Apache logger «client denied by server configuration» for en Require-regel. Søk i konfigurasjonen og i hver .htaccess langs stien etter regelen som slår til. I WordPress skriver lagring av permalenkeinnstillingene om kjernedelen av .htaccess, og sikkerhetsutvidelser legger inn egne blokkeringer både der og i sine egne innstillinger.
Brannmurer, CDN-er og sikkerhetsutvidelser
Finn den blokkerte forespørselen i hendelsesloggen ut fra tidspunkt, adresse eller forespørsels-ID, se hvilken regel som slo til, og avgjør om regelen er feil eller om forespørselen faktisk var uønsket. Legg inn unntak for bestemte adresser eller stier i stedet for å slå av en regel for hele nettstedet. Etter en endring i brannmuren bør du teste fra et nettverk utenfor kontoret, siden din egen adresse kan stå på tillatelseslisten.
Hvorfor en monitor får 403 når nettleseren din ikke gjør det
Et vanlig tilfelle: nettstedet fungerer for deg, men oppetidsmonitoren din rapporterer 403. Som regel er ingenting ødelagt. Noe foran nettstedet behandler sjekken som en bot, fordi den er en:
Bot-beskyttelse. CDN-er og WAF-er utfordrer klienter som ikke kjører JavaScript eller ser automatiserte ut. En nettleser løser utfordringen; det klarer ikke en monitor, så den får en 403 eller en utfordringsside.
Adresser fra datasentre. Monitorer sjekker fra servere, og noen regler blokkerer hostingnettverk som standard.
Landblokkeringer. Et nettsted som bare slipper inn besøkende fra eget land, blokkerer en monitor som sjekker fra utlandet.
Rate-regler. Noen brannmurer svarer 403 i stedet for 429 når en klient sender for mange forespørsler.
Løsningen er å legge monitoren på tillatelseslisten, helst etter IP-adressene, siden hvem som helst kan kopiere en user agent. Ikke løs det ved å godta 403 som «oppe» for hele nettstedet: da går en reell blokkering av de besøkende dine ubemerket hen. Hvis en side virkelig må ligge bak beskyttelsen, kan du overvåke et health check-endepunkt utenfor den. Guiden om å redusere falske varsler tar for seg andre årsaker til varsler som ikke er nedetid.
403-feil og Uptimecheck
En HTTP(S)-monitor i Uptimechecks oppetidsovervåking regner som standard statuser fra 200 til 399 som oppe, så en 403 regnes som nede. En ny sjekk bekrefter det før du blir varslet, og hendelsen forklarer hva som svarte: når 403-svaret eller en utfordringsside kommer fra Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence eller AWS WAF, oppgir den tjenesten og hva du må tillate der. Nettstedssjekker kommer fra Stockholm i Sverige, med en user agent som inneholder «Uptimecheck». Slik slipper du Uptimecheck gjennom en brannmur viser adressene våre med ferdige regler for Cloudflare, sikkerhetsutvidelser for WordPress og nginx, og hvorfor en monitor kan være nede når nettstedet fungerer tar for seg de andre årsakene.
Vil du vite om et nettsted svarer i det hele tatt? Den gratis Is it down?-sjekkeren regner alle svar under 500, også en 403, som oppe: serveren svarte, selv om den sa nei.
Skill en blokkert sjekk fra ekte nedetid. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.