La sécurité des applications que nous construisons et exploitons — des contrôles écrits en code, vérifiables de l’extérieur, sans certifications que nous n’avons pas.
Le travail couvre la sécurité des applications et l’ingénierie de la confidentialité : en-têtes et politique de contenu, limitation de débit, position par défaut « fermé » des vérifications, chiffrement des secrets, journaux impossibles à réécrire, anonymisation des données et durées de conservation définies dans le code, pas seulement dans la politique. Nous ne sommes pas des auditeurs certifiés et nous n’émettons pas de certificats.
Déjà construitAm ales „livrat” pentru un domeniu deliberat îngust, iar limita o scriem înaintea listei de capabilități. Controalele descrise mai jos rulează în sisteme proprii și o parte se pot verifica din exterior chiar acum: limitarea de rată se demonstrează cu douăsprezece cereri consecutive (a zecea primește 429, verificat pe producție la 06.09.2026), sonda de sănătate întoarce doar valori logice, iar antetele de securitate se citesc din răspuns. A doua și a treia implementare citate sunt platforma de sesizări — politică de conținut cu valoare unică per răspuns, listă albă de destinații de rețea verificată în integrarea continuă, autentificare în doi pași obligatorie pentru personal — și clientul de semnătură electronică scris fără nicio dependență nouă, cu apărare împotriva încadrării semnăturii XML. Ce NU susține dovada: nu avem nicio certificare, nu facem testare ofensivă ca serviciu, nu operăm un centru de monitorizare și nu emitem atestate de conformitate.
La plupart des failles que nous avons trouvées dans nos propres systèmes n’étaient pas des exploitations sophistiquées. C’étaient des valeurs par défaut. Une route qui lançait un appel téléphonique vers n’importe quel numéro, sans authentification, qu’aucun composant de l’interface n’appelait plus depuis longtemps. Une vérification d’origine qui passait lorsque la liste était vide. Une adresse IP complète envoyée dans un message de notification, alors que la page publique promettait l’anonymisation. Les trois étaient écrites dans notre code et aucune n’aurait été visible dans un scanner automatique.
C’est de là que vient la forme du service. Nous ne vendons pas un rapport de scan. Nous lisons le code avec une question précise : quand cette vérification ne peut pas décider, que fait-elle — elle autorise ou elle refuse ? La position par défaut est la différence entre une gate et une décoration. Dans nos systèmes, la gate de consommation renvoie « non autorisé » en cas d’exception, et la route d’appel téléphonique répond 404 si le secret n’est pas configuré — autrement dit, la fonction est arrêtée si quelqu’un ne l’a pas démarrée délibérément.
La seconde moitié du travail est l’ingénierie de la confidentialité, car en pratique les deux ne se séparent pas. Le délai de conservation déclaré publiquement ne signifie rien s’il n’est pas appliqué par le code. Chez nous, le journal des requêtes supprime les fichiers plus anciens que le délai déclaré, avec le nombre de jours pris dans la même valeur qui apparaît dans la politique publiée. Dans un autre système, la table de rétention garde à côté de chaque délai le texte publié, mot pour mot, et la base légale — pour que la politique et la base de données ne puissent pas dévier silencieusement l’une de l’autre.
Ce que nous publions sur nous-mêmes fait partie de la méthode. La politique de contenu de ce site autorise `unsafe-inline` et `unsafe-eval` dans les scripts. C’est une faiblesse réelle et nous l’écrivons ici, pas dans un rapport interne — c’était même le mécanisme grâce auquel notre propre audit d’accessibilité a pu injecter un outil de vérification directement dans la page de production. Un fournisseur qui ne publie pas ses propres faiblesses connues ne peut pas trouver les vôtres.
Ce que cela comprend
Le travail, par composantes
Nous lisons la position par défaut de chaque vérification
La question centrale de l’analyse : quand la vérification ne peut pas décider, permet-elle ou refuse-t-elle ? Exemple réel, tiré de notre propre code, marqué comme tel : la liste des origines autorisées d’un widget laisse la vérification passer si la liste est vide — choix délibéré de compatibilité avec les anciennes installations, écrit dans un commentaire, mais qui signifie que la restriction par domaine doit être configurée explicitement à chaque implémentation. Le contre-exemple : le gate de consommation qui, à la moindre exception, renvoie « interdit ».
Limitation de débit correcte derrière un proxy
Dix requêtes par minute par adresse, avec une subtilité qui décide si la limite fonctionne ou non : la clé est prise depuis le dernier saut de l’en-tête de redirection, pas depuis le premier. Notre proxy ajoute la vraie adresse à la fin de ce qu’a envoyé le client, donc la première entrée est contrôlée par l’attaquant — celui qui mise sur elle peut dépasser sa limite en envoyant des valeurs aléatoires. Cela peut être vérifié de l’extérieur : douze requêtes consécutives donnent neuf réponses réussies, puis 429.
En-têtes et politique de contenu, avec une valeur unique par réponse quand c’est possible
Sur ce site : transport strict sur deux ans avec sous-domaines et inscription sur la liste de préchargement, type de contenu non inférable, politique de référent restreinte, politique de permissions qui ferme la caméra et laisse le microphone et la localisation uniquement pour la page propre. Sur la plateforme de signalements, plus strict : la politique de contenu reçoit une valeur unique à chaque réponse, générée dans le proxy, sans sources tierces pour les scripts, connexions ou polices, et l’intégration dans un cadre est entièrement refusée.
Liste blanche des destinations réseau, vérifiée automatiquement
Dans un projet public, les adresses que l’application a le droit de contacter constituent une liste vérifiée par une commande exécutée en intégration continue, à la fois statiquement et à l’exécution. Un nouveau paquet qui commence à téléphoner à la maison échoue à la vérification, pas en production. C’est le contrôle qui attrape exactement la classe d’incidents de la chaîne d’approvisionnement contre lesquels personne ne se protège avec un scanner de vulnérabilités.
Les secrets n’atteignent pas les réponses, les journaux ni les notifications
La sonde de santé du formulaire de contact ne renvoie que des valeurs logiques — s’il est configuré, si l’accréditation est valide, si le journal peut être écrit — jamais le jeton, l’identifiant de conversation ou le nom du bot. Les jetons de canal de la plateforme de messagerie sont conservés chiffrés. Les journaux d’alerte passent par un module de caviardage des données personnelles avant écriture.
Anonymisation appliquée avant l’écriture, pas après
L’adresse IP est tronquée au préfixe réseau — /24 pour IPv4, /48 pour IPv6 — avant d’entrer dans le journal ou dans une notification. Avec deux détails qui comptent : on prend le dernier saut, pas le premier, pour la même raison que pour la limitation de débit ; et les adresses IPv4 rapportées sous forme mappée IPv6 sont reconnues et traitées comme IPv4, sinon elles seraient conservées en entier, c’est-à-dire exactement à l’inverse du but.
Journal qui ajoute, sans réécrire
Les demandes via formulaire sont écrites dans un journal en ajout, un objet par ligne, avec des droits 0600 sur le fichier et 0700 sur le répertoire, avant toute tentative de livraison. La raison est un vrai dysfonctionnement : quand le canal de notification est tombé, l’endpoint renvoyait 500 et chaque demande était perdue sans trace. Désormais, un canal cassé signifie « il faut regarder dans le fichier », pas « la demande n’a jamais existé ». Le résultat de la livraison est écrit comme deuxième ligne, avec le même identifiant.
Le délai de conservation appliqué par le code, pas seulement déclaré
Le journal des demandes supprime les fichiers plus anciens que le délai déclaré publiquement, avec le nombre de jours pris dans la même valeur. Dans un autre système, la table de rétention garde à côté de chaque délai le texte publié mot pour mot et le fondement juridique, et la fonction de nettoyage signale par défaut ce qu’elle supprimerait ; la suppression réelle exige un argument explicite. La suppression silencieuse est un mode d’échec, pas une fonction.
L’identité et la signature, quand le projet les exige
Nous avons écrit, from scratch et sans nouvelles dépendances, un fournisseur de services pour l’authentification fédérée et un client pour la signature électronique. L’analyseur XML ne traite pas les définitions de type de document, donc la classe d’attaques par entités externes ne s’applique pas ; la vérification de signature renvoie le nœud couvert par la signature, pas une valeur logique, et l’appelant est obligé de comparer l’identité de l’objet — la défense contre l’encadrement de la signature. La canonicalisation a été vérifiée sur les vecteurs officiels de la spécification.
À quoi cela ressemble
Le parcours, étape par étape.
01
Nous définissons le périmètre et ce que nous n’avons pas le droit de toucher
Par écrit, avant toute commande : quels systèmes, quelle période, quels types de vérification sont autorisés et qui est la personne de contact si quelque chose s’arrête. Nous livrons : le document de périmètre signé et la liste des systèmes exclus.
02
Nous lisons le code et la configuration, avec un accent sur la position implicite
Les vérifications qui ne peuvent pas décider, les secrets qui finissent dans les réponses ou les journaux, les routes qui ne sont plus appelées par personne mais restent ouvertes, les en-têtes manquants. Nous livrons : les constats avec fichier et ligne, ordonnés selon ce qu’on peut en faire, pas selon la gravité théorique.
03
Nous corrigeons ou décrivons exactement la correction
Là où nous avons accès, nous mettons le contrôle et écrivons le test qui le maintient en place — une vérification qui n’a pas de test se perd à la première refactorisation. Là où nous n’avons pas accès, nous livrons la modification décrite avec suffisamment de précision pour que l’équipe du client puisse l’appliquer sans nous redemander.
04
Nous relions la confidentialité au code
Le délai de conservation, l’anonymisation et la liste des destinataires deviennent des valeurs dans le code, avec le texte publié à côté. Nous livrons : le registre des traitements complété, avec la colonne « où c’est implémenté » remplie, et la liste des points restant à décider, avec qui décide chacun.
05
Nous vérifions de l’extérieur ce qui peut être vérifié de l’extérieur
Les en-têtes, le comportement aux limites, ce que renvoient les sondes de santé. Nous livrons : les commandes exactes de vérification, afin que n’importe qui — y compris un auditeur du client — puisse répéter la vérification sans nous.
Straturile pe care le atingem, de sus în jos
Les données
Ce que nous touchons, où elles sont et combien de temps elles restent
Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.
Ce nous touchons dans une analyse
Le code, la configuration du serveur, les en-têtes de réponse et, le cas échéant, le schéma de la base de données ainsi que les politiques d’accès, ligne par ligne. Nous n’avons pas besoin des données réelles des clients pour faire l’analyse et nous préférons ne pas les toucher du tout.
Ce que nous ne faisons pas sans domaine autorisé par écrit
Aucune action qui produit du trafic contre un système en fonctionnement. Les vérifications en production qui apparaissent sur cette page sont des requêtes ordinaires de lecture, sur des systèmes propres. Tout dépassement de cette limite nécessite une autorisation écrite, avec période et adresses, signée par la personne habilitée à la donner.
Où vont les constats
Dans un document avec un constat par ligne : où il se trouve, ce qu’il est possible d’en faire, ce qui le corrige précisément et comment vérifier la correction. Les constats qui décrivent une voie d’exploitation ne circulent pas par des canaux non sécurisés et n’aboutissent pas dans des supports publics avant la réparation.
Registre des traitements
Pour la partie confidentialité, le résultat est un registre avec une ligne par activité : finalité, base, catégories de données, destinataires, transferts, lieu de stockage, délai, mesures et le fichier du code où c’est implémenté. Ce qui n’a pas pu être vérifié est écrit « non vérifié », sans être complété à partir du modèle.
La règle qui maintient la politique collée au code
Si une modification de code change ce qui est collecté, à qui cela arrive ou combien de temps cela est conservé, la politique publiée est modifiée au même pas de livraison. L’écart entre la politique publiée et le code a été exactement le problème qui nous a amenés à écrire notre propre registre.
Un cas
Une route oubliée qui pouvait appeler n’importe qui
La situation
Lors d’une revue de notre propre site, nous sommes tombés sur une route d’interface de programmation qui lançait un appel téléphonique vers n’importe quel numéro envoyé dans le corps de la requête. Sans authentification, aux frais et depuis le numéro de l’entreprise. Aucun composant de l’interface ne l’appelait plus — le seul appelant était un élément qui ne s’affichait plus. Autrement dit, elle avait fonctionné ouverte vers Internet sans que personne n’ait de raison de la regarder.
Ce que nous avons construit
Nous l’avons traitée comme deux problèmes, pas un seul. Techniquement : la route exige désormais un secret partagé dans un en-tête, et si le secret n’est pas du tout configuré elle répond 404 — la capacité est arrêtée si quelqu’un ne la démarre pas délibérément, et non pas en marche jusqu’à ce que quelqu’un l’arrête. Juridiquement et éthiquement : un appel automatique non sollicité est un traitement de données que la personne appelée n’a pas demandé, donc nous avons écrit dans le registre ce qui serait nécessaire pour une éventuelle réactivation — base documentée vis-à-vis de l’appelé, preuve du consentement et un canal d’opposition.
Ce qui en est sorti
La capacité est fermée par défaut et le reste jusqu’à ce que quelqu’un prenne une décision explicite. La ligne du registre des traitements décrit l’état, ce qu’il y avait avant, le risque et les conditions de réactivation — ainsi, la prochaine personne qui trouve la route n’a pas à reconstruire le raisonnement.
Ce que le cas ne dit pas
Nous ne l’avons pas découvert à l’aide d’un outil. Nous l’avons trouvée en lisant les routes une par une et en demandant, pour chacune, qui l’appelle. Un scanner automatique aurait vu une route qui renvoie 400 à une requête vide et serait passé à autre chose. C’est aussi la limite de la méthode : elle couvre ce que nous lisons, et ce que nous ne lisons pas reste non couvert — c’est pourquoi le domaine est défini par écrit.
Questions
Ce que les gens nous demandent avant d'appeler
Avez-vous des certifications de sécurité ?
Non. Ni ISO 27001, ni SOC 2, ni aucune certification de test offensif, ni accréditation d’auditeur. Nous n’émettons pas de certificats et ne signons pas d’attestations de conformité. Ce que nous pouvons montrer, c’est notre pratique propre, avec fichier et ligne, ainsi que les contrôles que nous avons mis en place dans des systèmes en fonctionnement. Si vous avez besoin d’un certificat pour un dossier, il vous faut un organisme accrédité, pas nous — et il vaut mieux l’apprendre maintenant.
Faites-vous des tests de pénétration ?
Pas en tant que service. Nous n’avons pas d’équipe de test offensif, de licence ni de méthodologie certifiée, et nous ne prétendons pas en avoir. Ce que nous faisons, c’est une analyse du code et de la configuration, plus des vérifications non invasives depuis l’extérieur — en-têtes, comportement à la limite de débit, ce que fuient les réponses d’erreur. Si le projet exige un vrai test offensif, il vous faut une société spécialisée ; nous pouvons travailler avec elle sur la partie remédiation.
Qu’avez-vous trouvé dans vos propres systèmes ?
Trois choses, en une seule journée d’analyse, toutes écrites publiquement dans notre registre. Une route qui initiait un appel téléphonique vers n’importe quel numéro dans le corps de la requête, de manière anonyme, sans authentification, qu’aucun composant de l’interface n’appelait plus — elle répond maintenant 404 si le secret n’est pas configuré, c’est-à-dire qu’elle est désactivée si quelqu’un ne l’active pas délibérément. Un widget de conversation qui se chargeait à chaque affichage et écrivait la session dans la mémoire du navigateur avant que le visiteur ne demande quoi que ce soit — il se charge maintenant au clic sur le bouton. Et l’adresse IP complète envoyée dans une notification, alors que la page publique promettait l’anonymisation — elle est maintenant tronquée avant l’écriture.
Votre politique de contenu autorise `unsafe-eval`. Pourquoi devrais-je vous croire ?
Parce que c’est nous qui vous l’avons dit, pas vous qui l’avez découvert. Oui, la politique de ce site autorise `unsafe-inline` et `unsafe-eval` dans les scripts — c’est une faiblesse réelle, héritée de la manière dont certains scripts tiers sont chargés, et c’est même le mécanisme par lequel notre propre audit d’accessibilité a injecté un outil de vérification dans la page de production. Sur un projet où la contrainte est définie dès le départ par nous, la bonne forme est celle de la plateforme de signalements : une valeur unique par réponse générée dans le proxy et aucune source tierce pour les scripts. La différence entre les deux, c’est précisément la discussion que nous devrions avoir au début d’un projet, pas à la fin.
Comment puis-je vérifier, sans vous croire sur parole, que la limitation de débit fonctionne ?
En envoyant douze requêtes consécutives vers une route d’interface de programmation de ce site et en comptant les réponses : les neuf premières passent, la dixième reçoit 429 avec l’en-tête qui indique dans combien de temps on peut réessayer. La fenêtre est d’une minute. La commande figure dans la liste des sources de cette page et vous pouvez l’exécuter maintenant. Nous appliquons le même principe à ce que nous livrons : si un contrôle ne peut pas être vérifié de l’extérieur par le client, il n’est pas livré, il est déclaré.
Que devient les données personnelles d’un formulaire ?
Elles sont écrites dans un journal en ajout, un objet par ligne, avec des droits restreints sur le fichier et le répertoire, avant toute tentative de livraison — afin qu’un canal de notification défaillant ne fasse pas disparaître la requête. L’adresse IP est tronquée au préfixe réseau avant l’écriture. Les fichiers plus anciens que le délai déclaré sont supprimés, avec le nombre de jours pris dans la même valeur qui apparaît dans la politique publiée. Et la ligne du registre des traitements indique, pour chaque élément, dans quel fichier du code il est implémenté.
Pouvez-vous faire une authentification avec identité électronique d’État ou signature électronique ?
Le code existe et il est testé, mais il n’est activé nulle part en production, et la différence compte. Nous avons écrit un fournisseur de services pour l’authentification fédérée et un client de signature, tous deux sans nouvelles dépendances, avec les protections spécifiques implémentées et avec des tests. Ce qui manque ne relève pas du code : contrat avec l’autorité, certificat de système et enregistrement de l’adresse de production. D’ici là, la variante qui fonctionne aujourd’hui est celle où le citoyen signe sur le portail officiel et téléverse le document signé en retour.
Quels contrôles mettez-vous normalement dans une nouvelle application ?
Des en-têtes et une politique de contenu avec une valeur unique par réponse ; une limitation de débit avec la clé prise correctement derrière le proxy ; une séparation par organisation appliquée dans la base, pas seulement dans l’application ; des secrets chiffrés et jamais dans les réponses ou les journaux ; des clés d’idempotence sur les événements provenant de tiers ; une authentification à deux facteurs obligatoire pour les comptes du personnel ; un journal d’audit avec une visibilité séparée pour l’interne et le public ; et, pour les projets publics, une liste blanche de destinations réseau vérifiée automatiquement à chaque livraison.
Que ne couvre pas ce service ?
La sécurité du réseau d’entreprise, les équipements des utilisateurs, la surveillance continue de type centre d’opérations, la réponse aux incidents 24/7, l’investigation criminalistique et la formation contre le phishing. Ce ne sont pas des choses que nous faisons mal — ce sont des choses que nous ne faisons pas. Notre domaine, c’est l’application que nous construisons ou reprenons, ainsi que les données qui la traversent.
Sur quoi reposent les affirmations ci-dessus (24 sources)
Antete pe producție: transport strict 63072000 s cu subdomenii și precarcare, tip de conținut nedeductibil, politică de referință restrânsă, politică de permisiuni care închide camera; încadrarea în cadru e refuzată complet pe rutele de interfață de programare și limitată la aceeași origine pe paginihttps://www.megapromoting.com/api/health/contact · 2026-09-06
22 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.
Qu'est-ce que vous voudriez voir mieux fonctionner ?
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.