Se l'utente autenticato tenta di accedere a una risorsa limitata

È possibile enumerare le risorse attraverso distinzioni come queste: se si restituisce un 403 per le pagine esistenti, ma l'utente corrente non può accedere e 404 per le pagine che non esistono, un utente malintenzionato può facilmente distinguere tra risorse valide e non valide.

Se ciò che conta dipende dalla tua applicazione - se rivelassi informazioni in questa circostanza che ha valore, potrebbe essere una cosa negativa: se /user/73463 mi dà un 404 ma /user/64500 mi dà un 403, posso fare un supposizione istruita che 64500 sia un utente valido di cui non riesco a vedere il profilo. D'altra parte, se /year/2003 a /year/2016 mi dà un 403 ma /year/2002 e /year/2020 mi danno un 404, tutto quello che posso dire è che non hai creato cartelle annuali nel lontano futuro, e forse che non hai nulla da prima del 2003.

Idealmente, non vuoi fornire URL a cui l'utente non ha accesso ( dalla tua domanda, non sono sicuro che l'URL che segui sia sul tuo sito o altrove ). Tuttavia, è possibile controllarlo solo all'interno del proprio sistema: se l'utente B invia all'utente A un collegamento, l'utente A può scoprire che la risorsa esiste senza preoccuparsi della risposta a loro. Ciò si applica se un link viene fornito anche su un sito Web di terze parti - nessuno è in grado di collegarsi a una risorsa inesistente (sebbene potrebbero essere collegati a una risorsa che non esiste più, nel qual caso un 404 o 410 sarebbe adeguata). Per i tuoi sistemi, dovresti mirare a ridurre al minimo le possibilità che un utente legittimo possa seguire un link a una risorsa a cui non hanno il permesso di accedere.

Generalmente, se qualcosa può essere facilmente enumerato (ad es. identificatore numerico) ha più senso restituire una risposta coerente a tutte le richieste, indipendentemente dal fatto che allo stato attuale manchi l'autorizzazione o che la risorsa non sia esistente. Se qualcosa non può essere enumerato (ad esempio un identificatore di hash lungo), potrebbe avere senso distinguere tra gli stati, ma è necessario essere consapevoli del potenziale per qualcuno di imbattersi in risorse che non dovrebbero essere in grado di rilevare e di adottare misure per evitare ciò (ad es. monitorare alte frequenze di richiesta e limitare i tentativi apparenti di enumerare le risorse).

Non rovinare la vita dei tuoi utenti. Se hanno commesso un errore reale o hanno ricevuto un link da un altro utente autorizzato ad accedere alla pagina, è utile che sappiano che non dispongono di autorizzazioni sufficienti. Ci saranno casi in cui hanno una richiesta legittima di accedere alle informazioni e saranno quindi in grado di chiedere aiuto a un altro utente autorizzato o di rivolgersi ai processi di autorizzazione esistenti nel sistema. Se dici che una risorsa non esiste, invece, stai solo aggiungendo al loro carico cognitivo e rendendo più difficile per loro risolvere la situazione e portare a termine il loro lavoro.

Conclusione dal punto di vista dell'usabilità: spiega sempre chiaramente perché l'accesso è negato.

Ora, nel caso di un sito Web pubblico con spazi e ruoli autenticati, alcuni sostengono che far conoscere alle persone le risorse non autorizzate consente agli utenti malintenzionati di enumerare le risorse. In primo luogo, se sono adeguatamente protetti, questo non è sempre un problema (dipende ovviamente dal contesto della tua applicazione). In secondo luogo, è possibile accedere agli accessi negati alle risorse protette e individuare / escludere gli utenti che eseguono l'enumerazione (soprattutto se c'è un costo notevole per l'impostazione dell'account). In terzo luogo, se sei veramente preoccupato, puoi anche passare attraverso il processo inverso di mostrare i messaggi di errore appropriati agli utenti di cui ti fidi e lasciare quelli non affidabili al buio (utile se hai entrambe le risorse sensibili URL che non devono essere enumerati + registrazione gratuita al tuo sistema).

In ogni caso, non vi sono sostanziali vantaggi in termini di sicurezza o motivi remotamente validi per complicare la vita dei tuoi utenti con messaggi di errore criptici.

PS: ci sono uno o due articoli di ricerca che propongono l'idea che i sistemi di sicurezza non dovrebbero mai fornire feedback; senza alcuna prova che i benefici superano il costo. Se qualcuno è in vena di discutere, sono felice di prenderne uno e di ridimensionarlo per te. La formazione di base nella progettazione dell'interazione o nella ricerca dell'usabilità sarà sufficiente a spiegare perché è necessario fornire agli utenti preziosi messaggi di errore: il costo dell'usabilità di non fornire feedback è molto reale e nessuno nel campo della ricerca dell'usabilità ne discuterà.