Sécuriser
Audit de sécurité
On cherche ce qu'un attaquant trouverait, et on vous dit par quoi commencer.
Les failles que nous trouvons le plus souvent ne sont pas des exploits sophistiqués. Ce sont des adresses d'API qui répondent sans vérifier qui les appelle, des identifiants numériques qu'il suffit d'incrémenter pour lire le dossier du voisin, des clés d'accès laissées en clair dans le code, et des dépendances jamais mises à jour depuis la mise en ligne. Nous cherchons dans cet ordre, parce que c'est celui dans lequel on se fait attaquer. Et nous corrigeons sans supprimer les traces : un correctif qui efface aussi les journaux vous empêche de savoir si vous aviez déjà été visité.
La méthode
Comment nous procédons
- 01
On vérifie qui a le droit d'appeler quoi
Chaque adresse d'API, une par une, avec un compte sans droits puis sans compte du tout. C'est le défaut le plus répandu et le plus grave : le contrôle d'accès fait côté écran, mais pas côté serveur.
- 02
On teste l'énumération et l'accès aux données d'autrui
Un identifiant qui s'incrémente, un jeton devinable, un paramètre non filtré. Sur les applications multi-clients, on vérifie surtout qu'un client ne peut pas voir les données d'un autre.
- 03
On cherche les secrets exposés
Clés d'API dans le code envoyé au navigateur, mots de passe dans l'historique du dépôt, fichiers de configuration accessibles publiquement. Un secret publié une fois doit être changé, pas seulement retiré.
- 04
On passe en revue les dépendances et le serveur
Bibliothèques avec vulnérabilité connue, en-têtes de sécurité, ports ouverts, interfaces d'administration accessibles depuis internet.
- 05
On hiérarchise et on corrige
Classé par ce qui est exploitable depuis internet sans compte, puis par la gravité de ce qui serait obtenu. Nous pouvons corriger, ou laisser vos équipes le faire à partir du rapport.
Ce que vous recevez
Les livrables
- check_circleLe rapport, chaque faille avec sa reproduction pas à pas et sa correction
- check_circleLe classement par risque réel, pas par sévérité théorique d'outil
- check_circleLa liste des secrets à changer, avec la procédure de rotation
- check_circleUne contre-vérification après correction, pour attester que c'est fermé
La preuve
Où nous l'avons fait
Gextra
Depuis 2010Admissions, dossiers de soin, planning, facturation, applications mobiles. Un logiciel métier complet, en cours de migration écran par écran vers une technologie moderne, sans arrêter l'activité.
Lire le cas clientarrow_forward
Notre flotte
Depuis 2010Git, intégration continue, registre d'images, SSO, DNS, métriques, journaux, supervision : tout tourne chez nous, sur des briques libres. Pas parce que c'est militant — parce que ça tient mieux la charge, ça coûte dix fois moins, et ça ne s'arrête pas quand un fournisseur change d'avis.
Lire le cas clientarrow_forwardQuestions fréquentes
- C'est un test d'intrusion ?
- C'est un audit applicatif, avec accès au code — plus efficace pour trouver des failles qu'un test en aveugle, et beaucoup moins cher. Si vous avez besoin d'un test d'intrusion certifié pour une exigence contractuelle ou une assurance, nous vous orientons vers un cabinet spécialisé.
- Vous auditez une application que vous avez développée ?
- Nous le faisons en continu sur nos propres applications, avec des contrôles automatisés qui balayent tous les projets. Mais pour un audit qui engage, un regard extérieur au code vaut mieux — nous le disons plutôt que de vendre notre propre relecture.
- Et si vous trouvez quelque chose de grave ?
- Nous vous prévenons immédiatement, avant même la fin de l'audit, et nous proposons un correctif dans la journée si la faille est exploitable depuis internet. Le rapport complet peut attendre ; une porte ouverte, non.
Parlons de votre projet
Un échange de trente minutes suffit à savoir si nous sommes le bon prestataire. Nous répondons sous 48 heures, et nous disons non quand ce n'est pas pour nous.