GeckoFlag est un logiciel qui fonctionne sur votre propre serveur. Pour que vous puissiez lui confier en toute confiance les informations de vos projets, le développeur effectue lui-même des contrôles de sécurité à chaque version et en publie le contenu et les résultats sur cette page.
Cette page rend compte des contrôles effectués par le développeur lui-mêmeIl ne s'agit pas d'une certification ni d'un audit réalisés par un organisme tiers. Comme nous publions également ce qui est contrôlé, servez-vous-en comme élément d'appréciation avant d'adopter GeckoFlag.
- Mesures de conception
- Contrôles à chaque version
- Résultats de la dernière version
- Ce qui n'est pas contrôlé
- Signaler une vulnérabilité
- Vérifier les fichiers distribués
- Paramètres recommandés
Mesures de sécurité intégrées à la conception
GeckoFlag intègre par défaut les mesures suivantes. Toutes sont actives sans aucune configuration.
Protection des mots de passe
Les mots de passe ne sont jamais stockés en clair : ils sont hachés avec bcrypt. Les jetons de réinitialisation du mot de passe sont eux aussi stockés sous forme hachée, et le nombre de demandes de réinitialisation est limité.
Limitation des tentatives de connexion
Les échecs de connexion sont comptés à la fois par compte et par adresse IP de connexion ; au-delà d'un certain nombre, la connexion est temporairement bloquée. Cela freine les attaques par force brute et les attaques visant de nombreux comptes.
Protection contre le CSRF
Un jeton est vérifié à chaque envoi de formulaire, ce qui empêche des sites externes d'effectuer des opérations à votre place.
Protection contre le XSS
Le texte enrichi des tickets, commentaires, pages Wiki, notes, etc. est enregistré et affiché après passage dans HTML Purifier, qui ne conserve que les balises autorisées. Seuls les liens http et https sont autorisés. Les textes générés par l'IA passent tous par le même traitement avant d'être enregistrés.
Protection contre l'injection SQL
Les opérations sur la base de données passent par l'ORM de CakePHP 5 et des requêtes préparées.
Vérification de l'en-tête Host
Les liens insérés dans les e-mails de réinitialisation du mot de passe, d'invitation et de notification sont construits à partir du domaine enregistré, et non de l'en-tête Host de la requête. Un en-tête Host falsifié ne permet donc pas de remplacer les liens des e-mails par une adresse externe.
Stockage des fichiers
Les images des tickets et les fichiers des projets sont stockés hors du dossier public et ne sont servis qu'après avoir vérifié que la personne qui les consulte est membre du projet. Les fichiers portant une extension exécutable, comme PHP, sont refusés.
Chiffrement de la clé API
La clé API Claude utilisée par les fonctions d'IA est chiffrée avant d'être enregistrée dans la base de données.
Jetons d’API de l’intégration Claude
L’intégration Claude est désactivée par défaut et ne peut être utilisée que si un administrateur l’active et l’autorise pour chaque utilisateur. Seule une empreinte (hash) de chaque jeton d’API est enregistrée, et une date d’expiration peut être fixée. Changer le mot de passe rend les jetons invalides. L’API vérifie les mêmes droits que les écrans, et un jeton en lecture seule ne peut rien modifier.
Restriction par adresse IP
Les administrateurs peuvent limiter les adresses IP autorisées à accéder à l'application.
Fermeture de l'installateur
Une fois l'installation terminée, l'écran de l'installateur n'est plus accessible.
Protection des dossiers privés
Avec Apache, l'accès direct aux dossiers de configuration, de journaux, de code source, etc. est bloqué par défaut (pour Nginx, voir les paramètres recommandés).
Sauvegarde automatique avant mise à jour
Une sauvegarde est créée automatiquement avant chaque mise à jour du logiciel.
Vérification de la signature des fichiers de mise à jour
Les fichiers de mise à jour officiels portent la signature électronique du développeur (Ed25519). Avant la mise à jour, la signature et le contenu de chaque fichier sont vérifiés : les fichiers altérés et les fichiers de mise à jour non officiels ne sont pas appliqués.
Vérification des images téléversées
Le format des images (avatars, miniatures, logos, etc.) est déterminé d'après le contenu du fichier, et les images sont enregistrées sous un nom de fichier aléatoire. Les dossiers d'images ne servent aucun fichier autre que des images (avec Apache). Le format SVG n'est pas accepté.
En-têtes de sécurité
Les en-têtes Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy et Permissions-Policy sont envoyés pour empêcher le détournement de clic (clickjacking) et les fuites d'informations vers des sites externes. En cas d'utilisation en HTTPS, l'en-tête Strict-Transport-Security est également envoyé afin que le navigateur se connecte toujours en HTTPS.
Gestion des sessions
La session est recréée à chaque connexion. Les modifications de droits, les suppressions de compte et les changements de mot de passe s'appliquent immédiatement, y compris aux sessions déjà ouvertes. La modification de l'adresse e-mail et du mot de passe exige la saisie du mot de passe actuel.
Contrôles de sécurité à chaque version
Avant de publier une nouvelle version, nous effectuons les contrôles suivants. Ils sont réalisés dans un environnement de test configuré comme l'environnement de production, jamais sur des services en ligne ni sur les serveurs de nos clients. Les contrôles effectués pour la dernière version sont indiqués dans « Résultats des contrôles de la dernière version ».
| Catégorie | Contenu du contrôle | Outils et référentiels | Fréquence |
|---|---|---|---|
| Bibliothèques dépendantes | Vérification de l'absence de vulnérabilités connues dans les bibliothèques utilisées et établissement de la liste des bibliothèques utilisées (SBOM) | composer audit, OSV-Scanner, CycloneDX | À chaque version |
| Analyse statique | Détection dans le code source des chemins par lesquels une saisie peut atteindre un traitement dangereux (XSS, injection SQL, etc.) | Psalm (analyse de taint), PHPStan (niveau 5), Semgrep | À chaque version |
| Fuite de secrets | Vérification qu'aucun mot de passe ni aucune clé API ne figure dans le code source ou les fichiers distribués | gitleaks | À chaque version |
| Analyse dynamique | Envoi de véritables requêtes d'attaque, connecté en tant qu'administrateur et en tant qu'utilisateur standard, et vérification des réponses | Nuclei | À chaque version |
| Contrôle des droits | Vérification qu'il est impossible de consulter ou de manipuler les tickets, fichiers et notes d'un projet auquel on ne participe pas en modifiant l'ID dans l'URL | Tests automatisés (PHPUnit), vérification manuelle | À chaque version |
| Téléversement de fichiers | Vérification que les fichiers exécutables, les fichiers déguisés en images, les ZIP manipulant les chemins, etc. sont bien refusés | Revue de code, vérification manuelle | À chaque version |
| XSS | Saisie de chaînes d'attaque dans le corps des tickets, les commentaires, le Wiki et les textes générés par l'IA, et vérification qu'aucun script ne s'exécute | Revue de code, vérification manuelle | À chaque version |
| Vérification par configuration de serveur | Vérification, pour Apache et Nginx et pour chaque emplacement possible du dossier public, que les fichiers de configuration et les journaux ne sont pas directement accessibles | Vérification manuelle | À chaque version |
| Extension de l’intégration Claude | Vulnérabilités connues des bibliothèques utilisées par l’extension, traitement du jeton d’API et restriction des destinations des requêtes | npm audit, gitleaks, revue de code | À chaque version de l’extension |
| Auto-évaluation par liste de contrôle | Vérification point par point de l'authentification, des sessions, de la validation des saisies, de la gestion des erreurs, etc. | Inspirée de l'OWASP ASVS 5.0 niveau 1 ; IPA (Japon) : How to Secure Your Website | À chaque version majeure |
| Site officiel | Configuration HTTPS et en-têtes de sécurité de geckoflag.com | SSL Labs, Mozilla Observatory | Une fois par mois |
Si un problème de gravité « élevée » ou « moyenne » est détecté, la version n'est pas publiée tant qu'il n'a pas été corrigé et contrôlé à nouveau. Pour les problèmes de gravité « faible », nous en examinons le contenu, puis nous les corrigeons ou consignons la raison pour laquelle ils sont sans incidence.
Politique de mise à jour des bibliothèques dépendantes
Les vulnérabilités connues des bibliothèques utilisées par GeckoFlag (CakePHP, etc.) sont vérifiées à chaque version. Si une vulnérabilité affectant GeckoFlag est découverte, nous publions une version corrective dans les délais indicatifs suivants.
- Gravité « critique » ou « élevée » :dans les 14 jours suivant sa divulgation
- Gravité « moyenne » :dans les 30 jours suivant sa divulgation
- Gravité « faible » :à la version suivante (au plus tard dans les 90 jours)
Même lorsqu'une vulnérabilité n'a pas d'incidence compte tenu de la manière dont GeckoFlag utilise la bibliothèque, nous passons à une version corrigée lors de la version suivante. Les bibliothèques de développement ne sont pas incluses dans les fichiers distribués.
Résultats des contrôles de la dernière version : v1.11.0
Ces contrôles ont porté sur les modifications depuis la v1.10.0 (l’intégration Claude, les couleurs de texte et de fond et les séparateurs du texte enrichi, etc.) et ont aussi permis de corriger des problèmes déjà présents dans les versions précédentes. Si vous utilisez la v1.10.0 ou une version antérieure, nous vous recommandons de passer à la v1.11.0.
| Contrôle | Outils utilisés (version) | Détections (élevée / moyenne / faible) | Suite donnée |
|---|---|---|---|
| Bibliothèques dépendantes | GitHub Advisory Database, FriendsOfPHP security-advisories (données au 2026-10-28 ; 89 paquets) | 0 / 0 / 0 | Aucune vulnérabilité connue dans les bibliothèques incluses dans les fichiers distribués. Les vulnérabilités connues des bibliothèques de développement ont été résolues par une mise à jour dans la v1.11.0 (les bibliothèques de développement ne sont pas incluses dans les fichiers distribués) |
| Analyse statique et revue de code | Psalm 5.26.1 (analyse taint), PHPStan 2.1.17 (niveau 5), Semgrep 1.182.1, revue de code manuelle (modifications depuis la v1.10.0 : API et jetons de l’intégration Claude, texte enrichi, maintien de la connexion, mises à jour du logiciel ; ainsi que la sortie des liens sur tous les écrans) | 1 / 1 / 3 | Les problèmes de gravité « élevée » et « moyenne » et 2 problèmes de gravité « faible » ont été corrigés dans la v1.11.0. Le problème « faible » restant ne survient que par les actions de l’utilisateur lui-même, et son impact a été jugé limité. Le problème « élevé » était déjà présent dans les versions précédentes |
| Fuite de secrets | gitleaks 8.24.2 | 0 / 0 / 0 | Le code source et les fichiers distribués ont tous deux été vérifiés. Les 2 détections étaient des faux positifs (chaînes d’exemple dans des bibliothèques externes, etc.) |
| Vérification des corrections | Vérification du fonctionnement dans l'environnement de test (PHP 8.3, MariaDB 10.11, Apache 2.4, Nginx 1.24, Chromium) | — | Pour chaque point relevé, vérification que le problème d'origine ne se reproduit plus |
| Analyse dynamique | Nuclei v3.11.1 (modèles v10.5.1), sans connexion et en tant qu'administrateur et membre | 0 / 0 / 0 | Aucun problème |
| Contrôle des droits | PHPUnit 12.5 (454 tests automatisés ; en plus des contrôles précédents, ils vérifient que l’API de l’intégration Claude refuse les requêtes sans jeton, avec un jeton en lecture seule, venant d’utilisateurs non autorisés ou lorsque la fonction est désactivée, et n’atteint jamais les projets auxquels l’utilisateur ne participe pas) | 0 / 0 / 0 | Aucun problème |
| Vérification par configuration de serveur | Manuelle (Apache 2.4 et Nginx 1.24, 2 emplacements possibles du dossier public ; 39 URL : fichiers de configuration, journaux, sessions, fichiers stockés, etc.) | 0 / 0 / 1 | Corrigé dans la v1.11.0 : l’accès direct au dossier de fichiers des anciennes versions (files) est désormais entièrement refusé aussi sous Apache. Aucun autre problème |
| Liste de contrôle | OWASP ASVS 5.0 niveau 1 (70 points) | 50 des 56 points applicables respectés | Non revue cette fois (le résultat de la v1.10.0 est conservé) |
| Extension de l’intégration Claude | npm audit, gitleaks 8.24.2, mcpb validate, revue de code manuelle (geckoflag-1.0.0.mcpb) | 0 / 0 / 0 | Aucune vulnérabilité connue touchant les bibliothèques incluses dans le fichier distribué. Vérification du traitement du jeton d’API et de la restriction des destinations des requêtes (HTTPS uniquement, redirections non suivies) |
Les résultats de toutes les versions, y compris les précédentes, sont regroupés dans « Résultats précédents ».
Ce qui n'est pas contrôlé
Les contrôles ci-dessus ont les limites suivantes. Tenez-en compte également si vous envisagez d'adopter GeckoFlag.
- Aucun contrôle n'a été réalisé par un tiers.À ce jour, aucune revue du code source ni aucun test d'intrusion n'a été effectué par des experts externes.
- L'environnement de votre serveur n'entre pas dans le périmètre des contrôles.La sécurité varie fortement selon la configuration et l'état des mises à jour du système d'exploitation, du serveur web, de PHP et de la base de données.
- Tous les environnements d'hébergement n'ont pas été vérifiés.Les configurations contrôlées se limitent à celles indiquées dans « Résultats des contrôles de la dernière version ».
- Les services externes ne sont pas couverts.La sécurité de l'API d'Anthropic utilisée par les fonctions d'IA, de l'application de bureau Claude utilisée par l'intégration Claude, des serveurs d'envoi d'e-mails, etc. relève de leurs fournisseurs respectifs.
- À propos des problèmes non détectés par les outils automatiques.Les types de problèmes que les outils ne détectent pas (failles de logique métier, etc.) sont couverts par des contrôles manuels, mais ceux-ci ne peuvent pas tout couvrir.
Si vous découvrez une vulnérabilité
Si vous découvrez un problème qui pourrait constituer une vulnérabilité de GeckoFlag, merci de ne pas le divulguer publiquement et de nous contacter directement via le canal ci-dessous. Le développeur lit personnellement chaque signalement.
Canal de signalement :Utilisez le formulaire de contact en choisissant le type de demande « Signalement de vulnérabilité »
Informations à nous communiquer
- La version concernée et l'écran ou la fonction présentant le problème
- Les étapes pour reproduire le problème (dans la mesure du possible)
- L'impact envisagé
- L'environnement de votre serveur (PHP, serveur web, etc.)
Nous vous demandons
- D'effectuer vos tests dans un environnement que vous gérez vous-même, et de ne mener aucune opération offensive contre des instances de GeckoFlag exploitées par d'autres personnes ni contre geckoflag.com.
Si vous le souhaitez, nous mentionnerons votre nom dans les remerciements des informations de sécurité de la version corrective.
SHA-256 des fichiers distribués
Vous pouvez vérifier qu'un fichier téléchargé est identique au fichier officiel en le comparant avec les valeurs suivantes.
| Fichier | SHA-256 |
|---|---|
| GeckoFlag - 1.11.0.zip | 33354ac588c4cb4de2953c3c26a484953c2bb886f38196ba4bcf4fe629648399 |
| geckoflag-1.0.0.mcpb | 44f2c6dfc9f437856d0680920a327820d757a14116064faa6e46ad8a961d0747 |
Procédure : sous Windows, exécutez Get-FileHash nom-du-fichier -Algorithm SHA256 dans PowerShell ; sous macOS et Linux, exécutez shasum -a 256 nom-du-fichier.
Paramètres recommandés pour une utilisation sûre
La sécurité de GeckoFlag dépend aussi de la configuration du serveur sur lequel il est installé. Nous recommandons les paramètres suivants.
- Terminer l'installation dès le téléversement : tant que l'installation n'est pas terminée, toute personne connaissant l'URL peut ouvrir l'écran d'installation. Une fois les fichiers en place, terminez l'installation sans attendre.
- Utiliser le HTTPS : les identifiants de connexion et le contenu des projets sont chiffrés lors de leur transmission. La plupart des hébergeurs mutualisés proposent des certificats SSL gratuits. Notez qu'une fois l'adresse ouverte en HTTPS, le navigateur s'y connecte ensuite en HTTPS pendant un an (v1.10.0 et versions ultérieures). Soyez-y attentif si vous prévoyez de renoncer au HTTPS.
- Définir webroot comme dossier public (racine des documents) : les fichiers de configuration et les journaux se trouvent alors hors de portée du Web.
- Ajouter la configuration nécessaire si vous utilisez Nginx : avec Nginx, .htaccess n'a aucun effet. Configurez séparément le blocage de l'accès aux dossiers privés et la non-exécution de PHP dans le dossier de téléversement des images (webroot/img). Un exemple de configuration est disponible dans le manuel (Installation).
- Mettre à jour vers la dernière version : les correctifs de sécurité sont fournis dans la dernière version. Procurez-vous les fichiers de mise à jour sur le site officiel et vérifiez leur SHA-256. À partir de la v1.10.0, la signature est aussi vérifiée automatiquement avant la mise à jour.
- Utiliser des versions de PHP et de base de données encore prises en charge : aucun correctif n'est fourni pour les versions de PHP dont le support a pris fin.
- Protéger les comptes administrateur : utilisez des mots de passe longs et difficiles à deviner, et n'accordez les droits d'administrateur qu'aux personnes qui en ont besoin.
- Utiliser la restriction par IP pour un usage interne : depuis « Paramètres », vous pouvez limiter les adresses IP autorisées à accéder à l'application.
- Effectuer des sauvegardes régulières : conservez la base de données et les fichiers téléversés dans un emplacement distinct du serveur.