Une ligne de code. Dix SDK. N’importe quelle stack.
Ajoutez Defenso à votre app en quelques secondes et le pare-feu managé et les limites de débit s’activent aussitôt. Node, Python, PHP, Go, Ruby et plus, sans fichier de config, sans signature à maintenir, et ça reste toujours en marche en cas de panne.
- Dix SDK par framework
- Pare-feu actif aussitôt
- Reste ouvert en cas de panne
- ~4 ms par requête
Une ligne de code, et la couche de sécurité est active.
La plupart des outils de sécurité vous demandent de modifier le DNS, de lancer un agent ou de faire transiter le trafic par un proxy avant la moindre protection. Le SDK Defenso ne fait rien de tout cela. Vous installez un paquet, ajoutez une ligne à votre app, et les requêtes sont inspectées en cours de traitement, avant même d’atteindre vos routes : un WAF managé, des limites de débit et de la détection de bots, sans aucune infrastructure à monter. Cette page explique comment se déroule l’installation et pourquoi elle ne vous gêne jamais.
S’intègre au framework que vous utilisez déjà.
Le SDK se branche sur la couche middleware de votre app : rien de nouveau à apprendre. La politique de sécurité est diffusée par Defenso et reste à jour toute seule, vous ne touchez jamais une règle. Lancez une commande pour détecter votre framework et le câbler, ou ajoutez quelques lignes vous-même.
Lancez npx @defen.so/init : il détecte votre framework, installe le bon SDK et câble le middleware dans le bon fichier. Ou copiez le snippet de votre stack et ajoutez-le à la main, comme vous préférez.
Si Defenso est un jour injoignable, chaque requête passe et votre app continue de servir. Elle continue de servir tout du long ; seules nos mises à jour de politique en direct s’interrompent jusqu’à notre retour. Cela ajoute environ quatre millisecondes par requête.
Node et Next.js, Python pour FastAPI, Django et Flask, PHP pour Laravel et Symfony, Go, Ruby on Rails, et un middleware edge pour Vercel et Cloudflare Workers. La même idée en une ligne partout.
Un SDK de sécurité qui respecte votre app.
Le chemin le plus rapide, c’est une seule commande : npx @defen.so/init détecte votre framework, installe le bon SDK, câble le middleware dans le bon fichier et écrit un stub DEFENSO_TOKEN dans votre .env. Il connaît la convention de chaque framework (middleware Next.js, bootstrap Laravel, add_middleware de FastAPI, app.use d’Express, Rails, chi, gin, axum, Spring, ASP.NET) pour vous éviter d’éditer le boilerplate à la main. Dix runtimes sont couverts : Node, Bun, Deno, PHP, Python, Go, Ruby, Rust, Java et .NET.
Le SDK s’exécute à l’intérieur de votre application : un contrôle ajoute environ 4 millisecondes, sans saut par un proxy, sans bascule DNS ni agent à maintenir en vie. Il inspecte chaque requête au regard de règles WAF managées, applique des limites de débit par route et par IP, et repère les bots, puis il autorise, bloque ou trompe, et diffuse le verdict vers votre tableau de bord. Vous ajoutez du code, pas de l’infrastructure.
Chaque SDK Defenso reste ouvert en cas de panne. Si l’API Defenso devient un jour injoignable, le SDK autorise la requête et votre app continue de servir le trafic : vous perdez la protection pendant notre incident, jamais la disponibilité. C’est un choix délibéré : la sécurité ne doit jamais devenir le point de défaillance unique qui met votre site à terre. Un cache de politique de 24 heures maintient les règles en fonctionnement pendant les brèves coupures réseau.
Questions fréquentes.
Tout ce qu’on demande avant de se lancer. Encore un doute ? On est à un message.
Lancez npx @defen.so/init dans votre projet. Il détecte le framework, installe le SDK correspondant, câble le middleware dans le bon fichier et ajoute un stub DEFENSO_TOKEN à votre .env. Collez ensuite votre jeton depuis app.defen.so/developer. Si vous préférez voir le diff d’abord, chaque langage dispose d’un snippet manuel d’une ligne dans la doc.
Dix langages : Node, PHP, Python, Go, Ruby, Rust, Java et .NET, avec un câblage adapté à chaque framework pour Next.js, Nuxt, SvelteKit, Astro, Express, Fastify, FastAPI, Django, Laravel, Symfony, Rails, chi, gin, axum, Spring et ASP.NET. Le CLI installe le bon paquet et le câble comme chaque framework l’attend.
Non. Le SDK s’exécute en cours de traitement dans votre app : aucune bascule DNS, aucun saut par un proxy, aucun agent à installer. Un contrôle de requête ajoute environ 4 millisecondes. Les sites du plan Business peuvent, en option, ajouter un WAF edge par CNAME pour une protection sans code, mais le chemin SDK ne demande aucun changement d’infrastructure.
Le SDK reste ouvert en cas de panne : si notre API est injoignable, il autorise la requête et votre app continue de servir le trafic. Vous perdez la protection pendant l’incident, pas la disponibilité. Un cache de politique de 24 heures maintient aussi les règles en fonctionnement pendant les brèves coupures réseau, si bien que la sécurité n’est jamais un point de défaillance unique pour votre site.
L’installeur écrit un placeholder DEFENSO_TOKEN dans votre .env ; vous copiez le vrai jeton depuis app.defen.so/developer et vous le collez. Le jeton est lu depuis l’environnement à l’exécution et n’est jamais codé en dur, donc il reste hors de votre code source et de vos commits.
Ajoutez de la sécurité en une ligne.
Gratuit pour démarrer, sans carte. Récupérez votre jeton, lancez la commande, et le pare-feu managé est en ligne.