Pourquoi les clés primaires de la base de données ne doivent-elles pas être affichées en code html, par ex. dans certains champs?

Question

partout où je lis que les valeurs dans les zones de sélection (ou toute autre chose dans le code html) ne devrait pas être la clé primaire de la table de base de données. Par exemple:

<select> 
     <option value="1">Value 1</option> 
     <option value="2">Value 2</option> 
</select> 

Dans la base de données il y a des tables avec consultation ces valeurs comme clé primaire (1, 2, 3, ....). Donc les données de la boîte de sélection que je stocke dans une table qui fait référence à cette table de recherche est un nombre comme 1, 2, 3 .... (comme la valeur des champs d'options). J'ai lu pour mieux ne pas utiliser les mêmes valeurs en html et en tant que clé pour des raisons de sécurité, mais quel est le problème? Je ne comprends pas pourquoi cela devrait être une raison de sécurité?

Answer 1

Semble comme security-through-obscurity, aka pas de sécurité du tout pour moi.

Une bonne clé primaire dans une base de données est purement pour l'unicité dans le système et ne doit pas être liée à la signification des données. Si la clé primaire était liée aux données (disons les numéros de sécurité sociale des gens, des trucs comme ça) alors vous avez un problème de sécurité en exposant les clés, car elles exposent des informations qui pourraient être utilisées avec malveillance. Dans ce cas, alors que vous pourriez argumenter que la meilleure approche d'un point de vue technique pourrait être de changer l'application pour l'arrêter en utilisant ces clés significatives, il peut être une approche plus acceptable pour mapper les clés à une autre clé sans signification le problème. Un autre scénario qui vient à l'esprit lorsque l'exposition des clés peut être interprétée comme un problème de sécurité est l'authentification et l'autorisation inadéquates des données inscriptibles dans votre couche application/données, ce qui permet à une personne connaissant ces clés d'interférer avec les données dans l'application. Encore une fois, sécuriser le système est la meilleure approche. Mis à part la sécurité, je ne peux pas penser à un problème spécifique si les clés identifient réellement les données avec lesquelles elles interagissent et que votre application recherche les clés lorsqu'elle génère la page.

Answer 2

Les clés primaires doivent être utilisées comme identificateur unique pour chaque élément de la base de données, il est probable qu'il ne s'agisse pas d'un numéro de pièce ou de tout élément se rapportant à l'élément réel. D'une manière générale, le PK ne signifie rien, et dans le monde de la sémantique, tout devrait signifier quelque chose. S'il existe un meilleur identifiant unique, utilisez-le de toute façon, car votre PK n'est utile que pour votre base de données. Dites que vous avez une base de données de voitures, toutes les voitures ont un identifiant unique appelé VIN (Vehicle Identification Number) dans le NIV est codé un tas d'informations sur chaque voiture spécifique à l'usine qui l'a fait. Le NIV identifie seulement cette voiture spécifique. le PK sur l'objet pourrait être n'importe quoi, la voiture est lâchée de la DB, maintenant le PK n'existe pas, mais ce VIN est toujours là quelque part. C'est un ID bien meilleur que le PK, c'est ce qui devrait probablement être affiché aux utilisateurs.

Answer 3

Je serais préoccupé par la façon dont les informations sont traitées à partir de l'URL. Que faire si je le contenu affiché à l'aide value = « does_this_break_the_code » ou value = « can_I_read_secret_info »

Answer 4

Il serait sage de faire preuve de prudence dans l'utilisation des clés de substitution dans les URL ou dans le code HTML ou de l'application. Je ne dirais pas la même chose à propos des clés en général.

Une clé de substitution n'est pas censée avoir une signification commerciale ou avoir des dépendances dans le code d'application ou les processus externes. C'est souvent une considération importante, par exemple, si les valeurs clés doivent changer en raison de l'évolution de la conception de la base de données ou de la fusion des ensembles de données.En utilisant des clés de substitution comme "nombres magiques" dans le code ou dans les URL, vous pourriez compromettre la chose même qui rend les clés de substitution utiles. Les clés de substitution sont également beaucoup moins pratiques pour les utilisateurs (et peut-être les développeurs) parce que les valeurs n'ont aucun sens pour eux et sont donc moins lisibles que l'utilisation d'une clé naturelle.

Je vous suggère d'utiliser des clés naturelles dans vos URL et du code persistant. Conservez les clés de substitution à l'intérieur de la base de données, où elles sont supposées être.