Pour l’idor, c’est l’idée générale, mais c’est soit lourd, soit pas forcément trivial à implémenter.
Tu peux le faire dans le front end, mais c’est lourd et c’est facile de rater quelques endroits.
Tu peux le faire dans le backend, mais la propagation d’identité et d’autorisations dans une monde soa c’est pas trivial, surtout quand t’as des cas d’utilisations qui sont pas initiés par l’utilisateur (genre un e-mail déclenché par un événement sur un bus).
Pour repartir sur le fourchette, si t’invite des potes à ta réservation, maintenant eux aussi y ont accès. Sauf que c’est potentiellement un autre service qui gère les invit’. Maintenant ton service réservation doit comprendre ce genre de chose pour pourvoir te donner accès aux données.
Pour les PII, je suis pas sur de comprendre la question. Le problème c’est pas tant les id, qu’exposer trop de PII au monde.
Si je commande un Uber et que l’api d’uber me retourne le nom de famille et numéro de téléphone perso du chauffeur, c’est une PII leak, même si l’appli ne les montre pas.
Et ça peut arriver relativement facilement en fonction de comment ton backend marche, la vitesse à laquelle ça a été développé et l’attention portée aux problématiques de vie privée. L’ID du chauffeur peut être un uuid, ça aide pas si les dev ne font pas gaffe à ce qu’ils font.
[^] # Re: Nuance...
Posté par groumly . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 3.
Pour l’idor, c’est l’idée générale, mais c’est soit lourd, soit pas forcément trivial à implémenter.
Tu peux le faire dans le front end, mais c’est lourd et c’est facile de rater quelques endroits.
Tu peux le faire dans le backend, mais la propagation d’identité et d’autorisations dans une monde soa c’est pas trivial, surtout quand t’as des cas d’utilisations qui sont pas initiés par l’utilisateur (genre un e-mail déclenché par un événement sur un bus).
Pour repartir sur le fourchette, si t’invite des potes à ta réservation, maintenant eux aussi y ont accès. Sauf que c’est potentiellement un autre service qui gère les invit’. Maintenant ton service réservation doit comprendre ce genre de chose pour pourvoir te donner accès aux données.
Pour les PII, je suis pas sur de comprendre la question. Le problème c’est pas tant les id, qu’exposer trop de PII au monde.
Si je commande un Uber et que l’api d’uber me retourne le nom de famille et numéro de téléphone perso du chauffeur, c’est une PII leak, même si l’appli ne les montre pas.
Et ça peut arriver relativement facilement en fonction de comment ton backend marche, la vitesse à laquelle ça a été développé et l’attention portée aux problématiques de vie privée. L’ID du chauffeur peut être un uuid, ça aide pas si les dev ne font pas gaffe à ce qu’ils font.