Confiance et sécurité

Apertur traite des photos et des métadonnées 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 OWASP Top 10, le cadre de référence de l'industrie en matière de risques liés à la sécurité applicative.

Chaque appel API et chaque action effectuée dans le tableau de bord passe par notre couche d'autorisation. Les sessions sont liées à une empreinte d'appareil et sont rotées en cas d'activité suspecte. Vous pouvez révoquer une session active à tout moment depuis les paramètres de votre compte.

Les clés API sont restreintes par projet et par environnement (production vs bac à sable). Chaque clé peut être limitée à une plage d'adresses IP, à un domaine d'origine, et facultativement à un certificat TLS client. Les clés de production et de bac à sable ne sont pas interchangeables.

Les applications OAuth valident l'origine des requêtes contre une liste blanche enregistrée à l'application — empêchant l'utilisation des jetons depuis un domaine non autorisé.

Les mots de passe sont stockés exclusivement sous forme de hachages bcrypt avec un facteur de coût de 12 — jamais en clair, jamais chiffrés de manière réversible. Les clés API sont stockées sous forme de hachages SHA-256 et ne sont affichées qu'une seule fois à la création.

L'ensemble du trafic vers apertur.ca et notre API est servi en TLS, avec HTTP Strict Transport Security (HSTS) appliqué en production. Les webhooks sortants doivent utiliser des points de terminaison HTTPS.

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

Toutes les requêtes entrantes sont validées contre des schémas stricts avant d'atteindre la logique applicative. L'accès à la base de données passe exclusivement par un constructeur de requêtes paramétrées — aucune chaîne SQL n'est concaténée avec une entrée utilisateur, ce qui élimine une classe entière de vulnérabilités d'injection SQL.

Les fichiers téléversés sont validés contre une liste blanche de types MIME, une taille maximale et des limites de dimensions d'image.

Chaque réponse de page comporte une Content Security Policy qui restreint les scripts, styles et connexions que le navigateur autorisera. Les scripts en ligne ne s'exécutent qu'avec un nonce cryptographique généré par requête ; l'injection arbitraire de script est bloquée même si elle contourne l'encodage de sortie (XSS, extension de navigateur malveillante, CDN compromis). Le site marketing, le tableau de bord et la page de téléversement publique ont chacun leur propre politique — la page de téléversement étant la plus stricte, n'autorisant que les scripts de première partie.

La même réponse définit aussi HSTS (sécurité du transport), frame-ancestors (empêche le détournement de clic via iframe), base-uri et form-action. Les violations de politique sont rapportées à notre système de monitoring pour révision.

Nous prenons en charge plusieurs deuxièmes facteurs :

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

Les mots de passe doivent contenir au moins 8 caractères et sont vérifiés contre la base Have I Been Pwned — les mots de passe connus comme compromis sont rejetés à l'inscription et lors de la réinitialisation.

Les points de terminaison d'authentification ont des limites de débit agressives par IP (5 tentatives par minute pour la connexion et l'inscription ; 3 par heure pour la réinitialisation du mot de passe). L'API dans son ensemble est limitée pour prévenir l'énumération et le déni de service.

reCAPTCHA v3 évalue les formulaires publics (inscription, connexion, contact). La détection de connexion suspecte signale les patterns IP/appareil anormaux et déclenche un courriel de sécurité au propriétaire du compte. Les signaux d'abus multi-comptes sont évalués au moment de l'inscription.

Lorsque le service de téléversement reçoit un fichier d'un contributeur, il est validé, éventuellement filigrané ou miniaturisé, puis livré directement à la destination configurée pour le projet (S3, webhook, système partenaire). Les originaux ne sont pas conservés au-delà du temps nécessaire à la livraison — généralement quelques minutes, avec un plafond strict de 7 jours.

Les sessions de téléversement sont liées à une URL à usage unique. Les sessions imposent une expiration, un nombre maximum d'images et des listes blanches par type MIME. Le chiffrement de bout en bout peut être activé sur demande pour les charges de travail sensibles.

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

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 de suivi d'erreurs distinct. Avant toute transmission, les jetons d'autorisation, cookies et identifiants de session sont retirés des en-têtes, les corps de requête des routes d'authentification et de sécurité de compte sont expurgés, les paramètres de requête sensibles (`token`, `code`, `secret`, `email`, `phone`) sont supprimés, et le contexte utilisateur est limité à un identifiant de compte stable — jamais l'adresse courriel, le nom ou le téléphone.

Apertur est hébergé au Canada. Les en-têtes de sécurité standard (HSTS, drapeaux de cookies sécurisés, politiques cross-origin) sont définis sur chaque réponse. Les réponses d'erreur sont assainies — les traces de pile et les détails d'erreur internes ne sont jamais renvoyés aux clients. Les dépendances sont verrouillées via un fichier de verrouillage et révisées avant chaque mise à jour.

Les logos et icônes fournis par les partenaires sont récupérés, validés, traités et stockés sur notre infrastructure plutôt que référencés au runtime. Cela élimine la dépendance envers les serveurs des partenaires pour le rendu de la page de téléversement et empêche les opérateurs d'hébergement d'images d'observer le trafic de vos utilisateurs finaux.

Nous accueillons les rapports des chercheurs en sécurité. Si vous croyez avoir découvert une vulnérabilité dans Apertur, veuillez nous contacter via notre formulaire de contact (sujet : Sécurité) avant toute divulgation publique. Nous nous engageons à accuser réception des rapports dans un délai de 5 jours ouvrables et travaillerons avec vous sur un calendrier de divulgation coordonné. Nous n'opérons pas actuellement de programme de prime aux bogues rémunéré, mais nous serons heureux de créditer les chercheurs dans nos notes de version.

Pour les questionnaires de sécurité, les demandes de diligence raisonnable, ou pour discuter d'un contrôle spécifique 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 un délai de 2 jours ouvrables.