Je suis très nouveau au printemps. J'essaie de créer une API REST à l'aide de Spring Boot et je ne peux pas exposer ou non la clé primaire de mon utilisateur, qui se trouve également être son e-mail. Quelque chose comme api/user/example@gmail.com . Une grande partie de moi dit que ce n'est pas grave, car il serait judicieux de l'exposer car il s'agit de l'identifiant de cet enregistrement spécifique lors de la visualisation, de la suppression et de la mise à jour. Y a-t-il un risque de sécurité pour cela? Quelle est la meilleure pratique pour une telle mise en œuvre? En ce moment, je combine @PathVariable et @RequestBody . Je n'aimais pas l'idée de mettre ma clé primaire dans RequestBody en pensant que cela pourrait poser un risque ... ou y en a-t-il?
@RequestMapping(value = "/updateUser/{customerEmail}", method = RequestMethod.POST)
public ApiResult updateCustomer(@RequestBody UserDetailsDto userDetailsDto, @PathVariable String customerEmail) {
//service call...
}
3 Réponses :
Spring est un bon cadre de choix, généralement tant que l'identifiant est unique, cela devrait aller, le problème avec l'utilisation d'un e-mail est que vous exposez plus facilement les données de vos utilisateurs, ce qui pourrait être problématique pour les utilisateurs, je suggère vous utilisez plutôt une chaîne de caractères uniques comme identifiant sous la forme de:
http://api.example.com/user-management/users/{id} comme exemple http://api.example.com/user-management/users / 22 dans ce cas, l'identifiant de l'utilisateur 22 a l'adresse e-mail example@gmail.com de cette façon, vous n'exposez pas de données sensibles lors d'une mise à jour voici un lien qui donne des conseils sur les meilleures pratiques de dénomination < a href = "https://restfulapi.net/resource-naming/" rel = "nofollow noreferrer"> https://restfulapi.net/resource-naming/ .
Une autre astuce donnée dans le lien fourni est d'éviter d'utiliser les URI comme fonctionnalité CRUD (Créer, Lire, Mettre à jour, Supprimer) "Les URI doivent être utilisés pour identifier de manière unique les ressources et non aucune action sur elles".
Plus sur la pratique de nommage
Je pense que c'est plus une question de goût et de croyances personnelles que d'aspects objectifs.
Puisque HTTPS est plus ou moins obligatoire aujourd'hui, il est beaucoup plus difficile d'obtenir l'adresse e-mail en reniflant simplement avec un outil comme Wireshark.
Alors, quel est le risque possible? Étant donné que les utilisateurs doivent être autorisés à appeler ce point de terminaison, ils connaissent au moins leur propre adresse e-mail et l'ont très probablement utilisée pour s'authentifier. Ainsi, un utilisateur ne peut pas modifier ou acquérir les données d'un autre utilisateur, si elles sont correctement mises en œuvre.
Un problème qui peut être préoccupant est qu'il pourrait être possible de vérifier un e-mail enregistré pendant le processus d'inscription. Selon le type d'application que vous développez, cela peut poser problème. Pour donner un bref exemple d'un tel cas: imaginez un prêtre catholique inscrit sur un site pornographique ou l'adresse e-mail de votre mari / femme enregistré sur une plateforme de rencontre.
Alors, peut-être un conseil: forcez HTTPS et vous êtes assez bien pour les utiliser comme clé primaire. Cependant, si vous avez la possibilité de résumer cela, je le ferais. Une clé numérique ou un nom d'utilisateur peut être un meilleur choix et aussi plus facile à manipuler - mais cela ne fait aucune différence. Imaginez si vous disposez d'un point de terminaison pour acquérir les données de l'utilisateur, y compris l'adresse e-mail. Peu importe que vous acquériez ces données par une touche numérique ou par l'adresse e-mail. En fin de compte, vous vous retrouvez avec l'adresse e-mail dans le corps de la réponse. Et si ce corps est accessible par quelqu'un, il peut également accéder au nom d'utilisateur et au mot de passe, rendant ainsi toute mesure de sécurité que vous avez prise inutile.
Tout d'abord, l'adresse e-mail de l'utilisateur est souvent considérée comme PII (informations personnellement identifiables) . En tant que tel, il ne serait pas judicieux de le placer dans une URL, car vous ne devez pas mettre d'informations sensibles dans l'URL . En-tête - ok, corps - aussi. Mais pas dans l'URL. La raison en est que tous les proxys / équilibreurs de charge / autres infrastructures que vous possédez ou pourriez avoir à l'avenir seront toujours autorisés à consigner les URL pour des raisons de débogage. Et vous ne voulez pas que vos données sensibles fuient entre les composants comme celui-ci. Aucune politique d'entreprise ne l'autoriserait jamais.
D'accord, alors il est juste de dire que c'est bien de le mettre dans le corps? Serait-ce également une bonne idée de faire de l'email juste un attribut normal et de créer un nouveau pkey, disons "nom d'utilisateur" pour le mettre dans l'URL en remplacement de l'email?
De plus, en supposant que «l'e-mail» ne soit pas une PII, serait-il toujours bon d'exposer la clé primaire dans l'URL à utiliser pour l'affichage, la mise à jour et la suppression? Sinon, existe-t-il une meilleure pratique à cet égard?
Cela dépend du contexte (il pourrait également y avoir un problème avec les "références d'objets directes non sécurisées" si vous ne vous authentifiez pas et ne vérifiez pas correctement le contrôle d'accès), mais je dirais que si le courrier électronique n'était pas des informations personnelles, la mise en URL est correcte.
Le corps va bien. Le nom d'utilisateur - sinon PII - est ok aussi. De nouveau. Tant que vous ne créez pas de références d'objets directes non sécurisées.
Je vois votre point sur l'IDOR. Très bien merci pour le partage.
Je serais un utilisateur mécontent si je voyais que mon e-mail était exposé. Doublement mécontent si mon email a également été utilisé comme partie d'authentification.
@AndrewS ouais mais comment feriez-vous une mise à jour ou une suppression si l'identifiant (e-mail) n'est pas mis dans l'URL? Je ne peux pas non plus crypter l'e-mail car il serait fastidieux d'effectuer une recherche au niveau de la base de données. Avez-vous une alternative? Je vois que Facebook utilise le nom d'utilisateur de l'utilisateur pour ses URL de profil.
avoir un autre identifiant pour votre utilisateur - celui que vous fournissez (un numéro ou quelque chose) quand quelqu'un s'enregistre, il utilise son courrier mais vous fournissez l'identifiant dans le serveur et c'est ce qu'il verra plus tard quand quelqu'un obtient un profil afficher ce numéro dans l'url . (un exemple élaboré sera que dans Facebook, ils utilisent un nom personnalisable comme lien vers votre profil)
@GabrielH Ohh, je ne peux pas croire que j'ai raté ça. J'espérais réduire le nombre de clés pour réduire la complexité, c'est pourquoi j'ai utilisé l'e-mail comme clé primaire. Donc je vais juste devoir attribuer une nouvelle clé primaire appelée "nom d'utilisateur" et avoir l'e-mail comme un autre attribut mais l'avoir également unique.