Espace client : vérifier que chaque client voit uniquement ses documents

Espace client : vérifier que chaque client voit uniquement ses documents

Votre espace client permet de retrouver un devis, télécharger une facture ou déposer une pièce jointe. Avant sa mise en service, une question mérite une démonstration : que se passe-t-il lorsqu’un client tente d’ouvrir le document d’un autre ?

Une connexion réussie confirme une identité. L’application doit aussi vérifier ce que cette personne peut consulter ou modifier. Voici une méthode pour préparer ces contrôles avec votre prestataire. L’exemple d’une PME qui partage des devis et des comptes rendus est fictif ; il sert à construire vos propres tests.

Écrire les règles avant de choisir les écrans

Commencez par décrire les accès attendus en langage métier. Un contact consulte-t-il tous les documents de son entreprise ou seulement ceux de son dossier ? Peut-il inviter un collègue ? Un intervenant extérieur voit-il les pièces jointes ? Qui peut remplacer un document déjà publié ?

Pour chaque action, précisez la personne autorisée, les documents concernés et les éventuelles limites. Prévoyez un refus lorsque aucune règle n’accorde l’accès. L’OWASP recommande de limiter les permissions au nécessaire et de les vérifier à chaque requête, côté serveur. Masquer un bouton dans l’interface ne constitue donc pas une protection suffisante. Référence OWASP sur les autorisations.

Le livrable utile est une liste lisible par l’équipe : « Le responsable du dossier peut publier un compte rendu ; le contact client peut le consulter. » Faites valider cette liste par la personne qui gère réellement les échanges avec les clients.

Tester avec des comptes et des documents fictifs

Demandez un environnement de test avec des comptes rattachés à des entreprises distinctes. Chaque entreprise dispose de documents reconnaissables, sans données réelles. Vérifiez d’abord que chacun peut effectuer les actions prévues sur ses propres dossiers.

Testez ensuite un accès qui doit échouer : un compte tente d’ouvrir directement l’adresse d’un document appartenant à l’autre entreprise. Répétez le contrôle sur le téléchargement, la modification et l’export, selon les fonctions disponibles. Ces essais doivent rester dans le périmètre autorisé, avec les comptes de test préparés pour cela.

L’OWASP décrit ce risque sous le nom d’IDOR : un contrôle manquant permet d’accéder à une ressource en manipulant sa référence. Un identifiant long et difficile à deviner peut compliquer cette manipulation, mais il ne remplace pas la vérification des droits. Guide OWASP sur les références directes aux objets.

Conservez le résultat attendu et le résultat observé pour chaque essai. Une capture du tableau de bord ne prouve pas que le téléchargement direct est protégé.

Vérifier le stockage des pièces jointes

Une page peut être réservée aux clients tandis que les fichiers qu’elle affiche restent accessibles publiquement. Demandez où sont enregistrés les documents et comment leur téléchargement est contrôlé.

Pour les fichiers déposés, l’OWASP recommande notamment un stockage séparé ou hors du répertoire directement servi par le site, ainsi que des vérifications d’autorisation. L’application doit aussi encadrer les types de fichiers et leur taille. Ces contrôles répondent à des risques complémentaires : un utilisateur autorisé peut déposer un fichier problématique. Recommandations OWASP pour les fichiers téléversés.

Dans notre exemple, suivez une pièce jointe depuis son dépôt jusqu’à sa consultation. Vérifiez son rattachement au bon dossier, puis les éventuels aperçus générés. Posez aussi la question des exports : où sont-ils stockés et qui peut les récupérer ? Chaque copie produite doit avoir un usage et un accès définis.

Comprendre ce que permet un lien temporaire

Certains espaces clients délivrent une adresse de téléchargement signée, valable pendant une durée limitée. Ce fonctionnement mérite une règle explicite de partage.

Amazon S3 précise que ses URL présignées donnent accès à la personne qui les possède, dans les limites des permissions associées. Leur expiration dépend notamment de la durée prévue et de la validité des identifiants utilisés pour les créer. Un lien encore valable peut donc être transmis à quelqu’un d’autre. Documentation Amazon S3 sur les URL présignées.

Si cette technique est utilisée, demandez quand le lien est généré, après quel contrôle et pendant combien de temps il reste utilisable. Vérifiez aussi ce qui arrive à un lien déjà émis lorsque le compte perd ses droits. La suppression de l’accès dans le portail ne garantit pas, à elle seule, l’invalidation immédiate de ce lien. Le comportement exact dépend du service et de l’architecture retenus.

Prévoir le départ d’un contact client

Un interlocuteur change de poste et un collègue reprend le dossier. Cette situation doit faire partie de la recette du portail, c’est-à-dire des vérifications avant son acceptation.

Préparez avec votre prestataire un scénario de retrait d’accès. Vérifiez les nouvelles connexions, mais aussi les sessions déjà ouvertes et les liens précédemment obtenus. Précisez qui effectue la modification et comment l’équipe confirme sa prise en compte.

L’OWASP indique notamment qu’une déconnexion doit invalider la session côté serveur. Fermer un onglet ou une fenêtre ne permet pas de garantir cette déconnexion ; des mécanismes d’expiration restent nécessaires. Guide OWASP sur la gestion des sessions.

Un document déjà téléchargé reste toutefois entre les mains de son destinataire. Présentez clairement cette limite aux personnes qui publient les pièces dans le portail.

Garder des traces qui permettent de comprendre

Quand un client signale un accès inattendu, il faut pouvoir retrouver l’action concernée. Demandez un historique adapté : compte utilisé, moment de l’événement, document visé, opération demandée et résultat du contrôle.

L’OWASP recommande de journaliser les refus d’autorisation et les changements de privilèges. Il déconseille d’inscrire directement dans les journaux les mots de passe, jetons d’accès et autres secrets. Guide OWASP sur la journalisation.

Évitez donc de recopier le contenu complet des documents dans les alertes. Définissez aussi qui consulte les traces et qui reçoit les signalements. Un historique que personne ne sait retrouver aide peu lorsqu’un incident survient.

Demander une preuve avant l’ouverture

Avant d’inviter vos clients, rassemblez les règles d’accès validées, les résultats des essais entre comptes et la procédure de retrait des droits. Ajoutez les limites connues des liens de partage et le contact à prévenir en cas d’anomalie.

Faites rejouer les tests lorsque le portail gagne une fonction d’export, un nouveau rôle ou une intégration. Cette checklist prépare la discussion et la recette ; elle ne constitue pas un audit de sécurité complet.

Vous préparez un espace client ou une application métier ? Décrivez les documents à partager et les personnes qui doivent y accéder. Ce cadre permet de préciser les contrôles attendus dès la conception.

Sources officielles consultées le 9 octobre 2026. Les mécanismes disponibles dépendent des outils et de leur configuration.