HTML encoder la saisie de l'utilisateur lors du stockage ou de l'affichage

Question

Une question simple qui me perturbe sans cesse.

Dois-je immédiatement encoder le code HTML saisi par l'utilisateur et stocker le contenu encodé dans la base de données, ou dois-je stocker les valeurs brutes et l'encodage HTML lors de l'affichage?

Le stockage de données codées réduit considérablement le risque qu'un développeur oublie de coder les données lors de leur affichage. Cependant, le stockage des données codées rendra l’analyse de données un peu plus lourde et prendra un peu plus d’espace, même si cela ne pose généralement pas de problème.

Answer 1

Je suggérerais fortement de coder les informations avant de sortir. le stockage de données brutes dans la base de données est utile si vous souhaitez modifier la façon dont elles sont visualisées à un moment donné. le flux doit ressembler à:

sanitize user input -> protect against sql injection -> db -> encode for display

Pensez à une situation dans laquelle vous pourriez vouloir afficher les informations sous forme de flux RSS. avoir à refaire tout encodage spécifique HTML avant de ré-afficher semble un peu idiot. tout développement doit toujours suivre les instructions "ne faites pas confiance". meme, que cette entrée provienne d'un utilisateur ou de la base de données.

Answer 2

Le codage doit uniquement être effectué à l’écran. Sans exception.

Answer 3

Sortie.

Avec HTML, vous ne pouvez pas simplement vérifier la longueur d'une chaîne ( & amp; est composé de 1 caractère, mais strlen () vous en dira 5), ??vous pourrez rognez-le facilement (cela pourrait casser des entités).

Vous devrez peut-être mélanger des chaînes de la base de données avec des chaînes d'une autre source ou les lire et les réécrire. Faire cette application à l’échelle de l’application sans manquer d’évasion et éviter une double évasion est un cauchemar.

PHP a essayé de faire la même chose avec magic_quotes et cela s’est avéré être un énorme échec. Ne prenez pas la route magic_entities ! :)

Answer 4

N'oubliez pas que vous devrez peut-être accéder à la base de données avec quelque chose qui ne comprend pas le texte codé HTML (par exemple, un outil de génération de rapports). Je conviens que l’espace n’est pas un problème, mais à mon humble avis, le codage HTML dans la base de données place la connaissance de votre vue / frontal dans le niveau le plus bas de l’application, ce qui est une erreur de conception.

Answer 5

Cela n’atteint-il pas le but de l’encodage? Si un script SQL malveillant est entré en tant qu'entrée, il est ensuite transmis à la base de données, ce qui pourrait poser un gros problème.