Les 10 premiers — il en reste 10 à $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
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 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.

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
10 restants$100
Les 10 suivantsRapports 11–20
$149
Les 20 suivantsRapports 21–40
$199

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

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 ?

La production, sauf indication contraire. Vous pouvez lister en texte libre ce que vous préférez ne pas voir touché, et c'est respecté.

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 ?

Vous recevez quand même les deux rapports, qui documentent ce qui a été testé et ce qui a tenu. C'est un résultat que vous pouvez montrer à un client grand compte pendant sa revue de sécurité.

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 ?

Il ne se passe rien. La run vous attend, indéfiniment. Tester sans domaine vérifié et sans autorisation signée n'est pas quelque chose qu'on saute.

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