Aller au contenu
SecureLaunch
fren
REF SL-2026-001
v1.0.0
Périmètre OWASP ASVS L1
Open source — licence MIT

Construit par un profil cybersécurité, pas par un growth hacker

Lancez un SaaS Pythonsans vous faire trouer.

SecureLaunch est le starter kit FastAPI secure-by-default : auth durcie (JWT + rotation + 2FA + argon2id), headers OWASP sur chaque réponse, et RGPD pré-câblé — le seul boilerplate FastAPI à le livrer testé et audité.

Voir le code sur GitHubLire l'audit de sécurité

FastAPI · SQLAlchemy 2 async · PostgreSQL · Stripe · Docker + Caddy. De zéro à déployé en ~30 min.

$ unzip securelaunch-1.0.0.zip
Archive: securelaunch-1.0.0.zip
$ cd securelaunch
$ uv sync
Resolved 34 packages in 1.2s
Installed 34 packages in 890ms
$ alembic upgrade head
INFO [alembic.runtime.migration] Running upgrade -> e8b08e907e1a, initial schema
$ uvicorn app.main:app
INFO: Application startup complete.
INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
Figure 1 — Démonstration du kit dans un terminal
73
Tests automatisés
91 %
Couverture
ASVS L1
Audit
0 vuln.
pip-audit

Mesuré sur la v1.0.0 — vérifiable dans le dépôt, pas des promesses.

§1Ce que vous économisez

Vous ne payez pas du code. Vous payez des semaines de durcissement.

Vous ne payez pas pour du code que vous auriez pu écrire. Vous payez pour les semaines passées à durcir l'auth correctement, à ne pas vous tromper sur la rotation des tokens, et à ne pas découvrir un trou de sécurité en production. Voici le détail, module par module.

Base TJM 500 € — fourchettes indicatives.

  • Auth durcie — JWT 15 min + refresh rotatif, détection de réutilisation, Argon2id, lockout progressif, TOTP chiffré

    Temps DIY
    2–3 semaines
    Coût DIY
    5 000–7 500 €
    SecureLaunch
    Inclus

  • Webhooks Stripe signés + idempotents (claim-first), portail client

    Temps DIY
    1–2 semaines
    Coût DIY
    2 500–5 000 €
    SecureLaunch
    Inclus

  • RGPD — export Art. 20, effacement Art. 17, registre de consentements, docs légales FR/EN

    Temps DIY
    1–2 semaines
    Coût DIY
    2 500–5 000 €
    SecureLaunch
    Inclus

  • Baseline OWASP — headers CSP/HSTS…, rate-limiting, CORS strict, CSRF, logs sans PII

    Temps DIY
    1 semaine
    Coût DIY
    2 500 €
    SecureLaunch
    Inclus

  • Déploiement durci — Docker non-root, Caddy TLS auto, CI ruff/pytest/pip-audit/gitleaks

    Temps DIY
    1 semaine
    Coût DIY
    2 500 €
    SecureLaunch
    Inclus

  • Total si vous le construisez vous-même

    Temps DIY
    6–9 semaines
    Coût DIY
    ≈ 15 000–22 500 €
    SecureLaunch
    Open source — MIT

Total si vous le construisez vous-même

≈ 15 000–22 500 €

SecureLaunch

Open source

MIT

En réalité, la plupart des développeurs ne passent pas ces semaines : ils sautent la sécurité. Ce kit neutralise d'emblée les 4 classes de failles qu'on retrouve dans les audits de SaaS early-stage — vol de refresh token, énumération de comptes, brute-force, webhooks Stripe rejouables.

Ces chiffres sont des estimations destinées à situer l'ordre de grandeur du travail évité. Aucune garantie de résultat ni de conformité automatique n'est promise : la sécurité et la conformité dépendent aussi de votre exploitation.

§2Le kit

Six modules, chacun passé au crible d'une revue adversariale.

Six modules, chacun testé, documenté et passé au crible d’une revue de sécurité adversariale écrite.

  1. Auth durcie

    JWT access + refresh opaques avec rotation et détection de vol (révocation de toute la famille), hachage argon2id, reset & vérification email à usage unique, verrouillage brute-force progressif, 2FA TOTP optionnelle (secret chiffré au repos).

  2. RGPD pré-câblé

    Export de données (portabilité), droit à l'effacement (avec anonymisation du journal d'audit), registre de consentements append-only, politiques de confidentialité & CGV types FR + EN, bannière de consentement.

  3. Paiements Stripe

    Checkout abonnements et paiement unique, webhooks signés et idempotents (claim-first, race-safe), portail client, gestion des échecs de paiement.

  4. Données

    PostgreSQL + SQLAlchemy 2 async + Alembic. Modèles User / Subscription / Payment / AuditLog / Consent prêts à l’emploi, migrations et seeds de dev.

  5. Signature sécurité

    Headers OWASP sur toutes les réponses, rate-limiting, CORS restrictif, CSRF double-submit, logs structurés sans donnée personnelle.

    • CSP
    • HSTS
    • nosniff
    • X-Frame-Options
    • Referrer-Policy
    • Permissions-Policy
    • COOP/CORP

  6. Déploiement

    Dockerfile multi-stage durci (non-root, slim), docker-compose avec Caddy (TLS auto), CI GitHub Actions complète.

$ docker compose up -d
[+] Running 3/3
$ docker compose ps
NAME IMAGE STATUS PORTS
app securelaunch-app Up 12 seconds (healthy) 8000/tcp
db postgres:16 Up 12 seconds (healthy) 5432/tcp
caddy caddy:2 Up 12 seconds (healthy) 0.0.0.0:443->443/tcp
Figure 2 — docker compose ps

Pipeline CI

ruffpytest · cov 91 %pip-auditgitleaks

Inclus aussi : 73 tests automatisés (couverture 91 %, > 95 % sur l'auth), une revue de sécurité adversariale écrite par module, un audit final adversarial interne OWASP ASVS niveau 1 (0 finding Critique / Haut restant), et une doc « de zéro à déployé en 30 minutes ».

§3Sous le capot

Le chemin d'une requête — et ce qui l'attend à chaque couche.

De l'entrée TLS jusqu'à PostgreSQL : chaque couche de la stack embarque sa défense, câblée par défaut, pas ajoutée après coup.

Edge

Caddy (TLS auto)

AttaqueMITM, downgrade TLS

DéfenseTLS automatique + HSTS : la connexion en clair n’existe pas.

Application

FastAPI middleware

AttaqueXSS, flood, clickjacking

DéfenseHeaders OWASP sur chaque réponse (CSP, X-Frame-Options…), rate-limiting global + par route, CORS sans wildcard, CSRF double-submit.

Auth

Service Auth

AttaqueCredential stuffing, vol de token

DéfenseArgon2id, verrouillage progressif, refresh rotatif + détection de réutilisation avec révocation de toute la famille, TOTP chiffré au repos.

Paiements

Webhooks Stripe

AttaqueWebhooks forgés, replay

DéfenseSignature vérifiée + idempotence claim-first : un événement ne paie qu’une fois.

Données

PostgreSQL + SQLAlchemy 2 async

AttaqueInjection SQL, fuite de données

DéfenseRequêtes paramétrées via l’ORM, migrations Alembic, logs structurés sans PII.

§4Audit interne adversarial — OWASP ASVS L1

Audité comme si on voulait le trouer.

Chaque module a subi une revue de sécurité adversariale écrite. Puis une revue finale adversariale a re-vérifié le code réel ligne à ligne, mappée sur OWASP ASVS niveau 1 — sans confiance accordée aux revues précédentes. Méthode et findings sont publiés intégralement dans le kit.

Les findings résiduels (Moyens / Faibles) relèvent de la défense-en-profondeur et sont documentés publiquement avec leurs conditions d'exploitation. En cybersécurité, la crédibilité vaut mieux qu'un argumentaire lisse.

Lire l'audit complet
security-reviews/AUDIT_FINAL.mdPérimètre — OWASP ASVS L1

4 findings Hauts trouvés en développement — corrigés et re-vérifiés :

  • H1Contournement de la désactivation 2FA via /2fa/setupCORRIGÉ
  • H2Absence de verrou brute-force sur le second facteur TOTPCORRIGÉ
  • H3Headers OWASP absents des réponses 429CORRIGÉ
  • H4entrypoint.sh absent de l'image DockerCORRIGÉ

Trouver des failles pendant le développement n'est pas un échec : c'est le but de la méthode. Les cacher le serait.

SévéritéFindings restants
Critique0
Haute0
Moyenne4
Faible5
Info2

Verdict

PRÊT POUR LA VENTE

0 CRITIQUE · 0 HAUT

§5Qui construit ça

Construit par un ingénieur sécurité, pas par un growth hacker.

SecureLaunch est construit en public : chaque module est développé, puis attaqué par écrit — et tout est publié, y compris ce qui a été trouvé.

  • 01

    Une revue adversariale par module

    Chaque module a subi une revue de sécurité adversariale documentée : le code est attaqué comme le ferait un adversaire, et le résultat est écrit noir sur blanc.

  • 02

    Les findings sont publiés — rien de caché

    Y compris les 4 findings High trouvés en développement, corrigés puis re-vérifiés. Les taire aurait été plus confortable ; ce n’est pas la méthode.

  • 03

    Le code et l’audit, pas le marketing

    Pas d'équipe marketing derrière : le code et l'audit sont l'argument. Ce que cette page affirme, le dépôt le prouve.

Mohamed Fouad TAIWO — Ingénieur sécurité

§6RGPD

Le seul boilerplate FastAPI avec le RGPD pré-câblé.

Dès que vous vendez en Europe, le RGPD n'est pas une option. Les boilerplates FastAPI dominants l'ignorent — SecureLaunch le livre câblé, testé et documenté.

  • Export de données

    Portabilité complète : un endpoint authentifié renvoie toutes les données de l’utilisateur en JSON.

  • Droit à l'effacement

    Suppression de compte en cascade avec anonymisation du journal d'audit, re-authentification exigée.

  • Registre de consentements

    Append-only : chaque consentement est horodaté et conservé, jamais modifié ni supprimé.

  • Docs légales types FR/EN

    Politique de confidentialité et CGV en français et en anglais, plus une bannière de consentement.

  • GET/gdpr/exportExport des données — Art. 20
  • DELETE/gdpr/accountEffacement + anonymisation des logs — Art. 17
  • GET/gdpr/consentsRegistre des consentements

200 OK - application/json

{
"user": {
"email": "marie@exemple.eu",
"created_at": "2026-01-12T09:41:07Z"
},
"consents": [
{ "kind": "terms_of_service", "granted_at": "2026-01-12T09:41:07Z" },
{ "kind": "marketing_email", "granted_at": "2026-02-03T18:22:41Z" }
],
"payments": [
{ "amount": "29.00", "currency": "EUR", "status": "succeeded" },
{ "amount": "29.00", "currency": "EUR", "status": "succeeded" }
],
"exported_at": "2026-07-17T10:05:33Z"
}
Figure 3 — API RGPD — openapi.json (extrait)

Modèles livrés

privacy-policy.fr.mdprivacy-policy.en.mdcgv.fr.mdcgv.en.md

Les documents juridiques fournis sont des modèles à adapter à votre activité. Ils ne constituent pas un avis juridique.

§7Comparatif

SecureLaunch vs. boilerplates JS/Next.js

Comparaison factuelle. Les boilerplates JS dominants (type ShipFast et clones) sont d'excellents produits pour aller vite côté JavaScript — ils visent simplement un autre public et d'autres priorités. Voici les axes où le choix diffère réellement.

SecureLaunch vs. boilerplates JS/Next.js
AxeSecureLaunchBoilerplates JS/Next.js typiques
Langage / stackPython / FastAPI (async)JavaScript / Next.js
Sécurité par défautHeaders OWASP, rate-limit, CSRF, CORS, logs sécu — de baseVariable ; souvent laissé à l’intégrateur
RGPD pré-câbléExport + effacement + consentements + docs FR/ENRarement fourni
2FATOTP inclus (secret chiffré au repos)Selon le fournisseur d'auth externe
Tests & audit73 tests, 91 % couverture, audit ASVS L1Rarement mis en avant / documenté
LicenceOpen source (MIT), usage commercial autoriséLicence commerciale propriétaire, souvent à vie

Les caractéristiques des produits tiers évoluent et varient d'un kit à l'autre : vérifiez toujours l'offre exacte au moment de votre achat. Cette table décrit des tendances générales, pas un produit concurrent nommé en particulier.

§8En toute honnêteté

Pour qui — et pour qui ce n’est pas.

C’est pour vous si…

  • Vous êtes développeur Python solo / indie et voulez lancer un SaaS maintenant, sans réécrire l’auth et la sécurité de zéro.
  • Vous ciblez le marché européen et le RGPD n’est pas négociable.
  • Vous préférez FastAPI / async / PostgreSQL à un stack JavaScript.
  • Vous savez lire du code Python et faire tourner Docker : une base de production solide et modifiable, pas du no-code.

Passez votre chemin si…

  • Vous cherchez un template front / Next.js clés en main : SecureLaunch est un backend FastAPI.
  • Vous voulez du no-code ou un générateur d’UI.
  • Vous avez besoin de MySQL ou de multi-tenant natif : le kit est écrit pour PostgreSQL et mono-tenant.
  • Vous attendez un support commercial ou des garanties : le kit est fourni en l’état, sans garantie (licence MIT).

FAQ

Questions fréquentes

Parce qu'énormément de développeurs indépendants pensent et livrent en Python (data, IA, back-end, scripts), et que l'écosystème des boilerplates sérieux y est bien plus pauvre qu'en JS. FastAPI apporte l'async natif, la validation stricte via Pydantic 2 et l'OpenAPI générée. SecureLaunch vise ce public-là, avec la sécurité comme priorité de premier ordre.

Rien. SecureLaunch est open source sous licence MIT : le code, les revues de sécurité et l'audit ASVS L1 sont publics et réutilisables, y compris dans un projet commercial. Le dépôt est accessible via documentation.

Licence MIT : usage libre, y compris commercial, modification et redistribution autorisées, à condition de conserver la mention de copyright. Aucune garantie n'est fournie. Les documents juridiques livrés (politique de confidentialité, CGV) restent des modèles à adapter et ne constituent pas un avis juridique.

Par le dépôt Git : git pull puis rebuild. En Docker, les migrations Alembic se réappliquent au démarrage. Les dépendances sont épinglées (uv.lock) et auditables avec pip-audit. Les correctifs de sécurité restent la priorité.

Le kit est conçu pour être autonome : doc « 30 min », un guide par module, guides de déploiement (VPS, Scaleway, Railway/Render) et une FAQ technique détaillée. Les questions et rapports de bug passent par les issues du dépôt ; pour le reste, écrivez à support@securelaunch.dev.

Oui. Les issues et pull requests sont bienvenues, en particulier sur la sécurité : si vous trouvez une faille, ouvrez un rapport privé plutôt qu'une issue publique (voir SECURITY.md). Les findings résiduels de l'audit sont documentés et constituent une bonne porte d'entrée.

Arrêtez de recâbler l'auth à chaque projet.

Partez d'une base FastAPI durcie, testée et pensée pour le marché européen. Concentrez-vous sur votre produit, pas sur les trous de sécurité.

Voir le code sur GitHubÉcrire à l'auteur