403 Forbidden: cause, soluzioni e blocchi bot che ingannano i monitor

403 contro 401

RFC 9110 traccia il confine chiaramente. Un 401 Unauthorized significa che è richiesta l'autenticazione o che le credenziali fornite non sono state accettate, e la risposta deve portare un header WWW-Authenticate che descrive come autenticarsi. Un 403 Forbidden significa che il server rifiuta di autorizzare la richiesta, e riautenticarsi non aiuterà.

La specifica permette anche a un server di rispondere 404 invece di 403 quando non vuole rivelare che una risorsa esiste affatto. Ecco perché un URL che sai essere presente può tornare "non trovato" da un server rafforzato. Se stai facendo il triage di un 403, ricorda che esiste anche il caso inverso.

Cosa produce un 403

• Permessi del filesystem. Il processo del web server non può leggere il file o attraversare la directory. Un classico dopo una copia manuale di file o un ripristino che ha cambiato la proprietà.
• Elenco directory disattivato. Una richiesta per una cartella senza file indice restituisce 403 su server configurati per rifiutare gli elenchi. Comportamento corretto, errore che confonde.
• Regole di autorizzazione dell'applicazione. L'utente ha effettuato l'accesso ma manca del ruolo, del piano o dell'appartenenza al tenant richiesti per quella risorsa.
• Liste di consenso e diniego IP. Un percorso di amministrazione ristretto agli indirizzi dell'ufficio restituisce 403 a chiunque altro, incluso chi testa da casa o da una rete mobile.
• Regole del web application firewall. Un WAF blocca una richiesta il cui URL, header o corpo corrisponde a una firma. Spesso la richiesta ti sembra del tutto innocente.
• Geo-blocking. Il traffico da alcuni paesi o regioni viene rifiutato all'edge, quindi il sito va bene da un continente e proibito da un altro.
• Protezione hotlink. Una regola che rifiuta richieste di immagini o media il cui header Referer è assente o punta a un altro dominio. Le richieste senza referrer vengono spesso intercettate per errore.
• Filtraggio bot e user agent. La richiesta viene bloccata a causa di chi il client dichiara di essere, non di cosa ha chiesto. Questo è il caso che colpisce il monitoraggio.

Il caso "403 per i monitor, 200 per gli umani"

Questo è il falso allarme più comune nel monitoraggio dell'uptime, e non è un bug di monitoraggio. Il sito sta davvero restituendo 403, solo non ai browser.

La gestione dei bot presso una CDN o un WAF valuta ogni richiesta in base allo user agent, all'impronta TLS, all'ordinamento degli header, alla reputazione dell'IP e a se risolve una sfida JavaScript o interattiva. Un controllo HTTP automatizzato è, per progettazione, un client automatizzato: non esegue sfide JavaScript e si identifica onestamente. Quindi viene sfidato o bloccato mentre il tuo browser passa senza problemi, e il risultato è un sito che avvisa come giù mentre ogni umano conferma che è su.

Due segni lo identificano rapidamente: il 403 arriva istantaneamente invece che dopo un ritardo, il che esclude il sovraccarico, ed è costante per il client automatizzato pur non essendo mai riproducibile in un browser sulla stessa rete.

Come mettere in allowlist un servizio di monitoraggio

1. Conferma che il blocco sia basato sull'identità. Ripeti la richiesta come un client HTTP semplice e poi con una stringa user agent da browser, e confronta:

   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/

   Se i codici differiscono, è una regola sullo user agent a farlo.
2. Trova la regola che è scattata. Le dashboard di WAF e CDN registrano le richieste bloccate con l'id della regola corrispondente. È più veloce e sicuro che indovinare quale regola allentare.
3. Metti in allowlist per indirizzo IP dove puoi. I provider di monitoraggio pubblicano gli indirizzi usati dalle loro postazioni. Aggiungerli come regola di esclusione è preciso e non indebolisce la protezione per nessun altro.
4. Oppure metti in allowlist per user agent. Configura il controllo per inviare uno user agent distintivo e aggiungi una regola che lo esenta. È più facile da mantenere di un elenco di IP, ma trattalo come una comodità piuttosto che un confine di sicurezza, dato che uno user agent può essere copiato da chiunque.
5. Preferisci una regola di esclusione alla disattivazione della protezione. Esenta il percorso o il client di monitoraggio dalla regola specifica, e lascia in vigore il resto del set di regole.
6. Ritesta da più regioni. Una regola può essere applicata in modo non uniforme tra le postazioni edge, quindi verifica la correzione da più di un posto prima di chiudere il ticket.

Correggere un 403 che non riguarda i bot

1. Controlla se l'URL dovrebbe essere pubblico affatto. Metà delle indagini su un 403 finisce con la risposta che il blocco è corretto.
2. Verifica proprietà e permessi dei file sul percorso e su ogni directory superiore. Il processo del server ha bisogno del permesso di esecuzione sulle directory, non solo del permesso di lettura sul file.
3. Cerca un file indice se l'URL è una directory, oppure abilita un elenco deliberatamente se ne vuoi uno.
4. Leggi la configurazione del server per regole di diniego, restrizioni IP e controlli sul referrer per quel percorso, poi il livello di autorizzazione dell'applicazione.
5. Controlla l'edge prima dell'origine. Richiedi direttamente l'origine. Un 403 che scompare quando bypassi la CDN è una regola dell'edge, non un problema dell'applicazione.

Vedere il blocco dall'esterno della tua rete

Un 403 introdotto da un aggiornamento del WAF o un cambio di permessi non sembra un'interruzione dall'interno: la tua sessione è autenticata, il tuo indirizzo è in allowlist, e le pagine che controlli sono quelle che funzionano. Un controllo HTTP pianificato asserisce il codice che ti aspetti sugli URL che contano, dall'esterno della tua rete, così una pagina appena diventata proibita fa scattare un avviso immediatamente. I geo-blocchi e le regole edge variano per regione, quindi il numero di punti di osservazione conta: HostTracker controlla da oltre 300 postazioni in 158 città, il che trasforma "proibito in alcuni paesi" in una differenza visibile tra postazioni. Se il rifiuto è temporaneo e legato al volume delle richieste invece che all'identità, il codice sarà di solito 429 invece, trattato nella guida 429 Too Many Requests, e la famiglia più ampia è nella panoramica 4xx.