Désérialisation non sûre

Désérialisation non sûre : Reconstruction d’objets à partir de données reçues, susceptible de déclencher un comportement non prévu si l’entrée n’est pas contrôlée.

Le mot appartient à la famille « Sécurité » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.

Pourquoi Désérialisation non sûre compte sur un projet mobile

Désérialisation non sûre protège les données confiées par les utilisateurs. Sur mobile, la question se pose deux fois : sur le téléphone, qui peut être perdu ou compromis, et sur le serveur.

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

Ce que ça devient dans un cahier des charges

Un cahier des charges sérieux relie « Désérialisation non sûre » aux données concernées. Toutes ne méritent pas le même niveau de protection, et tout protéger au maximum coûte cher sans rien garantir de plus.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le référentiel de sécurité appliqué, nommé dans le contrat.
• Le classement des données manipulées, de la plus banale à la plus sensible.
• La revue de sécurité prévue avant la mise en ligne, et qui la mène.
• La procédure de correction d’une faille signalée, avec son délai d’engagement.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Vérifier plutôt que croire

À la recette, Désérialisation non sûre se contrôle sur pièces : configuration, journaux, preuve de test. Pas sur une déclaration de bonne intention.

• Demander le rapport d’audit complet, pas la seule page de synthèse.
• Vérifier que les correctifs annoncés ont été retestés, et par qui.
• Vérifier que les contrôles d’accès sont bien refaits côté serveur.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Erreurs fréquentes

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Traiter la sécurité en fin de projet, quand tout est déjà recetté.
• Stocker un secret dans le code de l’application, où il est lisible par qui veut le lire.
• Commander un audit sans budgéter les corrections qu’il va produire.
• Laisser les accès de production ouverts à d’anciens intervenants.
• Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Point de terminaison non documenté
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité

Questions fréquentes

Qu’est-ce que « Désérialisation non sûre » ?

Reconstruction d’objets à partir de données reçues, susceptible de déclencher un comportement non prévu si l’entrée n’est pas contrôlée. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Faut-il un audit de sécurité sur toutes les applications ?

Pas au même niveau. Une application sans compte ni donnée personnelle n’appelle pas l’effort d’un service bancaire. Le classement des données manipulées donne la mesure du travail à prévoir.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.