Visionneuse Doconut devient partie intégrante de la frontière de sécurité de votre application dès qu'elle affiche des contrats, factures, dessins techniques ou dossiers clients. Doconut fournit la couche de visualisation ; l'application environnante doit encore décider qui peut ouvrir un fichier, où la source est stockée, combien de temps les données dérivées restent disponibles, et ce qui est enregistré pour l’enquête.

Un document protégé entouré de contrôles d'accès en couches et d'une piste d'audit

L'article de Doconut sur les pratiques sécurisées de visualisation de documents décrit le rendu côté serveur comme une couche d'une conception en profondeur de défense. Cet article se concentre donc sur les responsabilités de l'application autour de Doconut et renvoie les détails d'implémentation à la documentation produit maintenue.

Commencer par un modèle de menace

« Privé » et « sécurisé » ne sont pas des configurations. Définissez les événements que vous devez prévenir ou détecter avant de choisir les contrôles.

Risque	Exemple	Contrôle d'application
Accès non autorisé	Un utilisateur modifie un identifiant de document dans l'URL	Autorisation au niveau de l'objet à chaque requête
Croisement de locataires	Un utilisateur valide demande le fichier d'un autre client	Portée du locataire incluse dans la décision d'autorisation
Exposition de la source	Un chemin de stockage ou le fichier original est renvoyé directement	Flux de recherche et de rendu contrôlé par le serveur
Accès obsolète	Un lien reste utilisable après qu'un rôle ou un cas a changé	Durée de session courte plus revalidation de l'autorisation
Rétention excessive	Des entrées ou sorties temporaires s'accumulent	Jobs de cycle de vie explicites avec résultats observables
Journalisation sensible	Des jetons ou emplacements de fichiers apparaissent dans les journaux	Redaction structurée et télémétrie uniquement d'identifiants

Priorisez les risques en fonction des documents et des utilisateurs de votre système. Une bibliothèque de brochures publiques et un portail de preuves légales ne doivent pas partager la même politique simplement parce qu'ils utilisent la même visionneuse.

Le cas d'utilisation de révision de documents juridiques de Doconut constitue une référence utile pour le rôle du produit au sein des flux de travail authentifiés de dossiers, contrats, preuves et conformité. Il renforce également la frontière architecturale : les permissions, le stockage, les dossiers clients et les règles métier restent proches de l'application hôte.

Autoriser avant d'ouvrir le document

Effectuez l'authentification et l'autorisation au niveau de l'objet avant d'ouvrir le document avec Doconut. Le guide officiel de configuration .NET 6 ou supérieur montre comment la visionneuse est configurée et comment un document côté serveur est ouvert ; placez les vérifications d'identité, de locataire et de permission du document de votre application avant cette étape du produit.

Répétez la même règle d'autorisation pour chaque opération liée que votre application expose, y compris les pages, les miniatures, la recherche, les annotations, la conversion, le téléchargement et l'impression. Masquer un bouton ne protège pas la requête sous-jacente.

Évitez d'accepter directement du navigateur un chemin de système de fichiers, une clé de stockage ou une URL distante. Résolvez un identifiant de document appartenant à l'application vers son emplacement de stockage sur le serveur, puis confirmez que l'objet résolu appartient au locataire autorisé et au flux de travail.

Séparer la visionneuse de la politique de stockage

La visionneuse ne doit pas définir votre période de rétention. Documentez chaque classe de stockage et son propriétaire :

Document source — contrôlé par votre politique principale de contenu ou de dossiers.
Fichiers de travail temporaires — créés pour le traitement et supprimés par un cycle de vie planifié et observable.
Pages rendues ou caches — limités à la durée de vie minimale utile et protégés comme la source.
Exports et fichiers prêts à imprimer — créés uniquement lorsque l'utilisateur possède la permission correspondante.
Journaux et événements d'audit — contiennent des identifiants et des résultats, pas le contenu du document ni les informations d'identification.

Le chiffrement en transit et au repos dépend de votre serveur web, de votre fournisseur de stockage, de la gestion des clés et des paramètres de déploiement. Vérifiez ces contrôles dans l'environnement réel ; ne les déduisez pas de la présence d'une bibliothèque de visionneuse.

Utiliser soigneusement les références à courte durée de vie

Une référence à courte durée de vie peut réduire le temps disponible pour une relecture, mais elle ne remplace pas l'autorisation. Si votre conception utilise une route signée ou un jeton de session :

Lier la référence à un seul document et à l'opération prévue.
Lui attribuer une durée de vie restreinte basée sur le flux de travail.
Éviter de placer des revendications sensibles ou des emplacements de stockage en texte clair.
Revalider l'autorisation pour les opérations privilégiées.
Définir ce que signifie la révocation avant le délai d'expiration naturel.
Garder les jetons hors des analyses, référents, messages d'exception et captures d'écran.

Lorsque la session du navigateur expire, affichez un message neutre et proposez un moyen sûr de se réauthentifier. Ne révélez pas si un autre locataire possède le document.

Comprendre ce que les contrôles côté client peuvent et ne peuvent pas faire

Supprimer les contrôles de téléchargement ou d'impression peut améliorer le flux de travail prévu, mais ce n'est pas une garantie de confidentialité. Un utilisateur qui peut voir le contenu peut toujours capturer l'écran, le photographier ou utiliser les capacités du navigateur en dehors de la visionneuse.

Considérez les restrictions côté client comme des mesures d'utilisabilité et de dissuasion. Des contrôles plus forts proviennent du fait de garder les fichiers sources derrière le serveur, d'appliquer l'autorisation à chaque requête liée, de limiter les exportations et d'utiliser des filigranes visibles lorsque votre politique l'exige.

Ne pas transformer les fonctionnalités du produit en affirmations de conformité

La conformité réglementaire dépend de l'objectif, des catégories de données, de la base légale, des contrats, du traitement régional, de la rétention, de la réponse aux incidents et des procédures organisationnelles. Une visionneuse peut soutenir une conception conforme, mais elle ne rend pas une application conforme à elle seule.

Pour une évaluation GDPR, documentez au minimum :

Où les fichiers source et dérivés sont traités et stockés
Qui agit en tant que responsable et sous-traitant pour chaque service
Quels sous-traitants et quels transferts sont impliqués
Comment les demandes de suppression atteignent chaque classe de stockage et la politique de sauvegarde
Quels événements sont journalisés et pendant combien de temps les journaux restent disponibles
Comment les revues d'accès et la réponse aux incidents sont effectuées

Faites valider ces décisions par les parties prenantes en matière de confidentialité et juridique pour votre déploiement.

Ajouter des en-têtes de sécurité et des règles de cache

Pour les routes d'aperçu authentifiées, évaluez une Content Security Policy restrictive, une politique d'encadrement, une protection contre le sniffing MIME et une politique de référent. Si l'aperçu apparaît dans une iframe, indiquez explicitement les origines parent prévues.

Choisissez les en-têtes de cache en fonction de la sensibilité et de la route de rendu. no-store peut être approprié pour certaines réponses, mais il peut affecter les performances et n'efface pas le contenu déjà capturé ailleurs. Testez le comportement du navigateur, du proxy et du CDN plutôt que de vous fier à un en-tête isolé.

Journaliser les décisions, pas les secrets

Un événement d'audit utile peut contenir :

Identifiants d'utilisateur et de locataire
Identifiant du document
Opération demandée
Résultat de l'autorisation
Horodatage et ID de corrélation
Résultat de la rétention ou du nettoyage

Évitez de journaliser les jetons bruts, les chaînes de requête, les URL de stockage, les noms de documents contenant des données personnelles ou le texte extrait. Protégez les journaux d'audit contre toute modification et limitez l'accès aux équipes qui en ont besoin.

Vérifier le flux complet

Les tests de sécurité doivent inclure des cas négatifs :

Modifier l'ID du document tout en restant authentifié.
Réutiliser une URL d'aperçu d'un autre utilisateur ou locataire.
Appeler directement les points de terminaison page, miniature, impression et export.
Faire expirer la session pendant un aperçu long.
Retirer la permission d'un utilisateur pendant qu'un document est ouvert.
Soumettre une entrée non prise en charge, surdimensionnée, endommagée ou protégée par mot de passe.
Confirmer que les jobs de nettoyage suppriment les données admissibles et signalent les échecs.
Inspecter les journaux, les analyses et les pages d'erreur à la recherche de valeurs sensibles.

Automatisez les cas stables et conservez une revue manuelle pour la configuration du stockage, la politique du navigateur et les changements de version de la visionneuse.

Conclusion

Une intégration soucieuse de la sécurité possède une propriété claire. Doconut fournit la capacité de visualisation de documents décrite dans sa documentation officielle ; votre application fournit l'authentification, l'autorisation, les contrôles de stockage, la rétention, la surveillance et la réponse aux incidents. Garder ces responsabilités explicites produit des contrôles plus solides et des affirmations de confidentialité plus honnêtes.