Sécurité et confidentialité dans Badgr

Cette page s'adresse aux DPO, RSSI et responsables IT qui évaluent Badgr dans le cadre d'un cycle d'achat ou d'un audit de conformité. Elle décrit les mesures techniques et organisationnelles en place, telles qu'elles sont implémentées dans le code de production.

Chiffrement des données sensibles

Badgr distingue deux types de données sensibles, traités différemment selon leur usage :

Mots de passe et codes PIN

Les mots de passe des utilisateurs et les codes PIN des employés sont stockés via bcrypt (fonction password_hash PHP avec PASSWORD_DEFAULT). Il s'agit d'un hachage à sens unique — Badgr ne peut pas retrouver un mot de passe en clair. La vérification s'effectue par comparaison de hachage (password_verify).

Secrets d'intégration

Les credentials qui doivent être déchiffrables par l'application (mot de passe de bind LDAP, client secret Azure AD) sont chiffrés en AES-256-CBC avec un IV aléatoire de 128 bits généré à chaque opération de chiffrement. Le chiffré est encodé en base64 avant stockage.

La clé de chiffrement est dérivée de la variable d'environnement APP_SECRET (minimum 32 caractères exigés au démarrage) via SHA-256. Cette variable n'est jamais présente dans le code source ni dans le dépôt — elle est injectée uniquement au niveau du serveur.

Transport sécurisé

HTTPS sur badgr.be

Toute communication avec badgr.be est chiffrée en TLS 1.2 minimum. Les requêtes HTTP sont redirigées vers HTTPS au niveau du serveur web. Il n'existe pas d'endpoint actif en clair sur le domaine de production.

Appels sortants vers Microsoft et OAuth

Les appels vers l'API Microsoft Graph et les endpoints d'authentification OAuth utilisent un contexte de flux PHP avec validation stricte du certificat serveur : verify_peer = true, verify_peer_name = true, allow_self_signed = false, et un timeout de 10 secondes. Un certificat auto-signé côté Microsoft provoquerait une erreur de connexion, pas un fallback silencieux.

Connexions LDAP

Les connexions vers un annuaire LDAP utilisent le schéma ldaps:// lorsque l'option SSL est activée. Lors des opérations d'importation et de recherche, Badgr impose LDAP_OPT_X_TLS_REQUIRE_CERT = LDAP_OPT_X_TLS_DEMAND — la connexion est refusée si le certificat serveur ne peut pas être validé. Un timeout réseau de 5 secondes est également appliqué.

Isolation multi-tenant

Badgr est une application multi-tenant : plusieurs organisations (tenants) cohabitent sur la même infrastructure, chacune isolée des autres.

L'isolation est appliquée côté serveur à chaque requête :

• Chaque session est liée à un tenant_id vérifié à chaque appel via session_guard.php et admin_is_authorized().
• Toutes les requêtes SQL incluent un filtre WHERE tenant_id = ? — il n'est pas possible d'atteindre les données d'un autre tenant en modifiant l'identifiant dans la requête HTTP.
• Un owner du tenant A ne peut pas lire, modifier ni supprimer les données du tenant B, même en appelant l'API directement avec un token valide.

Cette isolation ne repose pas uniquement sur l'interface utilisateur : elle est vérifiée à chaque endpoint API indépendamment de ce que l'interface affiche.

Authentification renforcée

• Email + mot de passe (minimum 8 caractères) pour tous les comptes admin/owner/manager.
• MFA TOTP disponible pour chaque compte ; peut être imposée par l'owner à tous les owners/admins et/ou managers. Voir la page dédiée au MFA.
• hCaptcha sur les formulaires publics (inscription, connexion, réinitialisation de mot de passe) pour prévenir les attaques automatisées.
• Rate limiting sur les endpoints sensibles : tentatives de connexion, réinitialisation de mot de passe, exports, et opérations de plan — les dépassements retournent une erreur 429.

Hébergement et RGPD

Données stockées vs non stockées

Rétention et suppression

Suppression de compte : lorsque l'owner supprime son organisation, les données personnelles identifiables (noms, emails, PINs, tokens, signatures) sont anonymisées immédiatement. Les pointages, plannings et absences sont conservés sous forme anonymisée pendant 5 ans conformément à la loi belge, sans aucun lien permettant de les rattacher à une personne réelle.

Résilience réseau (mode hors ligne)

En mode hors ligne (plans Essentiel et supérieurs), le kiosque stocke une copie chiffrée des données nécessaires au pointage dans l'IndexedDB du navigateur. Ce cache local est chiffré en AES-256-GCM avec une clé dérivée du token kiosque — il ne peut pas être lu sans connaître le token.

En cas de perte ou de vol de la tablette :

• La régénération du token depuis Paramètres → Kiosque invalide immédiatement l'ancienne URL.
• Les données locales sur la tablette restent chiffrées et inaccessibles sans le token révoqué.

Les pointages enregistrés hors ligne sont chiffrés avant mise en file d'attente et ne transitent vers le serveur qu'une fois la connexion rétablie, via HTTPS. Voir la page dédiée au mode hors ligne pour les détails techniques.

Audit et journaux

Un journal des pointages est accessible depuis Pointages → Journal (et admin/logs.html pour les owners). Il enregistre chaque événement de pointage avec son horodatage, l'identifiant de l'employé, et le statut de modification éventuelle. Les managers y accèdent avec un périmètre limité à leur service.

Les actions administratives critiques (activation/désactivation du MFA, changements de plan, suppressions) sont tracées dans une table audit_log interne, non encore exposée dans l'interface — cette fonctionnalité est prévue dans une version future.

Documentation à jour au 13 mai 2026. Données vérifiées dans api/lib/encryptor.php, api/lib/totp.php, api/admin/ldap_config.php, api/admin/ldap_search.php, api/admin/mfa_setup.php et api/admin/delete_account.php. Si vous remarquez une incohérence, écrivez-nous.