Revue de sécurité du code

Un audit vu de l’extérieur teste les portes visibles. Lire le code, c’est ouvrir le capot et repérer ce qui se cache à l’intérieur : un secret oublié, une entrée mal filtrée, une dépendance vulnérable. FastSolve examine votre code à la source, avant qu’un attaquant n’y trouve la faille.

Cette prestation demande un accès en lecture à votre code et une autorisation écrite. Le code reste chez vous, rien n’est conservé ni partagé.

Cette prestation est facturée sur devis accepté. Un audit livre un constat et non un outil : la règle habituelle, tester avant de payer, ne peut pas s’y appliquer. Le devis annonce à l’avance ce qu’il contient et jusqu’où va l’analyse.

Ce qui se cache dans le code

Certaines failles ne laissent aucune trace visible de l’extérieur. Elles attendent, écrites en clair dans les fichiers, jusqu’à ce que quelqu’un mette la main dessus.

• Un mot de passe, une clé d’accès ou un jeton écrit directement dans le code, parfois copié sans le vouloir dans un dépôt partagé.
• Une entrée utilisateur qui arrive jusqu’à la base de données sans contrôle, ouvrant la voie à une injection.
• Une brique externe restée en version ancienne, dont la faille est publiquement connue et documentée.
• Un bout de code repris d’un forum, qui fonctionne, mais qui traîne avec lui une vulnérabilité connue.

Ces défauts ne se devinent pas depuis la page d’accueil. Ils se lisent, ligne à ligne, là où ils ont été écrits.

Ce que couvre la revue

La lecture cible les endroits où une erreur de code devient une faille de sécurité.

1. Les secrets et la configuration

On traque les identifiants, clés et jetons écrits en dur, et on vérifie que la configuration sépare bien ce qui est public de ce qui doit rester caché.

Situation type. Une clé d’accès à un service payant dormait dans un fichier suivi par le dépôt. La sortir du code et la remplacer a fermé une porte que personne n’avait vue.

2. Le traitement des entrées

On suit le chemin des données envoyées par l’utilisateur jusqu’à la base ou l’affichage, pour s’assurer qu’aucune ne s’exécute là où elle ne devrait qu’être lue.

Situation type. Une requête à la base était construite en collant directement la saisie de l’utilisateur. La réécrire en requête préparée a supprimé le risque d’injection.

3. La logique des accès

On vérifie que les contrôles de droits sont bien côté serveur, et pas seulement masqués à l’écran, car ce qui est caché à l’affichage reste atteignable autrement.

Situation type. Un bouton d’administration était simplement masqué pour les comptes ordinaires, mais l’action restait accessible en la sollicitant directement. Un contrôle côté serveur a rétabli la barrière.

4. Les dépendances

On liste les briques externes et leurs versions, on repère celles dont une faille est connue, et on indique lesquelles mettre à jour en priorité.

Situation type. Un composant d’envoi d’e-mails traînait plusieurs versions de retard, avec une faille publiée. Sa mise à jour a pris quelques minutes, une fois le risque identifié.

Ce que la revue ne fait pas

Elle éclaire le code sous l’angle de la sécurité. Elle ne réécrit pas votre projet et ne juge pas vos choix techniques.

• Elle ne remplace pas l’audit vu de l’extérieur : les deux regards se complètent, l’un teste les portes, l’autre lit les serrures.
• Elle ne réécrit pas votre application. Elle signale les points à risque et la façon de les corriger, la correction restant un travail à part.
• Elle ne garantit pas l’absence totale de faille : aucune lecture ne le peut. Elle réduit fortement ce qui traîne de connu et d’évitable.
• Elle a besoin d’accéder au code. Sans lecture des sources, ce service n’a pas d’objet, et c’est l’audit externe qui convient.

Nous vous rendons une liste claire de ce qui mérite d’être corrigé, sans jargon inutile et sans dramatiser ce qui n’en vaut pas la peine.

Questions fréquentes

Dites-nous quel code vous aimeriez faire relire

Voir le déroulement d’un projet, du cadrage à la livraison
Voir l’ensemble des services FastSolve