Rate limiting d’API & un WAF managé.
Le rate limiting d’API automatique plafonne les abus par route, par IP et par compte, et un WAF managé de 50k+ règles bloque injection SQL, XSS, SSRF et bots scanners. Réglé pour être non bloquant : vos vrais utilisateurs ne rencontrent jamais de fausse alerte. Chaque requête reçoit un verdict auditable, la règle, la charge utile, la raison. S’installe en une ligne et fait toujours du fail-open.
- Rate limits d’API auto
- 50k+ règles managées
- Aucune fausse alerte
- Fail-open garanti
Un seul pare-feu managé, à l'affût de chaque requête.
Le WAF s'exécute au cœur de votre application et tranche en quatre millisecondes environ. Vous ne touchez jamais à une signature : la politique arrive en flux depuis Defenso et se met à jour chaque semaine, et elle reste toujours fail-open. Si nous devenions injoignables, votre trafic continue de passer sans encombre.
Injection SQL, XSS, SSRF, injection de commandes, path traversal et bots scanners : chaque règle est taguée avec son identifiant MITRE ATT&CK et OWASP, pour qu'un verdict ne soit jamais une boîte noire. Mis à jour chaque semaine par nos soins.
Vos endpoints sont découverts à partir du trafic réel et bénéficient de limites de débit par route et par IP. Les routes de connexion embarquent d'emblée des plafonds anti-force brute : le credential stuffing et le scraping sont stoppés dès la porte d'entrée.
Les attaquants confirmés reçoivent de faux contenus cohérents et des honeytokens à la place de vos vraies données. Le butin ne vaut rien, et à la seconde où ils touchent l'appât, vous recevez une alerte précoce.
Ce que le WAF managé bloque pour vous.
Les attaques que nous stoppons en production, chaque jour. Survolez pour mettre en pause et lire.
Injection SQL
Une saisie utilisateur concaténée directement dans une requête. Nous l'arrêtons avant qu'elle n'atteigne votre base de données.
Cross-site scripting (XSS)
Un script glissé par un attaquant qui s'exécuterait chez vos utilisateurs. Bloqué en périphérie.
SSRF
Le serveur piégé pour aller chercher des URL internes qu'il ne devrait jamais atteindre.
Injection de commandes
Des commandes shell dissimulées dans un champ de saisie. Interceptées par les règles managées.
Path traversal
Des chemins ../ sournois qui tentent d'atteindre des fichiers hors de la racine web.
Injection SQL
Une saisie utilisateur concaténée directement dans une requête. Nous l'arrêtons avant qu'elle n'atteigne votre base de données.
Cross-site scripting (XSS)
Un script glissé par un attaquant qui s'exécuterait chez vos utilisateurs. Bloqué en périphérie.
SSRF
Le serveur piégé pour aller chercher des URL internes qu'il ne devrait jamais atteindre.
Injection de commandes
Des commandes shell dissimulées dans un champ de saisie. Interceptées par les règles managées.
Path traversal
Des chemins ../ sournois qui tentent d'atteindre des fichiers hors de la racine web.
Scanners et bots malveillants
Scanners automatisés et navigateurs headless identifiés par empreinte JA4 et par comportement.
Credential stuffing
Des vagues de connexions à base de mots de passe volés, stoppées par des limites de vélocité par compte.
Mass assignment
Des champs supplémentaires glissés dans une requête pour écraser ce qui ne devrait pas l'être.
Force brute
Le matraquage des connexions et des API, plafonné d'emblée par IP et par compte.
Injection NoSQL
Des charges utiles d'injection d'opérateurs visant MongoDB et consorts.
Scanners et bots malveillants
Scanners automatisés et navigateurs headless identifiés par empreinte JA4 et par comportement.
Credential stuffing
Des vagues de connexions à base de mots de passe volés, stoppées par des limites de vélocité par compte.
Mass assignment
Des champs supplémentaires glissés dans une requête pour écraser ce qui ne devrait pas l'être.
Force brute
Le matraquage des connexions et des API, plafonné d'emblée par IP et par compte.
Injection NoSQL
Des charges utiles d'injection d'opérateurs visant MongoDB et consorts.
La déception active, intégrée au pare-feu.
Bloquer, c'est signaler à un attaquant que sa sonde a été repérée, et l'inviter à revenir avec une charge plus discrète. La déception active répond à cette même menace confirmée par un monde cohérent et sans valeur : faux fichiers .env, faux panneaux d'administration et honeytokens à la place de vos vraies données. Le honeypot vit à l'intérieur du chemin de requête que le WAF inspecte déjà, sans rien de plus à déployer, et dès qu'ils touchent l'appât, vous recevez l'alerte la plus précoce possible. Elle neutralise l’attaque (defang) au lieu de simplement la bloquer.
La déception ne se déclenche jamais sur du trafic normal. Elle n'entre en jeu qu'après qu'une requête a déjà obtenu un verdict hostile du WAF managé : charges d'exploit, sondes de path traversal, empreintes de scanner, rafales de credential stuffing. Les crawlers vérifiés comme Googlebot et Bingbot figurent sur une liste d'autorisation permanente et ne voient jamais d'appât : votre SEO et vos vrais utilisateurs restent intacts.
Les sondes visant .env, .git, des archives de sauvegarde ou des panneaux d'administration renvoient des fichiers et des pages plausibles plutôt qu'un code de statut. Ces leurres sont cohérents entre eux : l'attaquant continue de tirer le fil jusque dans un bac à sable pendant que vos vraies données restent hors d'atteinte. Voilà de la déception tissée dans le chemin de requête réel, et non un boîtier honeypot posé à l'écart.
Chaque faux identifiant, clé d'API et chaîne de connexion est un honeytoken qui ne fonctionne nulle part. À la seconde où l'un d'eux est utilisé quelque part sur Internet, vous recevez une alerte portant l'empreinte de l'attaquant. Comme seul un attaquant touche jamais à l'appât, le signal n'a pour ainsi dire aucun faux positif : la détection de brèche la plus précoce et la plus nette que vous puissiez exploiter.
Un pare-feu que vous n'avez jamais à surveiller.
La plupart des pare-feux vous livrent un moteur de règles et un manuel. Le nôtre embarque 50k+ règles managées, s’exécute dans votre application, décide en environ quatre millisecondes et maintient sa propre politique à jour, pour zéro temps passé à régler des signatures. Il est conçu pour être non bloquant : les vrais utilisateurs et le trafic d’API légitime ne déclenchent jamais de fausse alerte.
Dès qu’une requête arrive, elle est confrontée à une politique de 50 000+ règles taguées MITRE ATT&CK et OWASP que nous mettons à jour chaque semaine, y compris de nouvelles règles pour les schémas d’attaque qui frappent les applications en ce moment. Si elle est hostile, elle est stoppée avant d’atteindre votre code, et le verdict est journalisé avec la règle et la charge utile exactes, pour que rien ne soit une boîte noire. Si elle est propre, elle passe avec quelques millisecondes ajoutées.
Le plus dur, dans un WAF, n’est pas de bloquer les attaques, c’est de ne pas bloquer vos clients. Le nôtre est conçu contre les faux positifs : les règles sont notées et filtrées pour qu’une requête légitime ne soit jamais rejetée sur un simple soupçon, et le rate limiting d’API plafonne les abus par route, par IP et par compte sans brider l’usage normal. Vous obtenez une protection qui reste silencieuse jusqu’à ce que ça compte.
Parce que la politique vit chez nous, vous n’êtes jamais le dernier site à tourner sur un jeu de règles périmé. Les nouveaux schémas d’attaque sont ajoutés de façon centralisée et prennent effet sur votre site le jour même, sans aucun déploiement de votre côté. Et c’est fail-open par conception : si notre service est un jour injoignable, chaque requête est laissée passer et votre application continue de servir. Les attaquants confirmés ne sont pas seulement bloqués, ils sont activement trompés : de faux fichiers cohérents et des honeytokens à la place de vos vraies données, pour qu’une intrusion ne vaille rien et que vous soyez averti au plus tôt.
Bloquer l'attaque, ou la rendre sans valeur.
Le blocage et la déception ne sont pas rivaux. Defenso fait les deux dans un seul chemin de requête : le trafic hostile est bloqué là où un blocage suffit, et trompé là où vous voulez que l'attaquant perde des heures et vous laisse une empreinte. Voici comment la déception active intégrée à l'application se compare au blocage seul et à un boîtier honeypot autonome classique.
| Capacité | WAF blocage seul | Honeypot autonome | Déception active Defenso |
|---|---|---|---|
| Arrête l'exploit net | ✓ | × | ✓ |
| L'attaquant apprend que sa sonde a été repérée | Oui | Non | Non |
| Sert de faux fichiers cohérents et de faux panneaux | × | Partiel | ✓ |
| Honeytokens qui alertent en cas de réutilisation | × | ✓ | ✓ |
| Exfiltration filigranée traçable plus tard | × | × | ✓ |
| Ne se déclenche que sur des attaquants confirmés | n/a | × | ✓ |
| Les crawlers vérifiés ne voient jamais d'appât | n/a | × | ✓ |
| S'exécute dans votre application, rien à déployer | ✓ | × | ✓ |
| Inclus dans chaque offre, Free comprise | Variable | × | ✓ |
La limitation de débit API automatique.
Le pare-feu fait bien plus que bloquer des charges utiles. Il découvre vos endpoints API à partir du trafic réel et plafonne les abus par route, par IP et par compte, sans une seule règle à écrire de votre part.
Les endpoints trouvés pour vous
Vos routes sont apprises à partir du trafic réel : vous ne tenez jamais de liste. Les nouveaux endpoints sont repérés automatiquement et ceux qui ont besoin d'être protégés sont signalés.
Par route, par IP, par compte
Les limites s'appliquent là où elles comptent : une route de connexion, une API de recherche, un endpoint d'écriture. Les rafales venant d'une IP ou d'un compte sont bridées sans jamais gêner vos utilisateurs légitimes.
Des plafonds anti-force brute d'emblée
Les routes de connexion et de token embarquent dès le premier jour des plafonds anti-credential stuffing et anti-force brute : le password spraying et le scraping sont stoppés dès la porte, avant même que vous ne configuriez quoi que ce soit.
Un WAF managé face à un CDN ou un pare-feu de périphérie.
Un CDN comme Cloudflare protège la périphérie, devant votre application. Defenso protège l'application elle-même et ajoute le travail de sécurité qu'un CDN n'a jamais eu vocation à faire. La plupart des équipes utilisent les deux.
| CDN / pare-feu de périphérie | WAF managé Defenso | |
|---|---|---|
| Bloque SQLi, XSS, SSRF | ✓ | ✓ |
| Règle + charge utile auditables par requête | parfois | ✓ |
| Détecte vos API et les protège par limitation de débit | × | ✓ |
| Déception active et honeytokens | × | ✓ |
| Scans de sécurité du site et des dépôts | × | ✓ |
| Pentest et conformité dans le même compte | × | ✓ |
| Fonctionne aux côtés de votre CDN existant | — | ✓ |
Questions fréquentes.
Tout ce qu’on demande avant de se lancer. Encore un doute ? On est à un message.
Non. Le WAF managé arrive avec une politique de règles taguées MITRE et OWASP que nous mettons à jour chaque semaine. Il fonctionne d'emblée, et vous pouvez ajouter vos propres règles personnalisées sur Pro et au-delà si vous le souhaitez.
Il ne devrait pas. Les crawlers vérifiés comme Google et Bing sont sur liste d'autorisation, et les règles sont ajustées face au trafic réel. Quand une requête est bloquée, vous voyez exactement quelle règle s'est déclenchée et la charge utile : tout faux positif est facile à repérer et à corriger.
Quatre millisecondes environ par requête. Le contrôle s'exécute au cœur de votre application et renvoie un verdict rapidement, et les réponses GET sûres peuvent être mises en cache en périphérie pour récupérer ce temps.
Rien ne casse. Le WAF est fail-open par conception : si notre service est injoignable, chaque requête est laissée passer et votre application continue de répondre normalement. Votre application répond sans interruption ; seules nos mises à jour de politique en direct sont en pause jusqu'à notre retour.
Non, il le complète. Un CDN protège la périphérie ; le WAF managé protège l'application derrière lui et ajoute les scans, le pentest, la déception et la conformité. La plupart des clients utilisent les deux, et nous tenons nos IP de vérification à l'écart de votre pare-feu CDN pour qu'une règle ne déclenche jamais une fausse alerte de coupure.
Ajoutez une ligne de code avec le SDK, ou un clic avec l'extension WordPress. Le pare-feu managé, les limites de débit et la déception s'activent ensemble, sans fichier de configuration à maintenir.
La déception active répond à un attaquant confirmé par un faux environnement cohérent plutôt que par une erreur : faux fichiers plausibles, faux panneaux d'administration et honeytokens. L'attaquant perd du temps sur des données sans valeur pendant que vous recevez une alerte de brèche précoce. Contrairement à un honeypot autonome classique que vous installez et surveillez à l'écart, la déception Defenso s'exécute au cœur de votre vraie application, sur le chemin de requête que le WAF inspecte déjà : elle engage donc l'attaquant réel qui frappe votre site en production, sans rien de plus à déployer. Elle est incluse dans chaque offre, Free comprise.
Non. La déception ne s'engage qu'une fois qu'une requête a obtenu un verdict hostile du WAF. Les visiteurs normaux et les crawlers vérifiés comme Googlebot et Bingbot figurent sur une liste d'autorisation permanente et ne voient jamais d'appât : vos utilisateurs et votre classement de recherche ne sont jamais affectés. Les honeytokens ne fonctionnent nulle part, donc aucune personne légitime n'y touche jamais, et c'est pourquoi l'alerte n'a pour ainsi dire aucun faux positif.
Activez le pare-feu en une ligne.
Gratuit pour démarrer, sans carte bancaire. Ajoutez une ligne et le WAF managé, les limites de débit et la déception se mettent à bloquer en production.