Feature flags et cybersécurité : les décisions à cadrer avant l’activation

Un feature flag permet d’activer ou de désactiver un comportement logiciel sans redéployer toute l’application. Cette souplesse est utile pour livrer progressivement, tester un parcours ou préparer un retour arrière. Elle devient toutefois un sujet de cybersécurité dès qu’une bascule modifie un droit, une règle d’authentification, un traitement de données ou une action sensible.

Le risque ne vient pas du mécanisme lui-même. Il apparaît lorsque l’équipe traite le flag comme un simple paramètre d’interface alors qu’il agit sur une décision de sécurité. Une bascule visible dans le navigateur ne doit jamais remplacer le contrôle d’autorisation du serveur.

Les recommandations de l’OWASP Web Security Testing Guide invitent notamment à vérifier les états activé, désactivé, partiellement déployé, restauré et indisponible.

1. Décrire la décision avant de nommer le flag

Le premier livrable ne devrait pas être une clé technique comme new_access_v2. Il doit décrire la décision métier et le risque associé. Par exemple : « autoriser la validation d’un avoir par les responsables de secteur pendant une phase pilote ». Cette formulation permet de distinguer le périmètre fonctionnel du mécanisme de bascule.

Le cadrage doit préciser cinq éléments :

• l’action ou le comportement réellement modifié ;
• les utilisateurs, équipes ou comptes techniques concernés ;
• les données accessibles ou produites lorsque le flag est actif ;
• la conséquence attendue lorsque le flag est désactivé ;
• le propriétaire qui peut demander, approuver et retirer l’activation.

Un flag qui masque seulement un bouton n’a pas le même niveau d’exigence qu’un flag qui ouvre une API d’administration, désactive une vérification complémentaire ou autorise l’export d’un fichier sensible. Cette différence doit apparaître dans le cahier de cadrage et dans le devis de la prestation.

2. Séparer visibilité et autorisation

La règle la plus importante est simple : l’interface peut adapter ce qu’elle affiche, mais elle ne doit pas décider seule de ce que l’utilisateur a le droit de faire. L’OWASP Authorization Cheat Sheet recommande une vérification des permissions à chaque requête et rappelle qu’un contrôle côté client ne peut pas constituer la décision de sécurité.

Pour chaque feature flag sensible, le prestataire doit donc montrer où le contrôle est appliqué :

• dans l’interface, pour guider l’utilisateur sans créer de fausse promesse ;
• dans l’API ou le service métier, pour refuser réellement l’action non autorisée ;
• dans les traitements différés, files de messages ou tâches planifiées qui pourraient contourner l’écran ;
• dans les accès aux données, lorsque le flag change le périmètre d’une recherche, d’un export ou d’une modification.

La recette doit tenter l’action directement, y compris lorsque le flag est désactivé pour l’utilisateur concerné. Le résultat attendu n’est pas seulement l’absence du bouton : c’est un refus explicite et journalisé au niveau du service qui porte l’action.

3. Cadrer les états intermédiaires et le retour arrière

Une activation progressive crée plusieurs états possibles : aucun utilisateur, un groupe pilote, plusieurs instances applicatives ou l’ensemble du périmètre. Le cadrage doit dire ce qui se passe lorsqu’une requête passe d’une instance où le flag est actif à une autre où il ne l’est pas encore.

Le retour arrière mérite la même précision. Restaurer le code sans restaurer la configuration de sécurité peut laisser une ancienne version avec une règle incohérente. L’OWASP signale aussi le risque de conserver une assertion, un jeton ou un état de session devenu indûment fiable après la désactivation d’un contrôle.

Demandez un scénario de test qui couvre au minimum :

1. l’activation pour un périmètre réduit ;
2. la désactivation immédiate ;
3. le redémarrage d’un service pendant la bascule ;
4. le retour à la version précédente ;
5. la réutilisation d’une session ou d’une requête créée avant le changement ;
6. l’incohérence temporaire entre plusieurs services.

4. Prévoir un comportement sûr en cas d’indisponibilité

Un service de gestion des flags peut être indisponible, lent ou inaccessible depuis une partie du système d’information. Le comportement par défaut doit être défini avant le projet, et non choisi dans l’urgence par l’équipe de développement.

Pour un contrôle de sécurité, la question à trancher est la suivante : l’application refuse-t-elle l’action, conserve-t-elle le dernier état vérifié ou bascule-t-elle vers une configuration documentée ? Une réponse acceptable dépend du contexte métier, mais elle doit être explicite, testée et observable. Une désactivation accidentelle d’une vérification ne doit pas ouvrir silencieusement un accès privilégié.

Le livrable attendu comprend une matrice des états de panne : service de flags indisponible, réponse incomplète, configuration illisible, cache expiré et divergence entre régions ou instances. L’OWASP Developer Guide recommande notamment un refus sécurisé lorsque la configuration nécessaire au contrôle d’accès n’est pas disponible.

5. Relier le flag aux droits applicatifs

Un feature flag sensible doit être rapproché du modèle de droits, sans devenir un nouveau système d’habilitation opaque. Le rôle applicatif indique qui peut réaliser une action ; le flag indique éventuellement dans quel état du produit cette action est disponible. Les deux décisions doivent rester compréhensibles séparément.

Avant la recette, cadrer les droits applicatifs avant la recette permet de clarifier les rôles, les profils sensibles et les responsabilités de validation. Pour le flag lui-même, ajoutez les champs suivants au registre :

6. Définir les traces sans journaliser inutilement

La traçabilité doit permettre de reconstruire la décision sans copier des données sensibles dans les logs. Il faut au moins conserver l’identité de l’acteur ayant modifié la configuration, l’ancien et le nouvel état, le périmètre visé, la raison du changement, la version applicative associée et le résultat observé.

Le journal doit aussi distinguer une modification de configuration d’une décision d’autorisation. Une activation ne prouve pas qu’un utilisateur avait le droit d’effectuer une action ; elle prouve seulement qu’une règle de disponibilité a changé. Cette séparation évite de transformer le log du flag en preuve excessive.

7. Demander une prestation vérifiable

Un cadrage de feature flags ne doit pas se limiter à une promesse de « déploiement progressif sécurisé ». Dans une consultation ou un devis, demandez des livrables précis :

• un inventaire des flags qui touchent à l’authentification, aux droits, aux données ou aux contrôles de risque ;
• un schéma des points d’évaluation et des points d’autorisation ;
• une matrice des états activé, désactivé, partiel, restauré et indisponible ;
• des scénarios de recette négatifs, notamment l’appel direct de l’API ;
• un modèle de journal d’activation et de décision ;
• une procédure de retrait du flag et du code devenu inutile ;
• un responsable désigné pour l’approbation et l’expiration de chaque bascule.

Le bon critère de choix n’est donc pas le nombre de fonctionnalités proposées par l’outil de feature management. C’est la capacité de la solution et du prestataire à rendre les décisions visibles, à empêcher les contournements et à prouver le comportement du système dans les états normaux comme dans les états dégradés.

La décision à prendre

Si le flag ne modifie qu’une présentation sans effet sur les données ni les actions, un cadrage léger peut suffire. S’il touche à un droit, une authentification, un export, une validation ou un traitement automatique, traitez-le comme une décision de sécurité temporaire. Le projet doit alors prévoir un propriétaire, une règle d’autorisation indépendante de l’interface, un comportement sûr en cas de panne, des tests de transition et une date de retrait.

Cette approche ne supprime pas le risque. Elle évite surtout de confondre livraison progressive et contrôle d’accès, deux sujets qui peuvent partager un mécanisme mais pas les mêmes responsabilités.

Question de la rédaction : comment cadrez-vous les feature flags qui modifient des droits ou des traitements sensibles ?