ByteHeavy
ByteHeavy
ByteHeavy
Sécurité & confiance
La plupart des agences disent « sécurité de niveau bancaire » et s'arrêtent là. Nous préférons vous montrer les détails précis — y compris les parties encore en cours — parce qu'une promesse vague vaut moins qu'une promesse vérifiable.
Notre système de tickets tourne sur PostgreSQL avec la sécurité au niveau des lignes (Row-Level Security) activée et forcée, connecté via un rôle applicatif dédié qui n'est délibérément pas superutilisateur. Cela signifie que les règles de contrôle d'accès résident dans la base de données elle-même, pas seulement dans le code applicatif. Nous l'avons testé directement : une session cadrée sur l'email d'un client ne peut vraiment pas lire les tickets d'un autre client, même sur exactement la même connexion et le même rôle de base de données. Si un futur bug dans notre code applicatif tentait d'interroger les mauvaises données, la base de données refuse avant même que la requête ne s'exécute — l'isolation ne dépend pas du fait qu'on se souvienne d'écrire la bonne clause WHERE à chaque fois.
Chaque réponse porte une Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, et une Permissions-Policy restrictive — les défenses standard contre le clickjacking, les attaques par détection de type MIME, et une partie du XSS. Les builds de production sont livrés sans source maps, pour que la structure exacte de notre code source ne soit remise à personne qui ouvre les outils de développement.
Chaque point d'entrée de ticket et de formulaire de contact est limité en débit par IP, et inclut un champ « pot de miel » invisible pour les vrais utilisateurs mais souvent rempli automatiquement par les bots — les soumissions qui le déclenchent reçoivent une fausse réponse de succès au lieu d'un rejet, si bien que l'abus scripté n'apprend même pas qu'il a été bloqué. Toutes les entrées de formulaire sont validées côté serveur avec un schéma strict avant même de toucher la base de données, quoi que le frontend laisse passer.
Nous n'allons pas prétendre qu'une fonctionnalité existe avant qu'elle n'existe. L'authentification à deux facteurs (TOTP avec QR code) et un service d'authentification/sessions dédié en Rust sont conçus et planifiés, mais pas encore en production — pour l'instant, la recherche de tickets se fait par correspondance d'email, ce qui est un mécanisme de confort, pas une connexion de niveau mot de passe. Les pièces jointes sur les tickets ne sont volontairement pas encore prises en charge, précisément parce que nous n'avons pas encore construit la couche d'analyse antivirus que nous voudrions devant elles. Nous préférons livrer une fonctionnalité en retard plutôt que de la livrer non sécurisée.
Si vous ne pouvez pas vérifier une affirmation de sécurité, c'est du marketing. Nous préférons que vous puissiez.