Aller au contenu
Les 10 premiers — il en reste 5 à $100

Découvrez ce qu'un attaquant trouverait, pour $100

Un humain entre volontairement dans votre application web, puis vous remet deux fichiers : un rapport HTML qui explique chaque faille, et un rapport Markdown que votre agent de code transforme directement en correctifs. Dans les 48 heures après l'autorisation signée.

Aucun abonnement. Aucun compte à créer avant — l'email qui paie devient votre compte.

  • Manuel, pas un scanner
  • Un domaine, un paiement
  • Livré en 48h
  • Autorisation signée d'abord

18 applications auditées à ce jour. 13 avaient une faille critique ou élevée. Aucune n'est ressortie vide.

security-report.html
Security auditapp.yourcompany.com
1Critical
2High
1Medium
critical
Any member can read another organization's invoicesGET /api/orgs/:id/invoices
high
Stripe webhook accepts unsigned payloadsPOST /api/webhooks/stripe
high
Password reset token stays valid after useauth/reset-password.ts
medium
No rate limit on the sign-in endpointPOST /api/auth/sign-in
Les résultats

18 applications testées. 13 avaient une faille critique ou élevée.

Tous les audits menés à ce jour, comptés sur le premier rapport complet de chaque application. Aucune n'est ressortie propre — et c'est la partie que les fondateurs ne croient jamais tant que ce n'est pas leur application.

applications auditées
18
failles confirmées
133
classées critiques
17
application sans aucune faille
0

Un échantillon de ce qui a réellement été trouvé

  • CritiqueSupprimer toutes les conversations d'une organisation — sans être connecté
  • CritiquePrix et nombre de crédits décidés par le client au paiement
  • CritiqueLire les clés d'API de n'importe quelle autre organisation
  • CritiqueToute la table utilisateurs lisible sans authentification
  • CritiquePassage gratuit au plan payant par mass-assignment
  • ÉlevéeOTP de connexion brute-forçable, jusqu'à la prise de compte
  • ÉlevéeXSS stocké sur les pages de profil publiques
  • ÉlevéeApplication payante téléchargeable sans aucun contrôle de licence

Chaque faille ci-dessus a été confirmée en l'exploitant, puis remontée au propriétaire et corrigée. Les noms de domaine ne sont jamais publiés — le vôtre ne le sera pas non plus.

Le problème

Votre scanner a trouvé 200 problèmes. Un attaquant n'en a besoin que d'un.

Les outils automatiques repèrent très bien les en-têtes manquants et les paquets obsolètes. Ils n'ont jamais trouvé l'endpoint qui renvoie les données d'un autre client, parce que ce bug n'existe que dans votre logique métier — et personne n'a écrit de signature pour votre métier.

Les scanners testent le framework

Ils savent à quoi ressemble WordPress. Ils ne savent pas que votre route de facturation fait confiance à un id venu de l'URL.

Les agences annoncent 10k et 3 semaines

Un appel de cadrage, un devis, un kick-off. Le temps que ça démarre, vous avez déployé quarante commits.

Alors rien n'est testé

L'application part en production avec de vraies données clients et, pour toute sécurité, de l'espoir.

Qui teste

Un développeur, pas une agence

Je m'appelle Melvyn. Je construis des applications web, et j'entre dans celles des autres à la main. Rien n'est sous-traité et aucun junior n'est mis sur votre dossier — la personne qui lit votre code est celle qui signe le rapport.

Je suis développeur logiciel, pas pentesteur professionnel. Je ne possède ni diplôme ni certification professionnelle en cybersécurité. Ce service est une revue de sécurité indépendante, pas un audit certifié ni une certification de conformité.

  • Chaque faille atteinte avant d'être écrite
  • Votre domaine n'est jamais cité publiquement
  • Vous pouvez tout arrêter en un message
Ce que vous recevez

Deux rapports, parce que deux lecteurs différents doivent agir dessus

Un PDF que personne ne rouvre n'est pas un audit de sécurité. Vous recevez un fichier pour comprendre le problème et un fichier pour le corriger.

Le rapport HTML, pour vous

Chaque faille écrite pour un humain : ce que c'est, comment on y arrive, ce qu'un attaquant en tire et à quel point c'est grave. Classées, pour savoir quoi corriger lundi matin.

security-report.html
Security auditapp.yourcompany.com
1Critical
2High
1Medium
critical
Any member can read another organization's invoicesGET /api/orgs/:id/invoices
high
Stripe webhook accepts unsigned payloadsPOST /api/webhooks/stripe
high
Password reset token stays valid after useauth/reset-password.ts
medium
No rate limit on the sign-in endpointPOST /api/auth/sign-in

Le rapport Markdown, pour votre agent

Les mêmes failles sous forme d'instructions précises, fichier par fichier. Donnez-le à Claude Code ou Cursor et les correctifs sont déjà cadrés — aucune traduction entre la prose et le patch.

security-report.md
## FIX-01 — Cross-tenant invoice read **Severity:** critical**File:** `src/routes/api/orgs/$id/invoices.ts:34` The handler trusts `params.id` and never checks that thesession's user belongs to that organization. ```diff- const org = await getOrg(params.id);+ const org = await getRequiredCurrentOrg(params.id);```
Couverture

Les familles de bugs qui vous coûtent vraiment des clients

Pas une checklist de conformité. Voici ce qui est sondé à la main sur votre application en fonctionnement, dans l'ordre où un attaquant s'y prendrait.

Contrôle d'accès cassé

Des identifiants d'objets modifiables, des rôles qu'on escalade, les lignes d'un autre client qu'on peut lire.

Authentification et sessions

Des tokens de réinitialisation réutilisables, du brute force sur l'OTP, des sessions qui survivent à la déconnexion.

Paiements et webhooks

Des webhooks non signés, des prix qui viennent du client, des plans passés en payant sans payer.

Injections et entrées

Injection SQL et NoSQL, injection de template, XSS stocké dans les champs que personne n'échappe.

Upload et stockage

Des types de contenu falsifiables, des buckets restés publics, des URLs signées qui n'expirent jamais.

Secrets et fuites

Des clés dans le bundle client, des erreurs trop bavardes, des endpoints internes joignables depuis l'extérieur.

Comment ça marche

De l'autorisation au rapport en 48 heures

Quatre étapes, toutes chez vous sauf la dernière.

  1. Étape 1

    Payez avec votre email

    Un paiement pour un rapport sur un domaine. Votre email devient votre compte au retour de Stripe — rien à configurer avant.

  2. Étape 2

    Prouvez que le domaine est le vôtre

    Un code envoyé sur une adresse de rôle du domaine, ou un enregistrement DNS TXT. Une minute, et c'est la seule façon de rester dans la légalité.

  3. Étape 3

    Signez l'autorisation

    Vous tapez votre nom et donnez l'autorisation de tester ce domaine précis. Rien n'est scanné avant que cette signature existe.

  4. Étape 4

    Recevez les deux rapports

    L'audit se fait à la main, pas au scanner. Les deux fichiers arrivent dans votre tableau de bord dans les 48 heures après votre signature.

Autorisation

Rien n'est touché avant votre signature

Tester une application sans y être autorisé est un délit dans la plupart des pays. C'est pour ça que la partie ennuyeuse passe en premier, et qu'elle n'est pas contournable.

Vous prouvez le domaine

Un code sur une adresse de rôle, ou un enregistrement TXT que seul le propriétaire du domaine peut publier.

Vous signez le périmètre

Votre nom tapé, l'email de votre compte, la date, la version du document, conservés avec la run.

Vous pouvez tout arrêter

Un mot et les tests s'arrêtent. Tout ce que vous déclarez hors périmètre le reste.

Tarifs

Le prix monte à mesure que les rapports partent

C'est un tarif de lancement, et il ne bouge que dans un sens. Le palier auquel vous achetez est celui qui était en cours au moment du paiement.

Les 10 premiersRapports 1–10
5 restants$100
Les 10 suivantsRapports 11–20
$149
Les 20 suivantsRapports 21–40
$199

Une fois ce palier épuisé, le prix passe à $149.

Ce que le paiement achète

Vous pouvez demander un remboursement intégral avant de signer l'autorisation de test. Après signature, vous payez le temps d'audit, pas un quota de failles. Même si l'application tient, les deux rapports sont livrés ; un rapport sans faille demande le même travail et n'est pas remboursable.

FAQ

Les questions à poser avant

C'est un scanner automatique ?

Non. Les scanners produisent le bruit que vous ignorez déjà. L'audit est mené à la main sur votre application en fonctionnement, et chaque faille du rapport a été atteinte avant d'être écrite.

Vous avez besoin de quoi de ma part ?

Un domaine, la preuve qu'il vous appartient, et une signature. Si une partie de l'application est derrière un login, vous pouvez ajouter un compte de test jetable pendant l'onboarding ; sinon un compte est créé via votre propre inscription.

Vous testez la préprod ou la production ?

Vous choisissez la préproduction ou la production pendant l'onboarding ; la préproduction est le choix par défaut le plus sûr. L'autorisation signée fige l'environnement, les actifs, les exclusions et les consignes avant tout test.

Est-ce que ça va faire tomber mon application ?

Non. C'est un audit manuel, pas un test de charge. Pas de trafic volumétrique, pas de test de déni de service, aucun payload destructif sur les données de production.

Et si vous ne trouvez rien — je suis remboursé ?

Avant signature, vous pouvez demander un remboursement intégral. Après signature et planification de l'audit, non : vous payez le temps de test, pas un nombre de failles. Les deux rapports documentant ce qui a été testé restent dus.

Je peux faire auditer un deuxième domaine ?

Oui — c'est un deuxième achat. Un paiement donne un rapport sur un domaine, et il n'y a aucun abonnement à résilier.

Et si je ne vérifie jamais mon domaine ?

Rien n'est testé. La mission non signée vous attend et reste intégralement remboursable depuis votre tableau de bord.

Vous le saurez de toute façon. Autant par un rapport.

Un paiement, un domaine, les deux rapports dans les 48 heures après autorisation.

Paiement sécurisé par Stripe$100 une fois, rien après