Audits de sécurité pour applications web et boutiques en ligne

Nous testons applications web, API et boutiques WordPress ou WooCommerce comme le ferait un attaquant, examinons le code et la configuration du serveur, et vous remettons un rapport qui dit quoi corriger en premier. Après les corrections, nous testons à nouveau. Nous ne travaillons qu’avec l’autorisation écrite du propriétaire du système.

Quand un audit en vaut la peine

Les problèmes de sécurité se signalent rarement d’eux-mêmes. Un audit est généralement déclenché par un changement : un lancement, un départ, une question d’un partenaire.

Un développeur est parti, et vous ne savez pas quelles clés et quels accès sont partis avec lui
Le produit va être lancé, et personne ne l'a regardé avec les yeux d'un attaquant
Un partenaire, un investisseur ou un grand compte demande la preuve que la plateforme a été testée
La boutique tourne sur des dizaines de plugins, et une vulnérabilité vient d'être publiée pour l'un d'eux
Le produit repose sur un vieux framework que personne dans l'équipe ne veut toucher
Vous avez corrigé les problèmes d'un précédent audit et avez besoin qu'on confirme qu'ils sont réglés

Ce que nous vérifions

Test d'applications web

Test manuel de l’application et de sa logique métier : contrôle d’accès, traitement des entrées, envoi de fichiers, sessions, et les parcours où circulent de l’argent ou des données personnelles.

API et authentification

Connexion, réinitialisation du mot de passe, jetons et gestion des JWT, rôles et permissions. Nous vérifions si un utilisateur peut accéder aux données d’un autre en changeant un identifiant dans une requête.

WordPress et WooCommerce

Plugins et thèmes avec des vulnérabilités connues, accès d’administration, fichiers et configuration exposés, et logique de paiement : prix, codes promo et changements de statut des commandes.

Revue de code sécurité

Lecture du code et de son historique à la recherche de secrets dans le dépôt, de requêtes non sûres, de contrôles manquants et de bibliothèques obsolètes, y compris sur des stacks anciennes que personne n’a revues depuis des années.

Durcissement des serveurs

Règles SSH et pare-feu, ports ouverts, TLS, en-têtes de sécurité, droits sur la base de données et les fichiers, sauvegardes stockées hors du serveur et protection contre la force brute qui ne bloque pas votre propre bureau.

Retest

Une fois les constats corrigés par votre équipe ou la nôtre, nous testons à nouveau chacun d’eux et mettons à jour le rapport avec son statut.

Ce que nous ne faisons pas

Ces règles font partie de chaque accord et ne sont pas négociables.

Nous ne testons aucun système sans l'autorisation écrite de son propriétaire
Nous ne faisons pas de tests de charge ni de déni de service en production sans accord séparé
Nous ne partageons les constats qu'avec les contacts nommés dans l'accord
Nous ne conservons ni vos données ni les comptes de test une fois le travail terminé

Un rapport qui dit quoi corriger en premier

Une liste de deux cents alertes de scanner n’aide pas une équipe à décider quoi faire lundi. Notre rapport note la gravité de chaque constat selon CVSS, montre la preuve, comme la requête et la réponse qui démontrent le problème, explique comment le reproduire et indique comment le corriger. Le propriétaire reçoit une synthèse pour la direction en langage clair, et les développeurs un plan de correction classé par risque et par effort.

Là où se cachent en général les problèmes sérieux

Les scanners automatiques trouvent les versions obsolètes. Les problèmes qui permettent de prendre le contrôle de comptes sont en général ailleurs : une API qui renvoie la commande d’un autre client quand on change le numéro dans la requête, une clé de signature commitée dans le dépôt il y a des années, une route d’administration qui vérifie la connexion mais pas le rôle, un paiement qui fait confiance au prix envoyé par le navigateur, un fichier de sauvegarde oublié dans un dossier public. Les trouver demande une personne qui lit le code et essaie les parcours à la main, et c’est ainsi que nous testons.

Contrôle d'accès vérifié sur chaque requête sensible
Historique du dépôt passé au crible à la recherche de secrets et de clés
Logique de paiement et de commande testée à la main
Fichiers, endpoints et modes de débogage oubliés repérés

Retest et durcissement, pour que le rapport ne soit pas la fin

Un audit n’est rentable que si les constats sont traités. Après les corrections, nous retestons chaque constat et le marquons comme corrigé, partiellement corrigé ou toujours ouvert. Si vous le souhaitez, nos développeurs font eux-mêmes les corrections, et notre équipe serveurs durcit l’infrastructure : accès par clés uniquement, un pare-feu qui n’expose que ce qui doit être public, un TLS à jour, des utilisateurs de base de données séparés aux droits minimaux et des sauvegardes tenues à l’écart du serveur qu’elles protègent.

Comment se déroule un audit

Périmètre et autorisation

Nous convenons de ce qui est testé, d’où et quand, et le propriétaire du système signe une autorisation écrite. Vous fournissez des comptes de test et, pour une revue de code, l’accès au dépôt.

Tests

Nous cartographions l’application, la testons à la main et examinons le code et la configuration du serveur dans le périmètre convenu. Tout problème critique vous est signalé immédiatement, sans attendre le rapport.

Rapport

Vous recevez les constats notés CVSS, les preuves, les corrections, une synthèse pour la direction et un plan de correction, et nous les présentons à votre équipe.

Corrections

Vos développeurs ou les nôtres suivent le plan par ordre de risque.

Retest

Nous testons à nouveau chaque constat et remettons un rapport mis à jour avec le statut de chacun.

Ce que nous testons, et selon quels référentiels

Référentiels

Applications

Plateformes et stacks

Infrastructure

Formats de collaboration

Audit avec retest

Un périmètre fixe : tests, rapport et retest une fois que votre équipe a corrigé les constats.

Audit et corrections

Nous testons, corrigeons les constats dans le code et sur le serveur, et confirmons par un retest.

Revues régulières

Une revue avant les mises en production importantes ou selon un calendrier, souvent combinée avec la maintenance du site ou l’infogérance du serveur.

Témoignages

Nous traitons chaque client et son projet avec attention.

L’équipe Revol continue de renforcer les capacités de développement du client grâce à un travail de grande qualité et à un support fiable. Elle communique efficacement et fait preuve d’une solide compréhension des besoins et de l’activité du client.

Tomas

PDG (Yukon, Canada)

Le travail de Revol a pleinement répondu aux attentes et a satisfait le client. Leur approche nouvelle et leur disponibilité pour le support ont été de vrais atouts. On peut faire appel à eux pour disposer d’une équipe communicative et orientée client, qui aide à atteindre ses objectifs.

Andrey

PDG, Stellium (États-Unis)

Questions fréquentes

Avez-vous besoin de notre autorisation écrite ?

Oui, toujours. Le propriétaire du système signe une autorisation qui précise le périmètre, les adresses et les dates. Si le système tourne chez un hébergeur ou un fournisseur cloud, nous suivons aussi les règles de ce fournisseur en matière de tests de sécurité.

Les tests vont-ils casser notre site en ligne ?

Nous convenons des limites à l'avance. Quand c'est possible, nous testons sur une copie de préproduction avec le même code. En production, nous utilisons des comptes de test, évitons les actions destructrices et ne faisons pas de tests de charge sans accord séparé.

En quoi est-ce différent d'un scan de vulnérabilités automatique ?

Un scanner trouve les versions connues et les erreurs de configuration courantes, et nous utilisons aussi des scanners. Les constats les plus importants, comme un utilisateur qui lit les données d'un autre ou un prix modifié dans le navigateur, demandent une personne qui comprend l'application et la teste à la main.

Que recevons-nous exactement ?

Un rapport avec chaque constat noté selon CVSS, la preuve, les étapes de reproduction et la correction, une synthèse pour la direction et un plan de correction. Après le retest, vous recevez une version mise à jour avec le statut de chaque constat.

Pouvez-vous corriger ce que vous trouvez ?

Oui. Nos développeurs peuvent corriger le code et notre équipe serveurs durcir l'infrastructure. Certains clients préfèrent que leur propre équipe corrige et que nous vérifiions, ce qui fonctionne tout aussi bien.

Le retest fait-il partie de l'audit ?

Nous l'intégrons au périmètre dès le départ, car un audit sans retest vous laisse deviner si les corrections ont fonctionné. Le moment du retest dépend de la rapidité des corrections.

Comment traitez-vous nos données et les constats ?

Nous travaillons sous NDA, ne partageons les constats qu'avec les contacts nommés dans l'accord et supprimons données de test et accès à la fin du travail. Nous ne publions jamais le détail de ce que nous trouvons.

S'agit-il d'une certification ?

Non. Nous ne sommes pas un organisme de certification, et le rapport n'est pas un certificat de conformité. Il peut appuyer votre démarche de conformité et montre aux partenaires qui demandent une preuve de test ce qui a été vérifié, et comment.