J'écris actuellement une application Web, et mon client m'a demandé s'il serait possible de suggérer une URL valide à l'utilisateur lorsqu'il écrivait accidentellement une faute de frappe dans la barre d'URL, un exemple de ceci se présenterait comme suit:
- Bob accède à ' https://www.example.com/product '
- Le serveur Web ne trouve pas la route '/ produit', mais sait que la route '/ produit s ' existe
- Le serveur Web suggère à Bob de naviguer vers '/ produits' à la place
- Bob accède à "/ products" et continue de parcourir le site Web
Cet exemple permettrait à Bob d'avoir une meilleure expérience utilisateur.
Cependant, cela m'a amené à me demander si cela est considéré comme une mauvaise pratique, car le serveur peut exposer les URL que l'administrateur du site Web peut ne pas vouloir afficher publiquement.
Si Bob essaie de taper des produits et des types de produits erronés, il sait déjà qu'il y a une URL dans le site Web pour les produits et vous ne lui dites donc rien qu'il ne sache. Si vous ne proposez pas d'URL qui ne devraient pas être publiques, vous n'aurez aucun problème.
Pourquoi utiliser un message 404 et ne pas faire de redirection immédiate?
Cependant, cela m'a amené à me demander si cela est considéré comme une mauvaise pratique, car le serveur peut exposer les URL que l'administrateur du site Web ne souhaite pas afficher publiquement.
La fonctionnalité pourrait facilement être implémentée en ayant une liste explicite d'URL de pages publiques à laquelle elle compare l'URL demandée. Il pourrait être raisonnable, s'il n'y a qu'une seule correspondance, de rediriger directement l'utilisateur (en utilisant un code HTTP 302 trouvé) vers l'URL appropriée, ou vers une page de recherche. S'il existe plusieurs correspondances, il peut être raisonnable de les présenter dans une liste avec un code HTTP 300 choix multiples.
Je dirais que garder un URL secret n'est pas vraiment la meilleure pratique de sécurité. Vous pouvez avoir des liens, cachés ou générés par Javascript, qui montreront l'URL d'administration ou quoi que ce soit à quiconque y jettera un œil. 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 d'avoir fait votre travail pour protéger ces URL, ça va.
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 votre configuration de 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 un traitement supplémentaire pour avertir l'utilisateur qu'il a été redirigé si vous le souhaitez. J'ai vu cela se faire avec une sorte de superposition d'alerte discrète qui disparaît après quelques secondes. Je ne me souviens pas où je l'ai vu.
Dans le script que vous utilisez pour déterminer les URL à proposer en tant que suggestions, filtrez toutes les URL d'administration.
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 offrent une fonctionnalité de recherche sur leur page 404. Si vous pouvez faire des suggestions utiles, vous ne faites qu'aider. (Bien sûr, offrir des URL "admin" n'est probablement pas utile.)
Si votre serveur n'est pas configuré correctement, 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 pour la sécurité que si elle (et le HTML source - "voir la source") identifiaient la technologie de backend (CMS etc.) et si le système/CMS avait des failles de sécurité.
Par exemple, si j'ai exécuté un site WordPress et que j'ai vu les formats d'URL traditionnels de http://example.com/2016/05/20/my-article
et le code source contenait le wp-content
répertoires en tant qu'URL de ressource (CSS, JS, images, etc.), 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 informatique 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 des balises pas très facilement identifiables, il serait très difficile de trouver le système/CMS en arrière-plan et ce serait beaucoup plus plus difficile à attaquer.
Évidemment, comme beaucoup l'ont dit, masquer les URL d'administration "aiderait" et vous pourriez implémenter des mécanismes tels que .htaccess pour 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 donne, plus il est devenu sûr (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.