Configuration, accès, API, données et dépendances : nous examinons votre application dans un périmètre convenu par écrit, puis nous classons chaque constat avec sa correction.
Interfacepages, formulaires
Périmètre convenu : examiné
Authentification et sessionsconnexion, sessions
Périmètre convenu : examiné
APIpoints d'entrée
Périmètre convenu : examiné
Donnéesstockage, fichiers
Périmètre convenu : examiné
Dépendances et services externesbibliothèques, services tiers
Périmètre convenu : services tiers : leurs intégrations seulement
Configuration et infrastructureserveur, hébergement
Périmètre convenu : examiné
Un espace client, un back-office ou une plateforme métier peuvent fonctionner parfaitement pour leurs utilisateurs et laisser passer ce que personne ne teste au quotidien.
Ce que voit l'utilisateurChaque client retrouve ses propres dossiers.
Ce que vérifie l'auditLe serveur refuse-t-il la demande d'un client sur le dossier d'un autre ?
Ce que voit l'utilisateurLe site s'affiche et répond normalement.
Ce que vérifie l'auditSes bibliothèques sont-elles encore maintenues, et à jour de leurs correctifs publiés ?
Ce que voit l'utilisateurLes documents se téléchargent depuis l'espace client.
Ce que vérifie l'auditRestent-ils accessibles sans connexion à qui connaît leur adresse ?
Ce que voit l'utilisateurLe paiement et les e-mails fonctionnent.
Ce que vérifie l'auditLes clés d'accès à ces services sont-elles stockées hors du code, et renouvelables ?
Les six strates de la coupe, dans le périmètre convenu avec vous : rien n'est examiné qui n'y figure pas.
01R1
Ce que voit l'utilisateur, et ce que l'application accepte de lui.
02R2
Nous vérifions les accès existants ; leur conception relève de la gestion des accès.
03R3
Pour voir comment une demande est contrôlée, niveau par niveau, suivez le parcours d'une requête.
04R4
Les mesures de protection des données sont une prestation distincte.
05R5
Les services tiers eux-mêmes ne sont pas examinés, seulement leur intégration. Si l'application confie des outils à des agents IA, leurs droits d'accès entrent dans le périmètre.
06R6
Le renforcement de la configuration relève de la sécurisation de l'infrastructure.
Scénario fictif : dans un espace client, un utilisateur connecté peut afficher la facture d'un autre client. Suivez le raisonnement de l'audit, puis comparez l'application avant et après correction.
Compte de test autorisé
Client A · Atelier Nord
Demande l'affichage d'une facture qui appartient à un autre client.
Contrôles côté serveur
Écart constaté
Facture B-204 affichée
Document de Maison Sud, visible depuis le compte d'Atelier Nord.
Étape 1 sur 5 · avant correction
Un client connecté ne voit que ses propres factures. Toute demande portant sur le document d'un autre compte doit être refusée par le serveur, quelle que soit la façon dont elle est formulée.
La règle attendue est établie avec vous au cadrage, à partir des rôles et des données de l'application.
Chaque forme d'évaluation répond à une question différente. Aucune ne garantit l'absence de vulnérabilité. Le code d'un smart contract n'entre dans aucune d'elles : c'est une démarche distincte, et nous expliquons comment préparer l'audit d'un smart contract.
| Forme d'évaluation | La question à laquelle elle répond | Ce qu'elle examine | Crawler Agency |
|---|---|---|---|
| Revue de configuration | Les réglages exposent-ils l'application ? | Paramètres du serveur, de l'hébergement, des en-têtes et des secrets, comparés aux bonnes pratiques. | Nous la réalisons |
| Revue de code | Le code applique-t-il les bonnes règles ? | Lecture ciblée des parties sensibles : droits, validation des données, gestion des erreurs, appels externes. | Nous la réalisons, sur les parties convenues |
| Analyse de vulnérabilités | Des faiblesses connues sont-elles présentes ? | Composants et versions comparés aux vulnérabilités publiées ; vérifications non destructives sur des comptes de test. | Nous la réalisons, dans le périmètre autorisé |
| Audit applicatif | Où en est la sécurité de l'application, et que corriger d'abord ? | Les trois examens précédents, combinés selon le périmètre écrit, avec un rapport classé par priorité. | C'est la prestation de cette page |
| Test d'intrusion spécialisé | Que peut atteindre un attaquant en un temps donné ? | Simulation d'attaque bornée, menée par des spécialistes, pour démontrer ce qui est réellement exploitable. | Nous vous orientons vers un prestataire spécialisé |
| Audit indépendant ou certifiant | Puis-je présenter un rapport opposable à un tiers ? | Évaluation selon un référentiel, par un organisme reconnu, opposable à un client, un assureur ou une autorité. | Hors de notre offre |
Systèmes, environnements, fonctionnalités et rôles concernés sont listés par écrit, avec l'accord du propriétaire de l'application.
Revue de configuration, revue de code ciblée et vérifications non destructives, sur des comptes de test, aux dates convenues.
Chaque constat est documenté avec ses éléments de preuve et sa priorité ; un constat critique vous est signalé sans attendre le rapport.
Un rapport classé par priorité, une recommandation par constat, et une réunion pour le présenter à vos équipes techniques et à la direction.
Chaque constat porte une priorité justifiée : conséquences possibles, facilité d'accès, effort de correction. Vous décidez de l'ordre et du calendrier.
Les corrections ne sont pas comprises dans l'audit. Vos équipes peuvent les réaliser à partir des recommandations, ou nous pouvons les prendre en charge sur un devis distinct : sécurisation des applications et des API, ou évolutions confiées à notre pôle développement digital.
Une vérification ciblée des corrections peut être prévue, selon le projet et le périmètre retenu. Dans la durée, le suivi de sécurité et l'hébergement et la maintenance prennent le relais.
Moment opportun, test d'intrusion, accès à prévoir, priorités, budget, limites.
Avant une mise en ligne ou une ouverture à de nouveaux utilisateurs, après une évolution importante (paiement, espace client, API ouverte à des partenaires), lors de la reprise d'une application, ou à la demande d'un client ou d'un assureur. Un audit ponctuel ne remplace pas un suivi régulier : il fixe un point de départ.
Quand il faut démontrer ce qu'un attaquant peut réellement atteindre en un temps donné, ou remettre à un tiers un rapport établi selon un référentiel. L'audit cherche à couvrir largement les faiblesses de l'application ; le test d'intrusion cherche à prouver leur exploitation. Pour un test d'intrusion avancé, nous vous orientons vers un prestataire spécialisé.
L'accord écrit du propriétaire de l'application, un environnement de test si possible, des comptes de test pour chaque rôle, l'accès au code et à la configuration dans le périmètre convenu, et un interlocuteur technique joignable. Sans accès au code, l'audit reste possible mais plus limité : le périmètre écrit le précise.
Chaque constat est évalué selon ses conséquences possibles (données exposées, actions permises, nombre d'utilisateurs concernés), la facilité d'y accéder et l'effort de correction. La priorité est justifiée par écrit, constat par constat ; aucun score automatique ne la remplace, et vous gardez la décision du calendrier.
Le budget dépend du périmètre : nombre de fonctionnalités et de rôles, API, accès au code, environnements à examiner. Il est fixé après un premier échange, avant de commencer. Les corrections ne sont pas comprises : vos équipes ou les nôtres les réalisent sur un devis distinct, et une vérification ciblée peut être prévue selon le projet.
Non. Un audit établit l'état d'une application à une date et dans un périmètre donnés, et réduit les risques en les rendant visibles. Aucun système n'est invulnérable : de nouvelles vulnérabilités sont publiées en continu et le code évolue. C'est pourquoi les corrections et un suivi de sécurité dans le temps comptent autant que l'audit.
Décrivez votre application, son hébergement et ce qui vous préoccupe. Nous vous proposons un périmètre d'audit écrit : ce qui sera examiné, comment, et ce qui ne le sera pas.
| Constat | Priorité | Recommandation | Correction | Vérification |
|---|---|---|---|---|
| C-01 · APIFactures d'autres comptes accessibles | 1 | Vérifier l'appartenance de chaque document côté serveur | Faite, par vos équipes | Vérifiée |
| C-02 · SessionsSessions qui n'expirent jamais | 2 | Durée limitée et déconnexion de tous les appareils | En cours, devis distinct | À vérifier |
| C-03 · DépendancesBibliothèque d'images plus maintenue | 2 | Remplacer par une bibliothèque maintenue | À planifier | À vérifier |
Premier échange pour cadrer le périmètre, réponse sous 24 à 48 heures ouvrées. Les corrections font l'objet d'un devis distinct de l'audit.
Vos cookies, votre choix
Avec votre accord, nous mesurons la fréquentation du site pour l'améliorer.Sans accord, aucun cookie de mesure n'est déposé.Modifiable à tout moment : « Gestion des cookies », en bas de page. En savoir plus