Les API Safe Browsing permettent à vos applications clientes d'effectuer des vérifications d'URL en temps réel ou basées sur des listes par rapport aux listes de ressources Web non sécurisées constamment mises à jour par Google. Ces listes peuvent inclure, par exemple, des sites d'ingénierie sociale (sites d'hameçonnage et sites trompeurs), ou encore des sites hébergeant des logiciels malveillants ou indésirables. Toute URL figurant dans une liste de navigation sécurisée est considérée comme non sécurisée.
Pour déterminer si une URL figure dans l'une des listes de navigation sécurisée, les clients peuvent utiliser urls.search ou hashes.search.
Nouveautés
Fraîcheur des données
Traditionnellement, les clients de la navigation sécurisée téléchargent régulièrement des listes de menaces utilisées pour identifier les menaces potentielles. Au fil du temps, le volume et la vitesse des menaces ont augmenté. Ces listes de menaces locales sont donc devenues moins efficaces contre les menaces modernes.
Pour combler cette lacune, nous introduisons la possibilité de passer les protocoles en mode vérification par défaut au lieu du mode autorisation par défaut précédemment disponible dans la version 4. Pour ce faire, nous avons introduit la possibilité de télécharger une liste de sites probablement fiables, appelée "cache global". Si une URL n'est pas trouvée dans le cache global, le client doit effectuer une vérification avec l'API pour déterminer si l'URL constitue une menace.
Cette capacité à effectuer des vérifications par défaut, associée à l'amélioration de la fraîcheur des données dans le service, permet une protection plus rapide et quasi en temps réel contre les nouvelles menaces.
Confidentialité de l'adresse IP
L'API Safe Browsing n'utilise les adresses IP que pour les besoins essentiels du réseau et à des fins anti-DoS.
Nous avons introduit une API associée, appelée API Safe Browsing Oblivious HTTP Gateway, pour offrir des garanties de confidentialité supplémentaires. Cette fonctionnalité utilise Oblivious HTTP pour masquer les adresses IP des utilisateurs finaux à Google. Pour ce faire, un tiers non complice gère une version chiffrée de la requête de l'utilisateur, puis la transmet à Google. Le tiers n'a donc accès qu'aux adresses IP, et Google n'a accès qu'au contenu de la requête. Le tiers exploite un relais Oblivious HTTP (comme ce service de Fastly) et Google exploite la passerelle Oblivious HTTP. Il s'agit d'une API associée facultative. Lorsqu'il est utilisé conjointement avec la navigation sécurisée Google, les adresses IP des utilisateurs finaux ne sont plus envoyées à Google.
Pour en savoir plus, consultez la documentation de l'API Safe Browsing Oblivious HTTP Gateway.
Méthodes de recherche
Examinons les différentes méthodes disponibles pour effectuer des vérifications en temps réel des URL.
urls.search
Permet aux applications clientes d'envoyer des URL au service de navigation sécurisée pour vérifier si des menaces y sont associées.
Avantages
- Vérifications d'URL simples : vous envoyez une requête avec les URL réelles, et le serveur répond en indiquant les URL avec les menaces associées (le cas échéant).
Inconvénients
- Aucune confidentialité des URL : la requête contient les URL brutes à vérifier.
Si les avantages et les inconvénients correspondent à vos besoins, envisagez d'utiliser urls.search, car il est simple à utiliser.
Consultez les Conditions d'utilisation de l'utilisation de la méthode, car elles diffèrent de hashes.search.
hashes.search
Permet aux applications clientes de vérifier si un ensemble d'URL contient des menaces connues sans révéler les URL réelles au service. Pour ce faire, il suffit de fournir le préfixe de hachage de l'URL. La réponse contiendra les hachages complets des menaces connues avec le préfixe de hachage du shard.
Avantages
- Confidentialité des URL : seule une partie de l'URL hachée (préfixe de hachage de 4 octets) figure dans la requête.
- Compatibilité : comme le client gère la canonisation et le hachage des URL, cette méthode s'intègre parfaitement aux modes qui utilisent une base de données locale, tels que le mode Temps réel et le mode Liste locale.
Inconvénients
- Vérifications d'URL complexes : Vous devez savoir comment mettre en forme canonique les URL, créer des expressions de suffixe/préfixe et calculer des hachages SHA256 pour envoyer des requêtes à cette méthode, des comparaisons avec les copies locales des listes de sites dangereux ou du cache global.
Si vous devez donner la priorité à la confidentialité des URL et que vous souhaitez utiliser le mode temps réel ou le mode Liste locale, l'approche recommandée est hashes.search.
Méthodes HashList
Ces méthodes permettent aux clients de télécharger et de stocker des versions hachées des listes de ressources non sécurisées et du cache global. Les clients peuvent utiliser ces informations pour déterminer s'ils doivent effectuer une recherche en temps réel des URL en question.
Ces méthodes sont essentielles au fonctionnement du mode Temps réel et du mode Liste locale.
Pour en savoir plus sur l'utilisation de ces méthodes, consultez la page Base de données locale.
Exemples de requête
Cette section présente quelques exemples d'utilisation directe de l'API HTTP pour accéder à la navigation sécurisée. Il est généralement recommandé d'utiliser une liaison de langage générée, car elle gère automatiquement l'encodage et le décodage de manière pratique. Veuillez consulter la documentation de cette liaison.
Exemple de requête HTTP utilisant urls.search :
GET https://safebrowsing.googleapis.com/v5alpha1/urls:search?key=INSERT_YOUR_API_KEY_HERE&urls=testsafebrowsing.appspot.com/
Exemple de requête HTTP utilisant hashes.search :
GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ
Exemple de requête HTTP utilisant hashLists.batchGet :
GET https://safebrowsing.googleapis.com/v5/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw-4b
Tous les corps de réponse sont des charges utiles au format Protocol Buffer que vous pouvez décoder.