Risposte HTTP 403 vietate e 401 non autorizzate

Question

Per una pagina Web che esiste, ma per la quale un utente non dispone di privilegi sufficienti (non ha effettuato l'accesso o non appartiene al gruppo utenti appropriato), qual è la risposta HTTP corretta da servire?

401 Unauthorized?
403 Forbidden?
Qualcos'altro?

Quello che ho letto su ciascuno finora non è molto chiaro sulla differenza tra i due.Quali casi d'uso sono appropriati per ciascuna risposta?

Answer 1

Una spiegazione chiara da Daniele Irvine:

C'è un problema con 401 Non autorizzato, il codice di stato HTTP per gli errori di autenticazione.Ed è proprio questo:è per l'autenticazione, non per l'autorizzazione.Ricevere una risposta 401 è il server che ti dice: "Non lo sei autenticato: non autenticato affatto o autenticato in modo errato, ma esegui nuovamente l'autenticazione e riprova." Per aiutarti, includerà sempre un Autenticazione WWW che descrive come per l'autenticazione.

Si tratta di una risposta generalmente restituita dal server Web, non dal server Web applicazione.

È anche qualcosa di molto temporaneo;Il server ti chiede di riprovare.

Quindi, per l'autorizzazione utilizzo il file 403 Proibito risposta.E' permanente, è legato alla mia logica applicativa, ed è un risposta rispetto a un 401.

Ricevere una risposta 403 significa che il server ti dice: "Mi dispiace.Lo so chi sei, credo a chi dici di essere, ma non hai l'autorizzazione per accedere a questa risorsa.Forse se chiedi al sistema amministratore bene, otterrai il permesso.Ma per favore non preoccuparti finché la tua situazione non cambierà".

In sintesi, a 401 Non autorizzato risposta dovrebbe essere utilizzata per le o un'autenticazione errata, e un 403 Proibito dovrebbe essere utilizzata la risposta Successivamente, quando l'utente è autenticato ma non è autorizzato a Eseguire l'operazione richiesta sulla risorsa specificata.

Un altro bel formato pittorico su come dovrebbero essere utilizzati i codici di stato http.

Answer 2

Vedi RFC2616 :

401 non autorizzato:

.

Se la richiesta ha già incluso le credenziali di autorizzazione, quindi la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali.

403 Proibito:

.

Il server ha compreso la richiesta, ma si rifiuta di soddisfarlo.

Aggiornamento

Dal tuo caso di utilizzo, sembra che l'utente non sia autenticato.Ritornerei 401.

---

.

modifica: RFC2616 è obsoleto, vedere RFC7231 e RFC7235 .

Answer 3

Qualcosa Le altre risposte mancano è che deve essere compresa che l'autenticazione e l'autorizzazione nel contesto di RFC 2616 si riferisce solo al protocollo di autenticazione HTTP di RFC 2617. L'autenticazione da parte di schemi al di fuori di RFC2617 non è supportata nei codici di stato HTTP e non sono considerati quando si decidono se utilizzare 401 o 403.

Breve e Terse

Non autorizzato indica che il client non è autenticato RFC2617 e il server sta avviando il processo di autenticazione. Vietato indica che il client è autenticato da RFC2617 e non ha l'autorizzazione o che il server non supporti RFC2617 per la risorsa richiesta.

Significa che se hai il tuo processo di accesso a rotoli-your-proprio e non utilizzare mai l'autenticazione HTTP, 403 è sempre la risposta corretta e 401 non dovrebbe mai essere usato.

dettagliato e approfondito

da rfc2616

.

10.4.2 401 non autorizzato

La richiesta richiede l'autenticazione dell'utente. La risposta deve includere un campo di intestazione di autenticazione www (sezione 14.47) contenente una sfida applicabile alla risorsa richiesta. Il client può ripetere la richiesta con un campo di intestazione di autorizzazione adatto (sezione 14.8).

e

.

10.4.4 403 Proibito Il server ha compreso la richiesta ma si rifiuta di soddisfare. L'autorizzazione non aiuterà e la richiesta non deve essere ripetuta.

La prima cosa da tenere a mente è che la "Autenticazione" e "Autorizzazione" nel contesto di questo documento si riferiscono specificamente ai protocolli di autenticazione HTTP da RFC 2617. Non si riferiscono a alcun protocolli di autenticazione del rotolo-your Potrebbe aver creato utilizzando le pagine di accesso, ecc. Utilizzerò "Login" per fare riferimento all'autenticazione e all'autorizzazione per metodi diversi da RFC2617

Quindi la vera differenza non è ciò che il problema è o anche se c'è una soluzione. La differenza è ciò che il server si aspetta che il client faccia il prossimo.

401 Indica che la risorsa non può essere fornita, ma il server sta chiedendo che il client accedisca tramite l'autenticazione HTTP e ha inviato intestazioni di risposta per avviare il processo. Forse ci sono autorizzazioni che consentiranno l'accesso alla risorsa, forse non ci sono, ma diamo un tentativo di provare e vedere cosa succede.

403 Indica che la risorsa non può essere fornita e c'è, per l'utente corrente, nessun modo di risolverlo tramite RFC2617 e nessun punto nel tentativo. Questo potrebbe essere perché è noto che nessun livello di autenticazione è sufficiente (ad esempio a causa di una lista nera IP), ma potrebbe essere perché l'utente è già autenticato e non ha autorità. Il modello RFC2617 è un utente, una delle credenziali, quindi il caso in cui l'utente possa avere un secondo set di credenziali che potrebbe essere autorizzato può essere ignorato. Non suggerisce né implica che una sorta di pagina di accesso o altri protocollo di autenticazione non RFC2617 possono o non può aiutare - che sia al di fuori degli standard e della definizione RFC2616.

---

.

modifica: RFC2616 è obsoleto, vedere RFC7231 e RFC7235 .

Answer 4

  +-----------------------
  | RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
  +-----------------------
    |       |
 NO |       v YES
    v      +-----------------------
   404     | IS LOGGED-IN ? (authenticated, aka has session or JWT cookie)
   or      +-----------------------
   401        |              |
   403     NO |              | YES
   3xx        v              v
              401            +-----------------------
       (404 no reveal)       | CAN ACCESS RESOURCE ? (permission, authorized, ...)
              or             +-----------------------
             redirect          |            |
             to login       NO |            | YES
                               |            |
                               v            v
                               403          OK 200, redirect, ...
                      (or 404: no reveal)
                      (or 404: resource does not exist if private)
                      (or 3xx: redirection)

.

Gli assegni vengono solitamente eseguiti in questo ordine:

.
• 404 Se la risorsa è pubblica e non esiste o reindirizzamento 3xx
• altrimenti:
• 401 se non connesso o sessione scaduto
• 403 Se l'utente non ha il permesso di accedere alla risorsa (file, json, ...)
• 404 Se la risorsa non esiste o non disposta a rivelare nulla o 3xx reindirizzamento

non autorizzato : codice di stato (401) che indica che la richiesta richiede Autenticazione , di solito questo significa che l'utente deve essere loggato (sessione). Utente / agente sconosciuto dal server. Può ripetere con altre credenziali. Nota: questo è confuso in quanto ciò avrebbe dovuto essere nominato "non autenticato" invece di "non autorizzato". Questo può anche accadere dopo il login se la sessione è scaduta. Custodia speciale: può essere utilizzato al posto di 404 per evitare la presenza di rivelazione o la non presenza di risorse (crediti @gingercodeninja)

Proibito : Codice di stato (403) Indicare il server compreso la richiesta ma rifiutata di adempiere. Utente / agente noto dal server ma ha credenziali insufficienti . La ripetizione della richiesta non funzionerà, a meno che le credenziali non cambieranno, che è molto improbabile in un breve intervallo di tempo. Custodia speciale: può essere utilizzato al posto di 404 per evitare la presenza di rivelazione o la non presenza di risorse (crediti @gingercodeninja)

non trovato : codice di stato (404) che indica che la risorsa richiesta non è disponibile. Utente / Agente noto ma il server non rivelisce nulla sulla risorsa, fa come se non esistesse. La ripetizione non funzionerà. Questo è un uso speciale di 404 (GitHub lo fa per esempio).

Come menzionato da @Chrish ci sono alcune opzioni per Reindidirection 3xx (301, 302, 303, 307 o non reindirizzamento a tutti e utilizzare un 401):

.
• differenza tra i codici di reindirizzamento HTTP
• Quanto tempo fanno i browser cache http 301s? Qual è il corretto stato HTTP Codice quando si reindirizza in una pagina di accesso?
• Qual è la differenza tra un 302 e un 307 Reindirizzamento?

Answer 5

Secondo RFC 2616 (http / 1.1) 403 viene inviato quando:

.

Il server ha compreso la richiesta, ma si rifiuta di soddisfare.L'autorizzazione non aiuterà e la richiesta non dovrebbe essere ripetuta.Se il metodo di richiesta non è stato testa e il server desidera rendere pubblico perché la richiesta non è stata soddisfatta, dovrebbe descrivere il motivo del rifiuto nell'entità.Se il server non desidera rendere questa informazione disponibile per il client, il codice di stato 404 (non trovato) può essere utilizzato invece

In altre parole, se il client può accedere alla risorsa autenticando, deve essere inviato 401.

Answer 6

Supponendo l'autenticazione HTTP (Autenticazione WWW E Autorizzazione intestazioni) è in uso, se l'autenticazione come un altro utente concederebbe l'accesso alla risorsa richiesta, dovrebbe essere restituito 401 Unauthorized.

403 Forbidden viene utilizzato quando l'accesso alla risorsa è vietato a tutti o limitato a una determinata rete o consentito solo tramite SSL, purché non sia correlato all'autenticazione HTTP.

Se l'autenticazione HTTP non è in uso e il servizio utilizza uno schema di autenticazione basato su cookie come è la norma al giorno d'oggi, allora dovrebbe essere restituito un 403 o 404.

Per quanto riguarda 401, questo proviene da RFC 7235 (Hypertext Transfer Protocol (HTTP/1.1):Autenticazione):

3.1.401 Non autorizzato

Il codice di stato 401 (non autorizzato) indica che la richiesta è stata non è stato applicato perché non dispone di credenziali di autenticazione valide per la risorsa di destinazione.Il server di origine DEVE inviare un Campo di intestazione WWW-Authenticate (Sezione 4.4) contenente almeno un sfida applicabile alla risorsa di destinazione. Se la richiesta incluse le credenziali di autenticazione, quindi la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali.Il cliente PUÒ ripetere la richiesta con un nuovo o ha sostituito il campo di intestazione Autorizzazione (Sezione 4.1).Se il 401 la risposta contiene la stessa sfida della risposta precedente e la risposta l'agente utente ha già tentato l'autenticazione almeno una volta, quindi l'agente utente DOVREBBE presentare la rappresentazione allegata al utente, poiché di solito contiene informazioni diagnostiche rilevanti.

La semantica di 403 (e 404) è cambiata nel tempo.Questo è del 1999 (RFC 2616):

10.4.4 403 Proibito

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla.
L'autorizzazione non aiuterà e la richiesta NON DEVE essere ripetuta.
Se il metodo di richiesta non era HEAD e il server desidera effettuare
pubblico il motivo per cui la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità.Se il server non desidera mettere queste informazioni a disposizione del cliente, il codice di stato 404
È possibile utilizzare invece (Non trovato).

Nel 2014 RFC 7231 (protocollo di trasferimento ipertestuale (HTTP/1.1):Semantica e Contenuto) ha cambiato il significato di 403:

6.5.3.403 Proibito

Il codice di stato 403 (Accesso negato) indica che il server ha compreso la richiesta ma rifiuta di autorizzarla.Un server che desidera rendere pubblico il motivo per cui la richiesta è stata vietata può Descrivere tale motivo nel payload della risposta (se presente).

Se nella richiesta sono state fornite le credenziali di autenticazione, il file
il server li considera insufficienti per garantire l'accesso.Il cliente
NON DOVREBBE ripetere automaticamente la richiesta con la stessa
credenziali.Il cliente PUO' ripetere la richiesta con nuove o diverse credenziali.Tuttavia, una richiesta potrebbe essere vietata per motivi
estraneo alle credenziali.

Un server di origine che desidera "nascondere" l'attuale esistenza di a
la risorsa target proibita PUÒ invece rispondere con un codice di stato di
404 non trovato).

Pertanto, un 403 (o un 404) ora potrebbe significare qualsiasi cosa.Fornire nuove credenziali potrebbe aiutare...o potrebbe non esserlo.

Credo che il motivo per cui questo è cambiato è che RFC 2616 presuppone che l'autenticazione HTTP venga utilizzata quando in pratica le app Web di oggi creano schemi di autenticazione personalizzati utilizzando ad esempio moduli e cookie.

Answer 7

.
• 401 non autorizzato : Non so chi sei. Questo errore di autenticazione.
• 403 Proibita : So chi sei, ma non hai il permesso di accedere a questa risorsa. Questo è un errore di autorizzazione.

Answer 8

Questa è una domanda più antica, ma un'opzione che non è mai stata realmente allevata era quella di restituire un 404. Da una prospettiva di sicurezza, la risposta votata più alta soffre di un potenziale vulnerabilità di perdite di informazioni .Dì, ad esempio, che la pagina Web sicura in questione è una pagina di amministrazione di sistema, o forse più comunemente, è un record in un sistema a cui l'utente non ha accesso.Idealmente non vorresti che un utente malizioso sappia nemmeno che c'è una pagina / record lì, per non parlare di non avere accesso.Quando sto costruendo qualcosa del genere, proverò a registrare richieste non autenticate / non autorizzate in un registro interno, ma restituire un 404.

OWASP ha alcuni Ulteriori informazioni su come un attaccante possa usare questo tipodi informazioni come parte di un attacco.

Answer 9

Questa domanda è stata posta qualche tempo fa, ma il pensiero delle persone si muove.

Sezione 6.5.3 In questa bozza (autored da Fielding and Reschke) dà il codice di stato 403 un significato leggermente diverso a quello documentato in RFC 2616 .

Riflette ciò che accade in regimi di autenticazione e autorizzazione impiegati da un certo numero di web-server e framework.

Ho sottolineato il bit che penso sia più saliente.

.

6.5.3. 403 Forbidden

Il codice di stato 403 (proibito) indica che il server ha compreso la richiesta, ma si rifiuta di autorizzarlo. Un server che desidera rendere il pubblico perché la richiesta è stata vietata può descrivere quella ragione nel carico utile della risposta (se presente).

Se le credenziali di autenticazione sono state fornite nella richiesta, il server li considera insufficiente per concedere l'accesso. Il client non dovrebbe ripetere la richiesta con le stesse credenziali. Il client può ripetere la richiesta con credenziali nuove o diverse. Tuttavia, una richiesta potrebbe essere vietata per ragioni non correlate alle credenziali.

Un server di origine che desidera "nascondere" l'esistenza corrente di una risorsa di destinazione proibita potrebbe invece rispondere con un codice di stato di 404 (non trovato).

Qualunque sia la convenzione che usi, l'importante è fornire uniformità sul tuo sito / API.

Answer 10

TL; DR

.
• 401: un rifiuto che ha a che fare con l'autenticazione
• 403: un rifiuto che non ha nulla a che fare con l'autenticazione

Esempi pratici

Se Apache richiede l'autenticazione (tramite .htaccess), e hai colpito Cancel, risponderà con un 401 Authorization Required

Se nginx trova un file, ma non ha diritti di accesso (utente / gruppo) per leggere / accedere, risponderà con 403 Forbidden

RFC (2616 Sezione 10)

401 non autorizzato (10.4.2)

Significato 1: Devi autenticare

.

La richiesta richiede l'autenticazione dell'utente. ...

Significato 2: Autenticazione insufficiente

.

... Se la richiesta ha già incluso le credenziali di autorizzazione, la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali. ...

403 Forbidden (10.4.4)

Significato: Non correlato all'autenticazione

.

... Autorizzazione non aiuterà ...

maggiori dettagli:

.

• Il server ha compreso la richiesta, ma si rifiuta di soddisfarlo.

• Dovrebbe descrivere il motivo del rifiuto nell'entità

• Il codice di stato 404 (non trovato) può essere utilizzato invece

  (se il server vuole mantenere queste informazioni dal client)

Answer 11

non hanno effettuato l'accesso o non appartengono al gruppo utenti corretto

Hai affermato due casi diversi;ogni caso dovrebbe avere una risposta diversa:

1. Se non hanno effettuato l'accesso, dovresti tornare 401 Non autorizzato
2. Se hanno effettuato l'accesso ma non appartengono al gruppo utenti corretto, dovresti tornare 403 Proibito

Nota sulla RFC basata sui commenti ricevuti a questa risposta:

Se l'utente non ha effettuato l'accesso non è autenticato, il cui equivalente HTTP è 401 ed è ingannevolmente chiamato Non autorizzato nella RFC.COME sezione 10.4.2 stati per 401 Non autorizzato:

"La richiesta richiede user autenticazione."

Se non sei autenticato, 401 è la risposta corretta.Tuttavia, se non sei autorizzato, nel senso semanticamente corretto, 403 è la risposta corretta.

Answer 12

in inglese:

401

.

Sei potenzialmente consentito l'accesso ma per qualche motivo su questa richiesta eri negato.Come una brutta password?Riprova, con la richiesta corretta Otterrai invece una risposta di successo.

403

.

Non sei, mai permesso.Il tuo nome non è nella lista, non lo farai mai entrato, vai via, non inviare una richiesta di ricompensa, verrà rifiutato, sempre.Andare via.

Answer 13

Questi sono i significati:

401 : utente non (correttamente) autenticato, la risorsa / pagina richiede l'autenticazione

403 : L'utente autenticato, ma il suo ruolo o autorizzazioni non consentono di accedere alla risorsa richiesta, ad esempio l'utente non è un amministratore e una pagina richiesta è per gli amministratori

Answer 14

Questo è più semplice nella mia testa che da qualsiasi parte qui, quindi:

401: Hai bisogno di HTTP BASIC AUTH per vederlo.

403: Non puoi vederlo, e l'AUTH di base HTTP non ti aiuterà.

Se l'utente ha solo bisogno di accedere utilizzando il modulo di accesso HTML standard del sito, 401 non sarebbe appropriato perché è specifico per AUTH di base HTTP.

Non consiglio di usare 403 per negare l'accesso a cose come /includes, perché per quanto riguarda il Web, tali risorse non esistono affatto e dovrebbero quindi 404.

Questo lascia 403 come "Devi essere registrato".

In altre parole, 403 significa "questa risorsa richiede una qualche forma di autenticazione diversa da Autenzione di base HTTP".

https://www.w3.org/protocolli/rfc2616/RFC2616-sec10.html#sec10.4.2

Answer 15

Penso che sia importante considerare che, per un browser, 401 avvia una finestra di dialogo di autenticazione affinché l'utente possa inserire nuove credenziali, mentre 403 no.I browser pensano che, se viene restituito un 401, l'utente dovrebbe autenticarsi nuovamente.Quindi 401 sta per autenticazione non valida mentre 403 sta per mancanza di autorizzazione.

Ecco alcuni casi secondo questa logica in cui verrebbe restituito un errore dall'autenticazione o dall'autorizzazione, con frasi importanti in grassetto.

• Una risorsa richiede l'autenticazione ma nessuna credenziale erano specificato.

401:Il client deve specificare le credenziali.

• Le credenziali specificate sono in un file formato non valido.

400:Non è né 401 né 403, poiché gli errori di sintassi dovrebbero sempre restituire 400.

• Le credenziali specificate fanno riferimento a utente Quale non esiste.

401:Il client deve specificare credenziali valide.

• Quello specificato credenziali Sono non valido ma specifica un utente valido (o non specificare un utente se un utente specificato non è richiesto).

401:Anche in questo caso, il client deve specificare credenziali valide.

• Quello specificato credenziali Avere scaduto.

401:Questo equivale praticamente ad avere credenziali non valide in generale, quindi il client deve specificare credenziali valide.

• Le credenziali specificate sono completamente valide ma non lo sono basta il particolare risorsa, anche se è possibile che credenziali con maggiori autorizzazioni possano farlo.

403:Specificare credenziali valide non concederebbe l'accesso alla risorsa, poiché le credenziali correnti sono già valide ma non dispongono solo dell'autorizzazione.

• Il particolare risorsa È inaccessibile indipendentemente dalle credenziali.

403:Ciò avviene indipendentemente dalle credenziali, quindi specificare credenziali valide non può essere d'aiuto.

• Le credenziali specificate sono completamente valide ma particolari cliente È bloccato dal loro utilizzo.

403:Se il client è bloccato, specificare nuove credenziali non farà nulla.

Answer 16

Given the latest RFC's on the matter (7231 and 7235) the use-case seems quite clear (italics added):

• 401 is for unauthenticated ("lacks valid authentication"); i.e. 'I don't know who you are, or I don't trust you are who you say you are.'

401 Unauthorized

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.

• 403 is for unauthorized ("refuses to authorize"); i.e. 'I know who you are, but you don't have permission to access this resource.'

403 Forbidden

The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

Answer 17

In the case of 401 vs 403, this has been answered many times. This is essentially a 'HTTP request environment' debate, not an 'application' debate.

There seems to be a question on the roll-your-own-login issue (application).

In this case, simply not being logged in is not sufficient to send a 401 or a 403, unless you use HTTP Auth vs a login page (not tied to setting HTTP Auth). It sounds like you may be looking for a "201 Created", with a roll-your-own-login screen present (instead of the requested resource) for the application-level access to a file. This says:

"I heard you, it's here, but try this instead (you are not allowed to see it)"