PostHog est-il sûr ?
Analyse de sécurité des apps créées avec PostHog. Analytics produit open source avec enregistrement de sessions, feature flags et tests A/B.
PostHog est-il sûr ? La réponse courte
PostHog est une plateforme d'analytics produit reconnue, et son snippet JavaScript est conçu pour tourner dans le navigateur. Avoir PostHog dans votre front-end n'est pas une faille en soi : la clé de projet qu'il utilise permet seulement d'envoyer des événements, pas de lire vos données.
Le vrai risque avec PostHog relève de la confidentialité plus que de l'intrusion. L'analytics et le session replay peuvent collecter discrètement bien plus que prévu : e-mails, jetons dans les URL, contenu de formulaires, données de santé ou de paiement affichées à l'écran. Et si une clé API personnelle se retrouve côté client, n'importe qui peut interroger tout ce que PostHog a collecté. Sécuriser PostHog, c'est décider quelle clé va où et quelles données vous capturez.
Scannez votre app PostHog maintenant
Saisissez votre URL et obtenez un rapport de sécurité complet en 30 secondes. Gratuit, sans inscription.
Scanner mon app PostHogLes erreurs de configuration PostHog fréquentes dans les apps créées avec l'IA
Une clé API personnelle dans le front-end
La clé API de projet (phc_…) est publique par conception : elle ne sert qu'à envoyer des données. Les clés API personnelles (phx_…) permettent de lire vos données d'analytics, vos personnes et vos enregistrements via l'API. Elles n'ont leur place que sur un serveur ou dans un secret de CI, avec les permissions les plus restreintes possibles.
Des données personnelles envoyées dans les événements
Le code généré par IA appelle souvent identify avec des profils complets, ou ajoute e-mails, noms et adresses à chaque événement. L'autocapture et $current_url peuvent aussi enregistrer les jetons de réinitialisation de mot de passe ou de lien magique présents dans les URL. Envoyez des identifiants stables plutôt que des données personnelles, et sortez les secrets des URL.
Des replays de session qui montrent des écrans sensibles
Le session replay masque les champs de saisie par défaut, mais le texte affiché sur la page (données de compte, messages, informations médicales ou financières) peut être enregistré si vous ne le masquez pas. Désactiver le masquage pour déboguer et oublier de le réactiver est une erreur classique.
Des feature flags utilisés comme contrôle d'accès
Les flags évalués dans le navigateur peuvent être lus et modifiés par l'utilisateur. Cacher une fonctionnalité premium ou d'administration derrière un flag côté client n'est pas un contrôle de sécurité : vérifiez les permissions côté serveur.
Checklist de sécurité PostHog
- Cherchez
phx_dans votre bundle ; si une clé personnelle a fuité, révoquez-la dans les paramètres PostHog et créez une clé de remplacement aux droits limités. - Envoyez des identifiants utilisateur, pas des e-mails ou des noms, et vérifiez les propriétés collectées par l'autocapture.
- Laissez le masquage des champs activé, masquez le texte sensible avec un sélecteur et ajoutez la classe
ph-no-captureaux éléments qui ne doivent jamais être enregistrés. - Retirez les jetons des URL avant qu'ils n'atteignent l'analytics, ou évitez tout simplement de les y mettre.
- Choisissez la région PostHog (US ou UE) adaptée à vos obligations de confidentialité et mentionnez-la dans votre politique de confidentialité.
posthog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY!, { // clé de projet phc_ : publique par conception
api_host: "https://eu.i.posthog.com",
session_recording: {
maskAllInputs: true, // champs de saisie masqués
maskTextSelector: "[data-private]", // masque aussi le texte sensible
},
});
// N'envoyez jamais une clé personnelle phx_ au navigateur.Failles de sécurité fréquentes dans les apps PostHog
Clés API exposées
Les outils de code IA intègrent souvent les clés API directement dans le JavaScript côté client. Si vous utilisez PostHog, vérifiez qu'aucune clé secrète ne se trouve dans votre bundle front-end.
En-têtes de sécurité manquants
Des en-têtes comme Content-Security-Policy, Strict-Transport-Security et X-Frame-Options protègent contre les attaques XSS, le clickjacking et les attaques par rétrogradation (downgrade).
Dépendances vulnérables
Les paquets npm obsolètes présentant des CVE connues sont fréquents dans le code généré par IA. Des audits réguliers permettent de les repérer avant les attaquants.
Faiblesses d'authentification
Endpoints d'inscription ouverts, absence de limitation de débit (rate limiting) et jetons d'authentification exposés sont des problèmes fréquents dans les apps développées en vibe coding.
Ce que ScanVibe vérifie
Questions fréquentes
PostHog est-il sûr à utiliser ?
PostHog est en soi une plateforme reconnue, mais les apps créées avec PostHog présentent souvent des erreurs de configuration de sécurité : clés API exposées, en-têtes de sécurité manquants et dépendances vulnérables. ScanVibe analyse votre app pour détecter ces problèmes.
Quelles failles de sécurité trouve-t-on souvent dans les apps PostHog ?
Les problèmes les plus fréquents que nous détectons dans les apps PostHog sont : des clés API exposées dans le JavaScript côté client, des en-têtes de sécurité manquants (CSP, HSTS), des dépendances obsolètes présentant des vulnérabilités connues et des endpoints d'authentification mal configurés.
Comment vérifier si mon app PostHog est sécurisée ?
Saisissez l'URL de votre app dans le scanner ScanVibe. Nous vérifions les secrets exposés, les en-têtes de sécurité, les bibliothèques vulnérables, les fichiers exposés et les erreurs de configuration propres à chaque plateforme, le tout en 30 secondes environ.
ScanVibe analyse-t-il spécifiquement PostHog ?
Oui. ScanVibe détecte PostHog dans votre stack et exécute des contrôles de sécurité propres à cette plateforme, en plus de notre analyse standard en 8 catégories.
La clé API de projet PostHog est-elle un secret ?
Non. La clé API de projet (qui commence par phc_) est faite pour être publique : elle se trouve dans votre front-end et ne peut qu'envoyer des événements. Les clés API personnelles (qui commencent par phx_) sont des secrets, car elles permettent de lire vos données via l'API PostHog ; gardez-les côté serveur et révoquez celles qui ont fuité.
Le session replay de PostHog enregistre-t-il les mots de passe et les données personnelles ?
Les champs de saisie sont masqués par défaut : les mots de passe tapés ne sont donc pas enregistrés, sauf si vous désactivez le masquage. Le texte affiché sur la page, en revanche, peut l'être : utilisez des sélecteurs de masquage ou la classe ph-no-capture sur les zones sensibles, et évitez d'envoyer des données personnelles comme propriétés d'événements.
Autres outils d'analytics à vérifier
Ne devinez pas : scannez.
Détectez les failles de sécurité de votre app PostHog avant les attaquants.
Scanner mon app