cidocfm

Règle de conception : une identité authentifiée n’est pas automatiquement autorisée ; une requête autorisée n’est pas automatiquement sûre si les entrées, les données et les effets métier ne sont pas validés Résumé La sécurité des applications web repose sur plusieurs mécanismes complémentaires qui ne doivent pas être confondus : l’authentification, l’autorisation, la validation des entrées, la protection des données et le contrôle des effets métier. Une identité authentifiée correspond à un utilisateur dont l’identité a été vérifiée par le système. Cependant, cette vérification ne lui confère pas automatiquement le droit d’accéder à toutes les ressources ni d’exécuter toutes les opérations disponibles. De même, une requête autorisée peut contenir des données incorrectes, provoquer un changement inattendu ou enfreindre une règle métier si les contrôles appropriés ne sont pas appliqués. Cet article examine ces principes dans le contexte des applications web modernes, des plateformes de commerce électronique, des bibliothèques numériques et des centres d’information documentaire scientifique. Il présente des scénarios concrets, des exemples de programmation en HTML, CSS, JavaScript et pseudocode serveur, ainsi que des recommandations permettant de renforcer la sécurité des systèmes d’information à l’ère de l’intelligence artificielle. Mots-clés : authentification, autorisation, cybersécurité, validation des données, contrôle d’accès, sécurité applicative, règles métier, API, intelligence artificielle, bibliothèque numérique, CIDOCFM. 1. Introduction Les applications web contemporaines permettent de consulter des documents, de gérer des collections scientifiques, d’effectuer des achats, de traiter des paiements et d’administrer des bases de données. Ces opérations impliquent des utilisateurs possédant des profils et des permissions différents. La sécurité de ces systèmes dépend donc de leur capacité à vérifier non seulement l’identité des utilisateurs, mais également leurs droits et la légitimité de chaque opération demandée. Une erreur fréquente consiste à considérer qu’un utilisateur connecté peut être traité comme un utilisateur entièrement fiable. Cette approche est dangereuse. Un compte authentifié peut être compromis, un utilisateur légitime peut tenter une opération interdite et une requête techniquement valide peut produire un résultat contraire aux règles de l’application. La règle de conception étudiée dans cet article exprime trois exigences fondamentales : 1. L’identité doit être vérifiée avant d’établir une session ou d’accorder un accès. 2. Les permissions doivent être vérifiées pour chaque ressource et chaque opération protégée. 3. Les données reçues et les conséquences de l’opération doivent être validées avant toute modification importante. Ces exigences s’appliquent aux sites marchands, aux systèmes de gestion documentaire, aux applications bancaires, aux services administratifs et aux plateformes d’intelligence artificielle. Pour CIDOCFM, centre d’information documentaire scientifique, elles sont particulièrement importantes. Une plateforme documentaire doit protéger les comptes des utilisateurs, les notices bibliographiques, les documents numériques, les abonnements, les commandes et les paramètres administratifs. 2. Comprendre l’authentification 2.1. Définition L’authentification est le processus permettant à un système de vérifier qu’un utilisateur possède les éléments nécessaires pour établir une identité numérique. Cette vérification peut reposer sur plusieurs facteurs : – Un élément connu de l’utilisateur, comme un mot de passe. – Un élément détenu par l’utilisateur, comme une clé de sécurité. – Une caractéristique biométrique, lorsque le système la prend en charge. Une application peut également utiliser une authentification multifacteur afin de renforcer la protection des comptes sensibles. Lorsqu’un utilisateur saisit ses identifiants, le système vérifie les informations fournies et détermine si une session peut être ouverte. Si la vérification réussit, l’utilisateur est authentifié. Toutefois, cette réussite ne signifie pas qu’il possède tous les droits. 2.2. Exemple dans une bibliothèque numérique Imaginons que CIDOCFM propose un espace numérique comprenant des publications scientifiques, des notices bibliographiques et des documents réservés aux abonnés. Trois utilisateurs se connectent : – Un lecteur souhaite consulter les notices publiques. – Un documentaliste souhaite modifier les métadonnées d’une publication. – Un administrateur souhaite gérer les comptes et les paramètres du système. Les trois personnes peuvent être authentifiées. Pourtant, leurs responsabilités diffèrent. Le lecteur ne doit pas pouvoir modifier les métadonnées scientifiques simplement parce qu’il possède un compte. Le documentaliste ne doit pas pouvoir changer arbitrairement les paramètres de sécurité. L’administrateur doit lui-même respecter les contrôles et les procédures applicables aux opérations sensibles. L’authentification répond donc à la question : « Qui est cet utilisateur ? » Elle ne répond pas à la question : « Quelles opérations cet utilisateur peut-il effectuer ? » 3. Comprendre l’autorisation 3.1. Définition L’autorisation est le mécanisme qui détermine si une identité authentifiée possède les permissions nécessaires pour consulter une ressource ou réaliser une action. Ces permissions peuvent être définies en fonction : – Du rôle de l’utilisateur. – De la ressource concernée. – De l’action demandée. – Du propriétaire du document. – Du contexte de la requête. – De l’état de la transaction. – Des règles de sécurité propres à l’application. Un système peut utiliser un contrôle d’accès fondé sur les rôles, appelé RBAC, ou un contrôle d’accès fondé sur des attributs, appelé ABAC. Dans un modèle RBAC, un utilisateur reçoit un rôle qui détermine les opérations autorisées. Dans un modèle ABAC, la décision peut dépendre de plusieurs attributs, comme le rôle, le service, le niveau de confidentialité ou l’état d’une ressource. 3.2. Exemple de permissions Une plateforme documentaire pourrait définir les permissions suivantes : Fonction| Lecteur| Documentaliste| Administrateur Consulter les notices publiques| Oui| Oui| Oui Modifier une notice| Non| Oui, selon les droits| Oui Publier une notice| Non| Selon les droits| Oui Supprimer une collection| Non| Selon les droits| Selon les droits Gérer les comptes| Non| Non| Oui Modifier les paramètres de sécurité| Non| Non| Selon une politique spécifique Ce tableau est un exemple de politique de sécurité, et non une configuration universelle. Dans une application réelle, les permissions doivent être définies précisément. Le système doit aussi vérifier qu’un utilisateur peut agir sur la ressource concernée. Le simple fait de connaître l’identifiant d’une notice ne doit pas suffire pour la modifier ou la supprimer. 3.3. Le principe du moindre privilège Le principe du moindre privilège consiste à n’accorder à chaque utilisateur que les droits indispensables à ses missions. Un lecteur n’a pas besoin des droits d’administration. Un documentaliste n’a pas nécessairement besoin d’accéder aux données financières. Un service automatisé chargé d’indexer des publications ne devrait pas posséder les droits nécessaires pour gérer les comptes utilisateurs. Cette séparation limite les conséquences d’une erreur humaine, d’un compte compromis ou d’une vulnérabilité applicative. 4. Pourquoi une requête autorisée n’est-elle pas automatiquement sûre ? L’autorisation permet de déterminer si une opération est permise. Elle ne garantit pas que les données utilisées sont correctes ni que le résultat sera conforme aux règles métier. Une requête peut être autorisée tout en comportant : – Une valeur numérique négative alors qu’elle doit être positive. – Un identifiant de ressource inexistant. – Une référence à une ressource qui ne correspond pas à l’utilisateur. – Une quantité supérieure au stock disponible. – Un état de transaction incompatible avec l’opération demandée. – Un champ inattendu envoyé par le navigateur. – Une modification qui provoque une incohérence dans la base de données. Il faut donc distinguer la permission d’effectuer une action de la validité des données qui accompagnent cette action. Exemple : modification du prix d’un livre Supposons qu’un employé soit autorisé à modifier le prix d’un livre numérique vendu sur CIDOCFM. L’application vérifie son identité et sa permission. L’utilisateur envoie ensuite une requête contenant un prix de 100 unités monétaires. Si le prix est positif et respecte les règles commerciales, l’opération peut être acceptable. En revanche, si la requête contient un prix négatif, une valeur infinie, un nombre excessivement grand ou un format incorrect, l’application doit la refuser. Le fait que l’utilisateur soit autorisé à modifier les prix ne justifie pas l’acceptation de n’importe quelle valeur. Exemple : suppression d’un document scientifique Un documentaliste possède le droit de retirer certaines publications d’une collection. Il envoie une demande de suppression. Avant de l’exécuter, le système doit vérifier que le document existe, que son état permet cette opération, que le documentaliste dispose du droit requis et qu’aucune règle de conservation ne s’oppose à sa suppression. Si la publication est soumise à une obligation de conservation ou fait l’objet d’un processus de validation en cours, la suppression peut être interdite malgré les permissions générales de l’utilisateur. 5. La validation des entrées 5.1. Définition La validation des entrées consiste à vérifier que les données reçues correspondent aux formats, aux types, aux limites et aux règles attendus. Elle doit être effectuée côté serveur, car les contrôles présents dans le navigateur peuvent être contournés. Les contrôles côté client restent utiles pour améliorer l’expérience utilisateur. Ils permettent de signaler rapidement une erreur, mais ils ne remplacent jamais les contrôles côté serveur. 5.2. Exemple de validation d’un prix en JavaScript Le code suivant illustre une vérification élémentaire : function validerPrix(valeur) { const prix = Number(valeur); if (!Number.isFinite(prix) || prix <= 0) { return { valide: false, message: "Le prix doit être un nombre positif." }; } return { valide: true, message: "Le prix est valide." }; } console.log(validerPrix("100")); console.log(validerPrix("-10")); console.log(validerPrix("abc")); Cette fonction distingue une valeur acceptable de plusieurs valeurs incorrectes. Cependant, elle ne sécurise pas à elle seule un système commercial. Le serveur doit refaire les contrôles, appliquer les règles de prix, vérifier les droits de l’utilisateur et enregistrer les changements de manière cohérente. Pour un prix financier, il est également préférable d’utiliser un type numérique adapté aux montants monétaires, ou de représenter les montants en unités minimales entières lorsque cela convient à la devise et aux règles de calcul. 5.3. Validation et échappement : deux mécanismes différents La validation détermine si une donnée correspond aux règles attendues. L’échappement ou l’encodage contextuel permet de représenter cette donnée sans qu’elle soit interprétée comme du code dans un contexte particulier. Par exemple, une chaîne contenant des caractères spéciaux peut être parfaitement légitime dans un titre documentaire. Il ne faut pas la rejeter uniquement parce qu’elle contient des signes de ponctuation. En revanche, lorsqu’un titre est affiché dans une page HTML, il doit être inséré de manière sûre. Lorsqu’une donnée est utilisée dans une requête SQL, il faut employer des requêtes paramétrées plutôt que construire la requête par concaténation de chaînes. Ces mesures réduisent notamment les risques d’injection SQL et de scripts intersites, ou XSS. 6. La validation des données et leur cohérence La validation ne porte pas uniquement sur le format des données. Elle doit également prendre en compte leur cohérence avec les informations déjà enregistrées. 6.1. Vérifier l’existence d’une ressource Une application peut recevoir une demande de modification visant le document portant l’identifiant 452. Le serveur doit vérifier que ce document existe réellement. Il doit ensuite déterminer si l’utilisateur est autorisé à intervenir sur cette ressource précise. Un identifiant fourni par le navigateur ne doit jamais être considéré comme une preuve de propriété ou de permission. Cette vérification permet de réduire les risques d’accès non autorisé à des objets, notamment les vulnérabilités de type IDOR, dans lesquelles un utilisateur modifie un identifiant pour accéder à une ressource qui ne lui appartient pas ou qu’il ne peut pas consulter. 6.2. Préserver l’intégrité des métadonnées Dans un centre documentaire, une notice peut contenir un titre, un auteur, une date de publication, un identifiant normalisé, un résumé et des mots-clés. Le système doit vérifier les formats attendus et les relations entre les champs. Par exemple, une notice ne devrait pas être publiée si un identifiant obligatoire est absent ou si son état de validation interdit sa diffusion. Il faut aussi éviter qu’une modification remplace accidentellement des champs que l’utilisateur n’était pas autorisé à changer. Le contrôle des champs modifiables, parfois appelé liste blanche des propriétés acceptées, permet de limiter les modifications aux données explicitement prévues. 6.3. Utiliser des contraintes dans la base de données Les contrôles applicatifs doivent être complétés, lorsque cela est possible, par des contraintes de base de données. Ces contraintes peuvent inclure : - Des champs obligatoires. - Des clés primaires. - Des clés étrangères. - Des contraintes d’unicité. - Des limites numériques. - Des transactions garantissant la cohérence de plusieurs modifications. Ces protections empêchent certaines incohérences même si plusieurs composants de l’application interagissent simultanément. 7. Les effets métier : le dernier niveau de contrôle 7.1. Définition Les effets métier désignent les conséquences concrètes d’une opération sur le fonctionnement du service. Il peut s’agir de publier un document, de modifier un prix, de valider une commande, d’accorder un abonnement, de supprimer une ressource ou d’envoyer une notification. Une opération techniquement valide peut être interdite par les règles métier. 7.2. Exemple : commande WooCommerce Imaginons qu’un client commande un livre numérique sur CIDOCFM.com. La plateforme doit distinguer plusieurs états : commande créée, paiement en attente, paiement confirmé, commande annulée ou remboursement effectué. Un client ne doit pas recevoir automatiquement un produit payant simplement parce qu’il a accès à une page de confirmation. Le système doit vérifier l’état réel du paiement à partir d’une source fiable, conformément au mécanisme de paiement utilisé. Lorsqu’un prestataire envoie une notification de paiement, le serveur doit vérifier son authenticité, empêcher le traitement répété d’un même événement et confirmer que le montant ainsi que la référence correspondent à la commande attendue. Le téléchargement doit ensuite être accordé conformément aux règles d’accès définies pour le produit. 7.3. Prévenir les opérations répétées Une même requête peut être envoyée plusieurs fois en raison d’une connexion instable, d’un rafraîchissement de page ou d’une répétition automatique. Pour certaines opérations, notamment les paiements, les remboursements et la création de commandes, le système doit empêcher les répétitions indésirables. L’idempotence permet, lorsqu’elle est correctement conçue, de traiter plusieurs fois une même demande sans répéter ses effets métier. Par exemple, recevoir deux fois la même notification de paiement ne doit pas conduire à créditer deux fois un compte ou à enregistrer deux paiements pour une seule transaction. 7.4. Garantir la cohérence des opérations Lorsqu’une opération modifie plusieurs données liées, elle doit préserver leur cohérence. Pour une commande, cela peut concerner le stock, le montant total, le statut du paiement et le droit de téléchargement. Une transaction de base de données permet de regrouper certaines modifications afin qu’elles soient validées ensemble ou annulées en cas d’échec. Pour les processus distribués, une conception adaptée peut nécessiter des mécanismes de compensation, des événements fiables et une gestion explicite des erreurs. 8. Exemple d’architecture sécurisée côté serveur Le schéma conceptuel suivant illustre l’ordre des contrôles lors d’une requête de modification d’une notice : 1. Réception de la requête | v 2. Vérification de la session | v 3. Authentification de l'utilisateur | v 4. Vérification de la permission | v 5. Vérification des droits sur la ressource | v 6. Validation des données reçues | v 7. Vérification des règles métier | v 8. Enregistrement sécurisé | v 9. Journalisation de l'opération | v 10. Réponse adaptée à l'utilisateur Ce schéma est indicatif. Dans une application réelle, certains contrôles peuvent être regroupés ou réalisés à plusieurs niveaux. Par exemple, l’autorisation sur une ressource peut être vérifiée dans la même requête de base de données que la modification, afin de réduire les risques liés à un changement d’état entre la vérification et l’exécution. Les contrôles de sécurité doivent être appliqués à chaque point d’entrée pertinent : pages web, API, tâches planifiées, interfaces d’administration et intégrations externes. 8.1. Exemple de pseudocode serveur Le pseudocode suivant illustre une approche générale : fonction modifierNotice(requete): utilisateur = authentifier(requete.session) si utilisateur est absent: refuser(401) notice = chargerNotice(requete.noticeId) si notice est absente: refuser(404) si non autorise(utilisateur, "modifier", notice): refuser(403) donnees = validerSchema(requete.corps) si donnees sont invalides: refuser(400) si non respecterReglesMetier(notice, donnees): refuser(422) enregistrerModificationDeManiereSure( notice, donnees ) journaliserOperation(utilisateur, notice) retournerSucces() Les codes HTTP présentés sont des exemples. Le choix précis des réponses doit être cohérent avec l’architecture et les conventions de l’application. Dans une implémentation réelle, il faut également traiter les erreurs inattendues, protéger les journaux contre la divulgation d’informations sensibles et appliquer les contrôles de concurrence nécessaires. 9. Le rôle du HTML, du CSS et du JavaScript Ces trois technologies jouent des rôles différents dans une application web. 9.1. HTML : structurer les informations HTML définit les champs, les boutons, les titres, les formulaires et les zones de résultat. Un formulaire peut demander un titre de publication, un auteur et une date. Il peut utiliser des attributs comme "required", "type="email"" ou "min" pour guider la saisie. Ces attributs ne remplacent cependant pas la validation côté serveur. 9.2. CSS : améliorer l’interface CSS permet de rendre les formulaires lisibles, accessibles et adaptés aux téléphones, tablettes et ordinateurs. Une interface claire peut afficher les erreurs à proximité des champs concernés, différencier les actions sensibles et réduire les erreurs de manipulation. Toutefois, masquer un bouton avec CSS n’empêche pas un utilisateur d’essayer d’appeler directement l’API correspondante. 9.3. JavaScript : améliorer les interactions JavaScript peut vérifier les champs avant l’envoi, afficher les messages d’erreur et actualiser l’interface. Il peut également aider à prévenir des soumissions accidentelles ou à confirmer une opération sensible. Mais le code JavaScript exécuté dans le navigateur est contrôlable par l’utilisateur. Il ne doit donc pas être la seule barrière de sécurité. Règle essentielle : le navigateur améliore l’expérience utilisateur ; le serveur fait respecter les règles de sécurité. 10. L’application de cette règle aux bibliothèques numériques Les bibliothèques numériques gèrent des ressources documentaires dont l’accès peut être public, réservé aux membres ou limité à certaines catégories de professionnels. La sécurité doit protéger les documents, mais aussi les métadonnées, les comptes, les historiques de consultation et les fonctions de gestion. 10.1. Gestion des collections Un documentaliste peut être autorisé à créer une collection. Cette permission ne signifie pas qu’il peut modifier toutes les collections existantes. Le système doit vérifier le périmètre de ses responsabilités et les règles de publication. 10.2. Protection des documents réservés Une page de présentation peut être publique tandis que le fichier intégral est réservé aux abonnés. Le contrôle doit être appliqué au téléchargement lui-même, et non uniquement à la page qui présente le document. Si le fichier possède une adresse directement accessible, l’application doit vérifier que les droits d’accès sont effectivement appliqués à cette ressource. 10.3. Traçabilité documentaire Pour certaines opérations sensibles, il est utile de conserver un journal indiquant qui a effectué une action, sur quelle ressource, à quel moment et avec quel résultat. Les journaux doivent toutefois respecter les règles de confidentialité. Ils ne doivent pas enregistrer les mots de passe, les jetons d’authentification ou des données personnelles inutiles. 11. L’intelligence artificielle et les nouveaux risques L’intégration de l’intelligence artificielle dans les systèmes documentaires introduit de nouveaux points d’entrée et de nouvelles opérations automatisées. Un agent d’IA peut rechercher des documents, résumer des publications, proposer des mots-clés ou déclencher des actions à travers des outils. Le fait qu’un agent soit authentifié ou qu’il dispose d’une clé d’API ne signifie pas qu’il doit pouvoir effectuer toutes les opérations disponibles. 11.1. Limiter les outils accessibles aux agents Un agent chargé de résumer des publications peut avoir besoin d’un droit de lecture. Il n’a pas nécessairement besoin d’un droit de suppression ou de modification des comptes. Chaque outil doit donc disposer de permissions adaptées à sa fonction. Les opérations sensibles peuvent exiger une confirmation humaine ou un mécanisme d’approbation distinct. 11.2. Traiter les documents comme des données non fiables Un document scientifique, une page web ou un fichier importé peut contenir des instructions malveillantes destinées à influencer un système d’IA. Le système ne doit pas traiter automatiquement le contenu d’un document comme une instruction de confiance. Il faut séparer les instructions de contrôle, les données documentaires et les actions que l’agent est autorisé à effectuer. Les résultats produits par le modèle doivent être vérifiés avant d’être utilisés pour modifier des données ou déclencher une opération importante. 11.3. Valider les actions de l’IA Supposons qu’un agent propose de supprimer des notices qu’il considère comme des doublons. La décision du modèle ne doit pas déclencher automatiquement une suppression irréversible. Une architecture plus sûre consiste à produire une liste de doublons présumés, vérifier les identifiants, appliquer des règles de correspondance, conserver une trace de la décision et demander une validation humaine avant la suppression lorsque le risque le justifie. L’intelligence artificielle peut assister le documentaliste ; elle ne doit pas contourner les contrôles de sécurité. 12. Les principales vulnérabilités à prévenir 12.1. Contrôle d’accès défaillant Un utilisateur peut accéder à une ressource qui ne relève pas de ses permissions. La prévention consiste à vérifier systématiquement les droits sur la ressource et l’action demandée. 12.2. Injection SQL Une requête construite en concaténant directement des données utilisateur peut permettre une manipulation de la requête SQL. Les requêtes paramétrées, les permissions minimales de la base de données et une gestion appropriée des erreurs réduisent ce risque. 12.3. Scripts intersites (XSS) Une donnée non fiable peut être interprétée comme du code dans le navigateur. L’encodage contextuel, les API DOM sûres et une politique de sécurité du contenu adaptée permettent de réduire le risque. 12.4. Falsification de requêtes intersites (CSRF) Dans certaines applications utilisant des cookies de session, un site externe peut tenter de provoquer une action involontaire au nom d’un utilisateur connecté. Les protections peuvent inclure des jetons CSRF, des paramètres de cookies appropriés et la vérification de l’origine lorsque cela est pertinent. 12.5. Modification de propriétés non autorisées Une requête peut envoyer des champs supplémentaires qui ne figurent pas dans le formulaire visible, par exemple un rôle administrateur ou un prix spécial. Le serveur doit définir explicitement les champs modifiables et ne jamais faire confiance à toutes les propriétés reçues. 12.6. Concurrence et incohérences Deux requêtes simultanées peuvent tenter de modifier la même ressource. Des transactions, des contrôles de version ou des mécanismes de verrouillage peuvent être nécessaires pour éviter des états incohérents. 13. Plan de mise en œuvre pour CIDOCFM Pour appliquer cette règle à une plateforme documentaire ou commerciale, un plan progressif peut être utilisé. Étape 1 : inventorier les ressources. Identifier les comptes, les publications, les fichiers numériques, les commandes, les abonnements et les paramètres administratifs. Étape 2 : définir les rôles. Établir les responsabilités des lecteurs, documentalistes, responsables éditoriaux et administrateurs. Étape 3 : documenter les permissions. Préciser les opérations autorisées pour chaque rôle et les restrictions applicables à chaque ressource. Étape 4 : vérifier les points d’entrée. Examiner les formulaires, les API, les téléchargements, les tâches automatisées et les interfaces d’administration. Étape 5 : valider les données côté serveur. Définir les formats, les limites, les champs obligatoires et les contraintes métier. Étape 6 : sécuriser les opérations sensibles. Protéger les paiements, les remboursements, les suppressions, les changements de rôle et les modifications de configuration. Étape 7 : journaliser les événements utiles. Enregistrer les opérations importantes sans exposer de secrets ni de données personnelles inutiles. Étape 8 : tester les refus. Vérifier qu’un lecteur ne peut pas modifier une notice protégée, qu’un utilisateur ne peut pas accéder à un document réservé sans autorisation et qu’une requête incorrecte est rejetée. Étape 9 : mettre à jour les composants. Maintenir à jour le CMS, les extensions, les dépendances et les mécanismes d’authentification. Étape 10 : réévaluer régulièrement les contrôles. Les nouvelles fonctionnalités et les intégrations d’IA doivent être incluses dans les tests de sécurité. Pour un site WordPress.com, certaines mesures dépendent des fonctions disponibles sur l’offre utilisée et des extensions installées. Il faut donc distinguer les réglages accessibles dans l’administration du site des modifications nécessitant un accès au serveur, qui n’est pas nécessairement disponible sur une plateforme hébergée. 14. Tests de sécurité : vérifier les refus autant que les succès Une application ne doit pas seulement être testée lorsque tout se déroule normalement. Elle doit également être testée lorsque les utilisateurs tentent des opérations interdites ou fournissent des données inattendues. Exemples de tests : - Un visiteur non connecté tente d’accéder à une fonction privée. - Un lecteur tente de modifier une notice. - Un documentaliste tente de modifier une ressource située hors de son périmètre. - Un utilisateur envoie une valeur négative pour un champ qui exige un nombre positif. - Une requête contient un champ que l’utilisateur n’est pas autorisé à modifier. - Une notification de paiement identique est reçue plusieurs fois. - Un fichier réservé est demandé directement sans passer par sa page de présentation. - Une opération échoue au milieu d’une transaction. Pour chaque test, il faut vérifier que le système refuse l’opération lorsque cela est nécessaire, qu’aucune modification partielle indésirable n’a lieu et que les journaux contiennent les informations utiles à l’analyse. Les tests doivent être réalisés dans un environnement autorisé, de préférence sur une plateforme de test ou une copie de développement. 15. Référentiels et ressources pour approfondir Plusieurs références reconnues permettent de structurer une démarche de sécurité applicative : - OWASP Application Security Verification Standard (ASVS) : référentiel de vérification des exigences de sécurité des applications. - OWASP Top 10 : présentation des principaux risques de sécurité des applications web. - OWASP Cheat Sheet Series : recommandations pratiques sur l’authentification, l’autorisation, la validation des entrées et d’autres mécanismes. - NIST Cybersecurity Framework : cadre de gestion des risques de cybersécurité. - NIST Digital Identity Guidelines : recommandations relatives à l’identité numérique et à l’authentification. - Documentation officielle de WordPress : informations sur les rôles, les capacités et les mécanismes de sécurité de WordPress. Ces ressources doivent être consultées dans leur version actuelle pour les projets professionnels, car les recommandations et les versions des référentiels évoluent. 16. Conclusion La sécurité d’une application ne peut pas reposer sur un seul contrôle. L’authentification confirme une identité, l’autorisation détermine les actions permises, la validation vérifie les données et les contrôles métier garantissent que les conséquences d’une opération restent conformes aux règles du système. Une requête ne doit donc jamais être considérée comme sûre uniquement parce qu’elle provient d’un utilisateur connecté ou qu’elle correspond à une permission générale. Pour CIDOCFM, cette approche contribue à protéger les collections documentaires, les comptes, les fichiers numériques, les commandes et les services d’intelligence artificielle. Elle favorise également la fiabilité des données scientifiques et la continuité des activités. La règle fondamentale peut être résumée ainsi : vérifier l’identité, contrôler les permissions, valider les données, examiner les conséquences et enregistrer les opérations sensibles de manière appropriée. Cette démarche permet de construire des applications plus robustes, plus prévisibles et mieux adaptées aux exigences de sécurité des environnements numériques modernes. FAQ — Questions fréquemment posées 1. Quelle est la différence entre authentification et autorisation ? L’authentification vérifie l’identité d’un utilisateur. L’autorisation détermine les ressources et les opérations auxquelles cet utilisateur peut accéder. 2. Un utilisateur connecté peut-il représenter un risque ? Oui. Un compte légitime peut être compromis, et un utilisateur authentifié peut tenter une opération interdite ou transmettre des données incorrectes. 3. Pourquoi la validation côté serveur est-elle indispensable ? Parce que les contrôles effectués dans le navigateur peuvent être modifiés ou contournés. Le serveur doit appliquer lui-même les règles de validation. 4. Le JavaScript peut-il sécuriser complètement un site web ? Non. JavaScript peut améliorer l’interface et détecter des erreurs de saisie, mais les décisions d’autorisation et les contrôles critiques doivent être appliqués côté serveur. 5. Comment protéger une bibliothèque numérique ? En définissant les rôles, en contrôlant les droits sur chaque ressource, en validant les métadonnées, en protégeant les téléchargements et en conservant des journaux adaptés pour les opérations sensibles. 6. L’intelligence artificielle peut-elle décider seule de supprimer des documents ? Pour une opération irréversible ou à fort impact, une décision automatique ne doit pas remplacer les contrôles de sécurité et les procédures de validation prévus par le système. Une approbation humaine peut être nécessaire. 7. Quel est le premier contrôle à mettre en place ? Il faut commencer par inventorier les ressources et les opérations sensibles, puis définir précisément les droits associés à chaque rôle. Ces règles doivent ensuite être appliquées et testées côté serveur. Bibliographie indicative 1. OWASP Foundation. Application Security Verification Standard (ASVS). Documentation officielle : https://owasp.org/www-project-application-security-verification-standard/ 2. OWASP Foundation. OWASP Top 10: Web Application Security Risks. Documentation officielle : https://owasp.org/www-project-top-ten/ 3. OWASP Foundation. Cheat Sheet Series. Documentation officielle : https://cheatsheetseries.owasp.org/ 4. National Institute of Standards and Technology (NIST). Cybersecurity Framework. Documentation officielle : https://www.nist.gov/cyberframework 5. National Institute of Standards and Technology (NIST). Digital Identity Guidelines, SP 800-63. Documentation officielle : https://pages.nist.gov/800-63-3/ 6. WordPress.org. Roles and Capabilities. Documentation officielle : https://wordpress.org/documentation/article/roles-and-capabilities/