Chaque fois que votre utilisateur ou visiteur charge votre site Web ou votre application Web, il ne charge pas seulement vos composants, mais également ceux provenant du Web en général et de fournisseurs tiers. Vous n'avez une visibilité que sur ce qui se passe côté serveur, et non sur ce qui est réellement chargé dans le navigateur Web de l'utilisateur.
Tout comme un pare-feu d'application Web (WAF) proxy les requêtes HTTP,cside proxy les JavaScripts sur lesquels vous n'avez généralement aucun contrôle aujourd'hui. Cela nous permet de voir exactement ce que voit l'utilisateur.
Les pirates ne peuvent pas fournir un script propre aux solutions de sécurité et un script malveillant aux utilisateurs. Nous obtenons une copie exacte de la charge utile, la désobfuscations et l'exécutons sur des systèmes de détection, y compris des analyses basées sur le LLM.
Nous examinons comment le code s'exécute, et pas seulement ce qu'il fait. Cela permet de faire la différence entre les scripts de suivi légitimes et les comportements malveillants présentant des caractéristiques techniques similaires.
Surveillez les scripts marketing, analytiques et de paiement sans interrompre les flux de paiement.
Protéger les données des utilisateurs tout en maintenant les performances des applications mondiales.
Veillez à ce que les intégrations tierces ne compromettent pas les données de paiement sensibles.
MaintenezHIPAAla conformité tout en utilisant des services tiers essentiels.
Bien que les deux utilisent la technologie proxy,Gatekeeper est spécialement conçu pourJavaScriptla sécurité.
| Fonctionnalité | cside Gatekeeper | Pare-feu d'application Web (WAF) |
|---|---|---|
| Tout le trafic HTTPS vers l'ensemble de votre site web | ||
| Se situe entre les utilisateurs et l'ensemble de votre site web | ||
| Complexe - nécessite la gestion des règles pour tout le trafic, les certificats SSL, les types de contenu | ||
| L'ensemble du site web devient inaccessible. | ||
| Ajoute une latence à chaque requête | ||
| Protection des requêtes entrantes côté serveur | ||
| N/A - gère différentes couches |
FAQ
Foire aux questions
Un WAF se situe entre vos utilisateurs et votre infrastructure web en faisant proxy de tout le trafic vers votre infrastructure web. Le Gatekeeper est beaucoup plus ciblé et n'interagit qu'avec les fichiers JavaScript provenant de sources tierces sur lesquelles vous n'avez ordinairement aucun contrôle. Le trafic principal de votre site web reste totalement intact. Vos utilisateurs se connectent directement à votre site web, mais lorsque leur navigateur demande un script provenant d'une source tierce non fiable, cette demande unique est acheminée via cside pour analyse avant livraison. Cette approche est nécessaire pour éviter les limitations au niveau du navigateur.
Nous avons conçu Gatekeeper comme une solution hybride. Vous avez le contrôle sur les scripts qui passent par le moteur Gatekeeper et ceux qui ne le font pas. Les scripts critiques comme Stripe, PayPal, Google Pay ou Intercom sont déjà configurés pour être servis en mode direct. Nous vérifions toujours leurs comportements côté client et via notre analyse asynchrone, mais cside ne se situe pas au milieu ici. Vous pouvez sélectionner les scripts auxquels vous faites confiance et tout le reste reçoit le traitement de sécurité complet. Cette flexibilité vous permet d'autoriser les scripts auxquels vous faites confiance et de faire passer par le flux les scripts qui vous préoccupent le plus ou que vous n'avez jamais vus auparavant, puis d'étendre la couverture à mesure que vous vous sentez plus à l'aise. Cela est nécessaire car la détection côté navigateur est limitée. Le navigateur n'a pas été conçu pour la sécurité côté client, donc le Gatekeeper comble cette lacune.
Votre site web continuera à fonctionner normalement. En mode Gatekeeper, nous ne faisons passer que les scripts tiers par le moteur. Ceux-ci ne bloquent généralement pas le rendu, il n'y a donc pas de différence notable. Même en cas d'incident avec cside, nous n'empêcherons pas les scripts d'être servis. Nos produits fonctionnent sur un modèle fail-open avec un SLA de disponibilité de 99,99 %. Si le service Gatekeeper tombe en panne, le script cside qui effectue le passage cesse également de servir. Il s'agit d'un modèle classique de dead-man switch. Ceci est complètement différent d'une défaillance WAF où l'ensemble de votre site devient inaccessible lorsque le fournisseur tombe en panne. Lorsque nous avons conçu notre produit, nous nous sommes assurés d'inclure les événements de temps d'arrêt comme une possibilité, donc nous nous sommes assurés que par conception, nous n'allons pas casser une page web.
Votre site web continuera à fonctionner comme prévu.cside dispose d'une conception à sécurité intégrée avec un temps de SLAdisponibilité de 99,99 %, mais en cas de problème,JavaScript les requêtes sont automatiquement redirigées vers leurs sources d'origine. Cela diffère complètement d'une défaillance WAF, qui rendrait l'ensemble de votre site inaccessible. Nous avons conçu lacside plateforme afin de renforcer la sécurité sans créer de points de défaillance uniques pour les fonctionnalités essentielles de votre site web. Nous savions dès le départ qu'il s'agissait d'une exigence importante.