Android FLAG_SECURE : bloquer les captures d'écran et l'enregistrement

De temps en temps, on tombe sur un flag Android qui ressemble un peu à de la magie. FLAG_SECURE en fait partie. Activez-le et soudain votre application devient « impossible à capturer » : la combinaison de touches habituelle ne fonctionne plus, les enregistrements d'écran deviennent mystérieusement noirs, et votre interface disparaît de l'aperçu des applications récentes. On dirait une sorte d'interrupteur DRM musclé.

Ce n'en est pas un. Sous le capot, FLAG_SECURE est en réalité très simple : c'est une façon de dire à Android « cette fenêtre précise est sensible, ne laisse pas capturer ses pixels ». C'est tout. Pas de chiffrement, pas de poignée de main secrète, juste une indication forte donnée au système sur la manière de traiter cette fenêtre quand quelqu'un essaie de récupérer ce qui s'affiche à l'écran.

Dans cet article, nous allons voir ce que fait concrètement FLAG_SECURE, comment il fonctionne conceptuellement, comment l'utiliser dans le code, dans quels cas il est pertinent de l'activer, quelques patterns pour l'utiliser sans agacer vos utilisateurs, et les limites que vous ne devez absolument pas ignorer.

1. Ce que fait réellement FLAG_SECURE

Commençons par ce que les gens voient réellement quand cette fonctionnalité est activée, car c'est généralement là que les questions commencent.

Quand vous définissez FLAG_SECURE sur une fenêtre (par exemple dans une Activity), Android cesse de traiter cette fenêtre comme une interface normale, capturable, et la marque à la place comme « à ne pas toucher » pour tout ce qui veut récupérer des pixels.

Le premier effet que vous remarquerez, c'est que les captures d'écran sont bloquées. Le raccourci système habituel (par exemple alimentation + volume bas) refuse de prendre une capture d'écran, ou produit une image totalement noire ou blanche tant que votre fenêtre sécurisée est au premier plan. Du point de vue de l'utilisateur, on a simplement l'impression que l'appareil refuse de capturer cet écran. En dessous, Android applique fidèlement la règle : la fenêtre est marquée sécurisée, donc les pixels ne sortent pas.

Ce n'est pas seulement la fonction de capture d'écran intégrée qui est désactivée. La plupart des applications tierces de capture d'écran sont logées à la même enseigne. Elles reposent elles aussi sur des mécanismes système pour capturer ce qui s'affiche à l'écran, et quand elles demandent les pixels appartenant à une fenêtre sécurisée, la plateforme leur remet beaucoup de rien du tout. Le résultat est généralement le même : une image noire ou blanche, ou un échec pur et simple. Mais gardez à l'esprit qu'utiliser un autre appareil photo pour prendre en photo l'écran fonctionne toujours.

Passons à l'enregistrement d'écran, l'histoire est similaire. Les enregistreurs d'écran affichent généralement une zone noire à la place du contenu de votre application à l'endroit où la fenêtre sécurisée est affichée. Vous obtenez toujours une vidéo, mais partout où votre fenêtre sécurisée apparaît dans l'image, il n'y a qu'un rectangle sombre. Certains enregistreurs peuvent encore afficher l'interface système ou d'autres fenêtres non sécurisées sur les bords, mais votre fenêtre reste masquée. C'est comme découper un trou dans l'enregistrement exactement là où se trouve votre contenu sensible.

Vient ensuite l'écran des applications récentes / Aperçu, celui que vous obtenez en balayant vers le haut ou en appuyant sur le bouton Récents. Normalement, Android prend un instantané de l'interface de votre application et l'utilise comme petite carte d'aperçu. Avec FLAG_SECURE activé, cet instantané est délibérément inutilisable. Dans l'écran système Aperçu / Applications récentes, Android n'affichera pas d'image de votre fenêtre sécurisée. En général, elle apparaît comme une couleur unie ou un rectangle noir, ce qui empêche des informations sensibles d'être visibles lorsque l'application est en arrière-plan ou lorsque quelqu'un fait défiler les applications ouvertes par-dessus votre épaule.

Et tout cela est délibérément limité en portée. FLAG_SECURE ne verrouille pas l'ensemble de l'appareil et n'affecte pas toutes les applications. Il s'applique uniquement à la fenêtre spécifique (Activity, Dialog, etc.) sur laquelle il est défini. Si vous ne définissez pas le flag sur une autre Activity, cet autre écran se comporte normalement : les captures d'écran fonctionnent, les enregistrements fonctionnent, l'aperçu des applications récentes affiche l'interface.

En résumé, FLAG_SECURE protège ce que l'utilisateur (ou une autre application) peut capturer visuellement depuis votre application via le propre pipeline d'affichage d'Android, mais il le fait fenêtre par fenêtre plutôt que comme un « mode confidentialité » global.

2. Comment fonctionne FLAG_SECURE sous le capot

Maintenant que nous avons couvert le comportement visible, parlons de ce qui se passe réellement sur le plan conceptuel.

La façon la plus simple de voir ce flag est de le considérer comme un interrupteur de confidentialité sur une fenêtre :

• Interrupteur activé → Android reçoit l'instruction : « ne jamais laisser les pixels de cette fenêtre sortir du pipeline d'affichage sécurisé sous une forme capturable ».
• Interrupteur désactivé → La fenêtre se comporte normalement ; les captures d'écran et les enregistrements sont autorisés.

Sous le capot, quand une fenêtre a FLAG_SECURE défini, le compositeur d'Android garde la trace du fait que cette fenêtre est « sécurisée ». Chaque fois que le système est sollicité pour capturer l'écran, que ce soit via l'API de capture d'écran, l'enregistrement d'écran, la génération de la miniature des tâches récentes, ou dans certains scénarios de casting/mirroring, il doit construire une image à partir de toutes les fenêtres visibles. Pour les fenêtres qui ne sont pas sécurisées, il copie volontiers leurs pixels dans la capture. Pour les fenêtres qui sont sécurisées, toute tentative de capturer l'écran exclut la fenêtre sécurisée ou la remplace par un espace réservé noir ou blanc.

L'important, c'est que cela est appliqué par le système, pas par la logique de votre application. Vous n'avez pas à intercepter les événements de capture d'écran ou à essayer de deviner quand un enregistreur est en cours d'exécution. Une fois le flag défini, c'est Android lui-même qui devient responsable de s'assurer que les pixels de cette fenêtre ne fuient pas dans les captures d'écran, les enregistrements ou les miniatures. Les autres applications qui essaient d'être malines et utilisent les API officielles pour capturer l'affichage restent soumises aux mêmes règles : elles demandent des pixels, le compositeur applique la politique de sécurité, et votre contenu n'apparaît pas.

C'est aussi pourquoi FLAG_SECURE est raisonnablement robuste face aux tentatives occasionnelles, voire modérément déterminées, de capturer votre interface par logiciel. Mais il est crucial de garder à l'esprit ce qu'il ne couvre pas : il contrôle uniquement la capture visuelle via le pipeline de rendu d'Android. Il ne protège pas comme par magie vos données en stockage, sur le réseau, ou ailleurs.

3. Comment utiliser FLAG_SECURE dans le code

La partie implémentation est la plus simple. Il n'y a pas d'API secrète, pas de permission spéciale, juste un flag sur la fenêtre.

Vous l'activez généralement dans une Activity pendant onCreate, avant ou autour du moment où vous appelez setContentView. En Java, cela ressemble à ceci :

Comment utiliser FLAG_SECURE en Java :

import android.os.Bundle;
import android.view.WindowManager;
import androidx.appcompat.app.AppCompatActivity;

public class SecureActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        getWindow().setFlags(
            WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE
        );

        setContentView(R.layout.activity_secure);
    }
}

Comment utiliser FLAG_SECURE en Kotlin :

import android.os.Bundle
import android.view.WindowManager
import androidx.appcompat.app.AppCompatActivity

class SecureActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        window.setFlags(
            WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE
        )

        setContentView(R.layout.activity_secure)
    }
}

C'est tout ce qu'il faut pour rendre la fenêtre de cette Activity sécurisée tant qu'elle est en vie.

Parfois, cependant, vous ne voulez pas que la fenêtre soit sécurisée en permanence. Peut-être qu'une partie de l'écran est sensible et une autre non, ou peut-être qu'il existe un mode particulier où vous voulez autoriser les captures d'écran. Dans ces cas, vous pouvez retirer FLAG_SECURE à l'exécution quand il n'est plus nécessaire :

Comment retirer FLAG_SECURE à l'exécution quand il n'est plus nécessaire, en Kotlin :

window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)

Comment retirer FLAG_SECURE à l'exécution quand il n'est plus nécessaire, en Java :

getWindow().clearFlags(WindowManager.LayoutParams.FLAG_SECURE);

Un détail important ici est que FLAG_SECURE s'applique par fenêtre, pas par application. La constante est :

WindowManager.LayoutParams.FLAG_SECURE

Il n'existe aucun paramètre de manifeste qui l'applique automatiquement à toute votre application. Vous devez le définir (ou le retirer) fenêtre par fenêtre :

• Chaque Activity que vous souhaitez protéger.
• Chaque Dialog ou fenêtre personnalisée qui doit être sécurisée.

C'est à la fois une fonctionnalité et un piège : vous obtenez un contrôle fin, mais vous devez aussi vous assurer que chaque surface sensible est couverte.

4. Cas d'usage courants pour FLAG_SECURE

Alors, où est-ce pertinent dans le monde réel ? La réponse courte est : partout où vous affichez des informations que vous ne voulez vraiment pas voir atterrir sans réfléchir dans l'archive de captures d'écran, la sauvegarde cloud ou l'historique de discussion de quelqu'un.

Parcourons quelques catégories courantes.

4.1 Applications bancaires et financières

Les applications bancaires et financières en sont ici l'exemple évident. Les écrans qui affichent des soldes de compte, des relevés bancaires, des historiques de transactions, des numéros de carte ou des mots de passe à usage unique (OTP) contiennent des données à la fois sensibles et hautement réexploitables si elles tombent entre de mauvaises mains. Si ces vues autorisent sans problème les captures d'écran, ces informations peuvent se retrouver dans la galerie photo de l'utilisateur, synchronisées sur un stockage cloud, ou transférées dans une application de messagerie, généralement sans aucun chiffrement ni contrôle d'accès.

En activant FLAG_SECURE sur ces écrans financiers, vous mettez un frein basique devant cette voie de fuite. Cela n'empêche pas quelqu'un de déterminé à photographier l'écran avec un autre appareil, mais cela évite beaucoup de moments « je vais juste faire une petite capture d'écran rapide de ça » qui finissent par poser problème plus tard.

4.2 Applications d'authentification et de sécurité

Si vous développez quoi que ce soit lié à l'authentification ou aux secrets, gestionnaires de mots de passe, générateurs 2FA / OTP, flux de vérification d'identité, FLAG_SECURE devrait figurer en bonne place sur votre radar.

Ces applications affichent régulièrement des secrets à haute valeur : mots de passe, clés de récupération, codes de secours, codes de connexion de courte durée, etc. Si les utilisateurs peuvent capturer ces écrans, ces données ont tendance à finir exactement là où vous ne voulez pas qu'elles soient : pellicules, galeries cloud, et applications de prise de notes diverses. À partir de là, il n'en faut pas beaucoup pour qu'elles fuitent davantage.

Appliquer FLAG_SECURE aux parties de votre application qui révèlent ces secrets signifie qu'ils ne peuvent pas être capturés trivialement via l'OS. Les utilisateurs doivent faire une démarche plus délibérée, comme les noter ou utiliser un autre appareil photo, s'ils veulent les conserver. Cela ne résout pas tous les problèmes, mais cela réduit drastiquement l'exposition accidentelle que l'on observe quand les captures d'écran sont autorisées partout.

4.3 Applications de santé et médicales

Les applications de santé et médicales se trouvent dans une catégorie particulière où les données sont incroyablement personnelles et, dans de nombreuses juridictions, strictement réglementées.

Les écrans qui affichent des dossiers médicaux personnels, des résultats d'analyses, des diagnostics, des détails de traitement ou des notes de consultation détaillées ne sont pas seulement « un peu privés » ; ils sont souvent soumis à des lois de confidentialité strictes. Si ces vues peuvent être capturées en image ou en vidéo puis automatiquement sauvegardées ou partagées, vous avez créé un chemin facile pour que des données très sensibles sortent du contrôle de votre application.

Utiliser FLAG_SECURE sur ces vues aide à réduire ce risque. Cela ne remplace pas un chiffrement adéquat, des contrôles d'accès et un travail de conformité, mais cela s'attaque à un problème très concret : des personnes qui font une capture d'écran rapide de leurs résultats et poussent sans le savoir ces images dans des environnements jamais conçus pour la confidentialité médicale.

4.4 Outils d'entreprise et internes

Au sein des organisations, on trouve souvent des tableaux de bord internes, des panneaux d'administration et des outils de débogage qui exposent toutes sortes d'informations que personne ne veut voir sur Twitter. Pensez : métriques internes, données clients, chronologies d'incidents, écrans de configuration, ou vues de logs parsemées d'identifiants et de secrets.

Dans ces environnements, les employés qui prennent des captures d'écran et les partagent en interne peuvent être parfaitement normaux, jusqu'à ce que l'une de ces captures fuite hors de l'organisation ou se retrouve à un endroit où elle ne devrait absolument pas être. Les outils de débogage utilisés contre des systèmes de production sont particulièrement risqués, car ils affichent souvent des données brutes qui n'étaient jamais censées être visibles par les clients.

Activer FLAG_SECURE sur les écrans d'administration particulièrement sensibles et les outils internes est une manière pragmatique de limiter le rayon d'impact de ce type de comportement. Les gens peuvent toujours documenter ce qu'ils font, mais vous ne rendez plus aussi facile la capture et la diffusion de copies pixel perfect de vos interfaces internes les plus sensibles.

4.5 Communication critique pour la confidentialité et scénarios de borne interactive

Il existe aussi toute une classe d'applications où la sensibilité tient davantage à la manière dont les gens les utilisent qu'au domaine spécifique. La messagerie sécurisée, les discussions éphémères et les messages autodestructeurs en sont de bons exemples.

Si vous annoncez que « ce message disparaît », mais que l'interface est trivialement capturable, l'expérience et l'attente ne sont pas alignées. Vous ne pouvez pas empêcher quelqu'un de pointer un autre téléphone vers l'écran, mais vous pouvez au moins éviter de cautionner le chemin de capture facile et intégré. Marquer ces conversations spéciales avec FLAG_SECURE envoie un signal assez clair : ceci n'est pas censé vivre éternellement dans votre galerie photo.

Les applications de type borne interactive constituent un autre cas intéressant. Pensez aux bornes d'enregistrement, aux systèmes de file d'attente, aux formulaires en libre-service, ou à tout appareil partagé sur lequel les gens viennent interagir dans des espaces semi-publics. Souvent, ces écrans afficheront brièvement des noms, des identifiants, des détails de réservation, ou d'autres données personnelles. En activant FLAG_SECURE sur ces flux, vous rendez beaucoup plus difficile pour des utilisateurs opportunistes, ou un logiciel malveillant s'exécutant sur l'appareil, de collecter discrètement ce qui s'affiche à l'écran.

5. Patterns de conception : où et quand activer

Parsemer FLAG_SECURE au hasard dans votre application n'est pas une stratégie. Vous voulez des patterns délibérés qui équilibrent sécurité et facilité d'usage.

Un pattern simple est l'Activity « toujours sécurisée ». Pour certains écrans, tout ce qu'ils affichent jamais est sensible. Les exemples classiques sont quelque chose comme OtpVerificationActivity ou CardDetailsActivity. Dans ces cas, vous pouvez simplement définir FLAG_SECURE dans onCreate et ne jamais le retirer. Chaque fois que l'utilisateur atterrit sur cette Activity, les captures d'écran et les enregistrements sont exclus, point final.

Un pattern plus nuancé est le basculement basé sur l'état. Imaginez une seule MainActivity qui affiche normalement du contenu inoffensif, mais qui révèle parfois un panneau « Détails sensibles », une feuille en bas d'écran avec les numéros de compte complets, par exemple. Tant que ce panneau est caché, il n'y a aucune raison de bloquer les captures d'écran. Dès que vous l'affichez, vous activez le flag ; quand il est fermé, vous désactivez de nouveau le flag. En Kotlin, cela pourrait ressembler à ceci :

fun showSensitiveContent() {
    window.setFlags(
        WindowManager.LayoutParams.FLAG_SECURE,
        WindowManager.LayoutParams.FLAG_SECURE
    )
    // Show a fragment or view containing sensitive data
}

fun hideSensitiveContent() {
    window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)
    // Hide that fragment or view
}

Ce pattern vous donne le meilleur des deux mondes : les gens peuvent toujours capturer l'interface générique, mais les moments vraiment sensibles sont protégés.

Il y a ensuite l'approche du contenu sécurisé uniquement dans la boîte de dialogue. Parfois, la seule partie sensible de tout le flux est une boîte de dialogue transitoire, disons une pop-up révélant un numéro de carte complet, une phrase de récupération, ou un secret à usage unique. Dans ces cas, il peut être pertinent de définir FLAG_SECURE sur la fenêtre propre de la boîte de dialogue plutôt que sur l'ensemble de l'Activity. L'écran de base reste capturable, mais le contenu de la boîte de dialogue n'apparaît jamais dans les captures.

Quel que soit le pattern choisi, l'essentiel est d'être cohérent : définissez quels écrans ou états sont considérés comme sensibles, appliquez FLAG_SECURE à ceux-là, et laissez le reste tranquille. Ainsi, vous ne surprenez pas les utilisateurs au hasard, et vous ciblez le flag exactement là où il vous apporte la plus grande réduction de risque.

6. Limites et idées reçues

Place maintenant à la partie tout aussi importante que les fonctionnalités : ce que FLAG_SECURE ne fait pas.

Le point majeur : il ne bloque ni les appareils photo ni les appareils externes. Un utilisateur peut toujours pointer un autre téléphone, un reflex, une webcam, ou autre chose vers l'écran et le capturer. FLAG_SECURE contrôle uniquement la capture logicielle à l'intérieur d'Android. Si votre modèle de menace inclut quelqu'un physiquement présent prenant des photos de l'appareil, ce flag ne vous aide pas.

Ensuite, FLAG_SECURE ne chiffre ni ne sécurise autrement vos données. Il protège l'affichage visuel, pas :

• Les communications réseau
• Le stockage sur disque
• Les logs, caches ou sauvegardes

Si vous envoyez des données sensibles sur le réseau, vous avez toujours besoin de HTTPS (et vous devez toujours valider correctement les certificats). Si vous stockez des secrets sur disque, vous avez toujours besoin de mécanismes de chiffrement comme des bases de données chiffrées ou EncryptedSharedPreferences. Si vous journalisez des valeurs sensibles, FLAG_SECURE ne vous sauvera pas quand ces logs sont expédiés vers un serveur central.

Il y a aussi le problème de portée. Comme le flag est par fenêtre et non global, il est très facile de sécuriser un chemin et d'en oublier un autre. Si vos données sensibles sont aussi accessibles depuis une autre Activity ou vue qui ne définit pas FLAG_SECURE, cet autre écran peut toujours être capturé. Vous devez raisonner en termes de « chaque endroit où cette information apparaît » plutôt que « cet écran-là ».

Autre point subtil : FLAG_SECURE ne protège pas rétroactivement les captures antérieures. Les captures d'écran ou enregistrements réalisés avant que vous n'activiez le flag ne sont pas affectés. Ils restent là où l'utilisateur les a stockés, galerie locale, sauvegarde cloud, application de messagerie. Le flag s'applique uniquement aux tentatives de capture pendant qu'il est actif.

Enfin, il y a des compromis en matière d'expérience utilisateur. Certains utilisateurs s'appuient beaucoup sur les captures d'écran pour signaler des bugs, enregistrer des instructions ou documenter des processus. Quand vous bloquez les captures d'écran à des endroits qu'ils ne perçoivent pas comme particulièrement sensibles, vous allez les frustrer. Un usage excessif de FLAG_SECURE peut donner aux gens l'impression que votre application est verrouillée sans nécessité, surtout si vous ne communiquez pas clairement pourquoi une capture d'écran n'est pas autorisée.

À retenir : FLAG_SECURE est un outil ciblé qui répond très bien à un problème spécifique. Ce n'est pas une solution miracle. Vous avez toujours besoin d'une véritable conception de sécurité autour de lui.

7. Interactions avec le casting et les écrans externes

Un dernier détail qui surprend souvent les gens : comment FLAG_SECURE se comporte quand vous diffusez ou dupliquez l'écran.

Selon la version d'Android et l'appareil, le contenu marqué avec FLAG_SECURE peut ne pas apparaître du tout sur certains écrans externes. Si le système considère l'écran externe comme « non sécurisé » (par exemple certaines cibles de cast ou écrans dupliqués), il applique essentiellement la même logique que pour les captures d'écran et les enregistrements.

En pratique, cela signifie que pendant les sessions de duplication ou de casting d'écran :

• Les fenêtres sécurisées peuvent apparaître comme une zone blanche ou noire sur l'écran distant.
• L'interface non sécurisée et l'habillage système peuvent rester visibles.
• Votre application peut sembler « manquer » des parties de son interface sur la sortie diffusée chaque fois qu'une fenêtre sécurisée est au premier plan.

Ce comportement correspond à la formulation que l'on trouve parfois dans la documentation : « Empêche le contenu de la fenêtre d'apparaître dans les captures d'écran ou d'être visible sur des écrans non sécurisés. » « Écrans non sécurisés » est ici un raccourci pour désigner les sorties auxquelles Android ne fait pas entièrement confiance pour appliquer les mêmes garanties qu'il peut appliquer sur l'écran principal de l'appareil.

Si votre application est beaucoup utilisée lors de présentations, de démonstrations ou de scénarios d'assistance à distance, il vaut la peine de tester comment vos écrans sécurisés se comportent pendant le casting et de décider si c'est acceptable. Dans certains cas, vous pourriez avoir besoin de flux alternatifs pour ces situations, ou au moins d'un message convivial expliquant pourquoi l'écran ne peut pas être partagé.

8. Résumé

FLAG_SECURE (WindowManager.LayoutParams.FLAG_SECURE) est un flag de fenêtre Android qui indique « ne laisse pas capturer les pixels de cette fenêtre ». Une fois défini sur une fenêtre, il empêche les captures d'écran classiques de fonctionner, fait apparaître du noir dans les enregistrements d'écran là où cette fenêtre s'affiche, masque les miniatures significatives dans la vue des applications récentes, et peut même empêcher le contenu d'apparaître sur certains écrans externes.

Vous l'utilisez en définissant le flag sur les fenêtres qui comptent, généralement des Activities ou des Dialogs spécifiques, et, si nécessaire, en le retirant de nouveau quand l'interface n'affiche plus de données sensibles :

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

// Later, if needed:
window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)

Vous devriez l'envisager sur les écrans qui affichent des informations véritablement sensibles ou réglementées : détails bancaires, secrets d'authentification, données de santé, tableaux de bord internes, discussions critiques pour la confidentialité, flux de bornes interactives, et cas similaires. Mais vous devez aussi être très clair sur ce qu'il ne fait pas : il n'arrête pas les appareils photo, ne chiffre rien, ne s'applique pas globalement sauf si vous le faites vous-même, et ne nettoie pas les captures d'écran passées.

Utilisé avec discernement, FLAG_SECURE est un moyen très pratique de fermer une fuite spécifique et très courante : des pixels qui sortent de votre application via des captures d'écran et des enregistrements d'écran. Ce n'est pas toute l'histoire de la sécurité sur Android, mais pour les bons écrans, c'est une histoire que vous voulez absolument raconter.