Confiance et sécurité

Notre engagement

SeeItLive achemine des flux caméra en direct et des clichés qui proviennent souvent de vos clients. Nous prenons cette responsabilité au sérieux. Cette page décrit les contrôles que nous avons mis en place — alignés sur le Top 10 de l'OWASP, la référence de l'industrie en matière de risques de sécurité applicative.

Authentification et contrôle d'accès

Chaque appel d'API et chaque action dans la console passe par notre couche d'autorisation. Les sessions sont liées au compte authentifié et peuvent être consultées et révoquées à tout moment depuis vos paramètres.

Les options de connexion comprennent le mot de passe, les clés d'accès (passkeys) et les liens magiques à usage unique. Les clés d'API sont limitées à chaque compte et peuvent être révoquées à tout moment. Les dossiers de session et les clichés ne sont visibles que par les membres authentifiés de l'espace de travail qui en est propriétaire.

Chiffrement

Les mots de passe sont stockés exclusivement sous forme de hachages bcrypt — jamais en clair, jamais de façon réversible. Les secrets TOTP de double authentification sont chiffrés au repos. Les clés d'API et les codes de récupération sont stockés sous forme de hachages et affichés une seule fois à la création.

Tout le trafic vers seeitlive.io et notre API est servi via TLS, avec HSTS (HTTP Strict Transport Security) appliqué en production. La vidéo en direct circule via DTLS-SRTP, le chiffrement que WebRTC impose pour les médias pair-à-pair.

Les jetons cryptographiques (identifiants de session, jetons de lien magique, codes de récupération) sont générés à l'aide des primitives cryptographiques de Node.js.

Signalisation de session authentifiée

Les sessions en direct sont négociées via un canal de signalisation en temps réel authentifié. Chaque participant — agent et invité — n'est admis qu'avec un identifiant de session valide et à usage unique, de sorte qu'un lien d'accès ne peut être rejoué ni utilisé pour entrer dans une session sans rapport.

Une fois négociés, la vidéo et l'audio circulent en pair-à-pair entre l'appareil de l'invité et le navigateur de l'agent ; SeeItLive ne relaie que la signalisation nécessaire à l'établissement de la connexion et n'enregistre pas le flux.

Authentification multifacteur

Nous prenons en charge plusieurs seconds facteurs :

• TOTP (Google Authenticator, 1Password, Authy, etc.), avec le secret chiffré au repos
• Clés d'accès / WebAuthn (Touch ID, Face ID, Windows Hello, clés de sécurité matérielles)
• Codes à usage unique par SMS
• Codes de récupération (à usage unique, hachés au repos)

Les échecs répétés du second facteur déclenchent un verrouillage par compte pour contrer les attaques par force brute. Les mots de passe doivent comporter au moins 8 caractères et sont comparés au corpus de fuites Have I Been Pwned — les mots de passe connus comme compromis sont rejetés à l'inscription et à la réinitialisation.

Validation des entrées et prévention des injections

Toutes les requêtes entrantes sont validées selon des schémas stricts avant d'atteindre la logique métier. L'accès à la base de données passe exclusivement par un constructeur de requêtes avec des instructions paramétrées — aucune requête SQL brute n'est concaténée avec des données utilisateur, ce qui élimine toute une classe de vulnérabilités d'injection SQL.

Les clichés et pièces jointes téléversés sont validés selon une liste blanche de types MIME et une taille maximale.

Défenses côté navigateur

Chaque réponse de page comporte une politique de sécurité du contenu (CSP) qui restreint les scripts, styles et connexions que le navigateur exécutera ou ouvrira. Les scripts en ligne ne s'exécutent qu'avec un nonce cryptographique propre à chaque requête ; l'injection arbitraire de scripts est bloquée même si elle contourne l'encodage de sortie (XSS, extension de navigateur malveillante, CDN compromis).

La même réponse définit aussi HSTS (sécurité du transport), frame-ancestors (empêche le détournement de clic par iframe), base-uri et des restrictions form-action.

Limitation de débit et prévention des abus

Les points de terminaison d'authentification et publics ont des limites de débit agressives par IP (par exemple, 5 tentatives de connexion ou d'inscription par minute, et le formulaire de contact public est également plafonné). L'API dans son ensemble est soumise à une limitation de débit pour dissuader l'énumération et le déni de service.

reCAPTCHA évalue les formulaires publics (inscription, connexion, contact). La détection de connexions suspectes signale les schémas IP/appareil anormaux et déclenche un courriel de sécurité au propriétaire du compte. Les signaux d'abus multicomptes sont évalués au moment de l'inscription.

Médias en direct et clichés

Le flux caméra en direct est transmis en pair-à-pair et n'est jamais enregistré par SeeItLive. Seuls les clichés qu'un agent choisit de capturer sont conservés, et chaque capture est inscrite au journal d'audit de la session.

Les clichés conservés sont liés à l'espace de travail propriétaire de la session et ne sont accessibles qu'à ses membres authentifiés. Les invités accordent explicitement l'accès à la caméra dans leur navigateur et peuvent mettre fin au partage à tout moment.

Journaux d'audit et surveillance

Les événements pertinents pour la sécurité sont journalisés avec horodatage, adresse IP et agent utilisateur : connexions réussies et échouées, activation et retrait de la MFA, création et révocation de sessions, réinitialisations de mot de passe et modifications de clés d'API. Les propriétaires de compte peuvent consulter leur propre journal d'audit depuis la console.

Les journaux applicatifs sont structurés (JSON) et conservés à des fins de diagnostic et de réponse aux incidents.

Les erreurs applicatives non gérées sont capturées par un système distinct de suivi des erreurs. Avant toute transmission, les jetons d'autorisation, les témoins et les identifiants de session sont retirés des en-têtes de requête, le corps des requêtes des routes d'authentification et de sécurité du compte est expurgé, les paramètres de requête sensibles sont supprimés, et le contexte utilisateur est limité à un identifiant de compte stable — jamais le courriel, le nom ou le téléphone.

Infrastructure et configuration

SeeItLive est hébergé au Canada. Des en-têtes de sécurité standard (HSTS, attributs de témoins sécurisés, politiques inter-origines) sont définis sur chaque réponse. Les réponses d'erreur sont assainies — les traces de pile et les détails internes ne sont jamais renvoyés aux clients. Les dépendances sont figées par fichier de verrouillage et examinées avant chaque mise à jour.

Divulgation responsable

Nous accueillons favorablement les signalements des chercheurs en sécurité. Si vous pensez avoir découvert une vulnérabilité dans SeeItLive, veuillez nous contacter au moyen de notre formulaire de contact (sujet : Sécurité) avant toute divulgation publique. Nous nous engageons à accuser réception des signalements dans les 5 jours ouvrables et travaillerons avec vous sur un calendrier de divulgation coordonnée. Nous n'exploitons pas actuellement de programme de primes rémunéré, mais nous sommes heureux de créditer les chercheurs dans nos notes de version.

Contact

Pour les questionnaires de sécurité, les demandes de diligence raisonnable ou pour discuter d'un contrôle précis plus en détail, veuillez utiliser notre formulaire de contact et sélectionner le sujet Sécurité. Nous répondons aux demandes de sécurité dans les 2 jours ouvrables.