Si Bob essaie de taper des produits et de saisir un produit par erreur, il sait déjà qu'il y a une URL sur le site Web pour les produits et vous ne lui dites rien qu'il ne sait pas. Si vous ne suggérez pas d'URL qui ne devraient pas être publiques, vous n'aurez aucun problème.
Pourquoi utiliser un message 404 et ne pas effectuer de redirection immédiate?

Cependant, cela m'a conduit à me demander si cela était considéré comme une mauvaise pratique, car le serveur pourrait révéler des URL que l'administrateur du site Web pourrait ne pas vouloir afficher publiquement.

1. Cela suggère que la fonctionnalité est mise en œuvre en vérifiant une liste de toutes les URL valides possibles (une liste que le serveur n'a peut-être même pas ou ne peut même pas obtenir facilement), pour inclure des URL non publiques et en comparant l'URL demandée avec elles.
2. Cela suggère qu'il existe des URL qui sont secrètes. Bien qu'il puisse y avoir des cas d'utilisation valables pour cela, en général , les pages auxquelles vous ne voulez pas que les gens accèdent ne doivent pas leur permettre d'y accéder en devinant ou en connaissant l'URL. Cependant, du point de vue de l'expérience utilisateur, il peut être ennuyeux pour l'utilisateur de se faire suggérer une URL à laquelle il ne peut pas vraiment accéder.

La fonctionnalité pourrait facilement être mise en œuvre en ayant un liste explicite des URL des pages publiques auxquelles il compare l'URL demandée à la place. Il peut être raisonnable, s'il n'y a qu'une seule correspondance, de rediriger directement l'utilisateur (en utilisant un code HTTP 302 Found) vers l'URL appropriée, ou vers une page de recherche. S'il y a plusieurs correspondances, il peut être raisonnable de les présenter dans une liste avec un code HTTP de 300 choix multiples.

Je dirais que garder une URL secrète n'est pas vraiment la meilleure pratique de sécurité. Vous pouvez avoir des liens, qu'ils soient cachés ou générés par Javascript, qui montreront l'URL de l'administrateur ou quoi que ce soit à toute personne qui la regarde. C'est encore plus vrai pour les applications SPA (Single Page Application), je pense.

Je ne pense pas qu'il soit utile de cacher les URL de navigation, si vous êtes sûr que vous avez fait votre travail pour protéger ces URL, tout va bien.

Je dirais qu'avoir cette fonctionnalité à développer vous rendrait plus conscient de la sécurité de ces URL.

Je pense que la meilleure réponse ici est de traiter l'activité nécessaire comme une redirection 301 (permanente).

Si vous pouvez anticiper les fautes d'orthographe et les problèmes courants et les détecter dans la configuration de votre serveur Web (que ce soit Apache, Nginx , ou IIS), toute l'activité doit être complètement transparente pour l'utilisateur.

Dans votre application Web, vous pouvez ajouter une gestion supplémentaire pour alerter l'utilisateur qu'il a été redirigé si vous le souhaitez. J'ai vu cela faire avec une sorte de superposition d'alerte discrète qui disparaît au bout de quelques secondes. Je ne me souviens pas où je l'ai vu.

Quel que soit le script que vous utilisez pour déterminer les URL à proposer en tant que suggestions, filtrez toutes les URL d'administrateur.

Ce n'est pas un problème de sécurité. Un statut 404 est destiné à informer votre visiteur qu'il a demandé une ressource que le serveur ne connaît pas. Il est très raisonnable d'inclure de l'aide dans la réponse. Par exemple, de nombreux serveurs proposent des fonctionnalités de recherche sur leur page 404. Si vous pouvez offrir des suggestions utiles, vous ne faites qu'aider. (Bien sûr, proposer des URL "admin" n'est probablement pas utile.)

Si votre serveur n'est pas configuré de manière sécurisée, vous devez résoudre ce problème, mais vous devez le faire, que vous essayiez ou non de fournir une réponse 404 plus utile.

Suggérer une URL "réelle" ne serait un risque de sécurité que si elle (et le code HTML source - "afficher la source") identifiait la technologie backend (CMS, etc.) et si le système / CMS présentait des failles de sécurité.

Par exemple, si j'ai dirigé un site WordPress et vu les formats d'URL traditionnels de http://example.com/2016/05/20/my-article et le code source contenu les répertoires wp-content en tant qu'URL de ressources (CSS, JS, images, etc.) alors peu importe la complexité de mes URL - le backend a été révélé et ce ne serait qu'une question de temps avant qu’un pirate ne trouve vos URL d’administration.

De l’autre côté, si mes URL ne contenaient que des URL simples et conviviales et que mon code source avait des répertoires ou un balisage difficiles à identifier, alors ce serait très difficile de trouver le système / CMS en arrière-plan et il serait beaucoup plus difficile d'attaquer.

De toute évidence, comme beaucoup l'ont dit, masquer les URL d'administration "aiderait" et vous pourriez implémenter des mécanismes tels que .htaccess to p empêcher certains accès par IP (pour vos pages d'administration, etc.) mais il n'y aura jamais de protection à 100%.

Essentiellement, moins votre site en donne, plus il est devenu sécurisé (IMO); et suggérer de vraies URL (qui ne sont pas celles de votre administrateur) n'a aucun effet sur la sécurité de votre site.