Configurer l'authentification et activer l'API Web Risk
Sign in to your Google Cloud account. If you're new to
Google Cloud,
create an account to evaluate how our products perform in
real-world scenarios. New customers also get $300 in free credits to
run, test, and deploy workloads.
Installez la Google Cloud CLI.
Une fois que la Google Cloud CLI est installée, initialisez-la en exécutant la commande suivante :
Quelle API me convient-elle le mieux ? Lookup ou Update ?
Web Risk fournit deux API différentes que vous pouvez intégrer. Ces API sont : l'API Lookup et l'API Update. Ces deux API fournissent les mêmes informations. À savoir, si une URL a été identifiée comme malveillante. L'API Lookup est la plus simple à utiliser. À l'aide de l'API Lookup, vous interrogerez Web Risk concernant chaque URL que vous souhaitez vérifier.
L'API Update est plus complexe, mais possède certaines propriétés avantageuses. À l'aide de l'API Update, vous gérerez une base de données locale. Cette base de données peut être vérifiée pour déterminer si une URL est malveillante. Cette base de données fait office de filtre de Bloom. Par exemple, il peut y avoir de faux positifs (une URL est identifiée comme malveillante, mais ne l'est pas), mais il ne doit y avoir aucun faux négatif (une URL est identifiée comme n'étant pas malveillante, mais l'est). Par conséquent, les serveurs Web Risk sont rarement contactés et le sont uniquement pour confirmer les correspondances et lever les ambiguïtés sur les faux positifs. Dans la plupart des cas, lorsque vous vérifiez une URL à l'aide de l'API Update, vous n'aurez aucunement besoin de contacter les serveurs Web Risk. Vous ne devez contacter les serveurs Web Risk que lorsque vous mettez à jour la base de données locale et que vous confirmez qu'une URL est malveillante.
En résumé, utilisez l'API Lookup si vous souhaitez obtenir une configuration rapidement et facilement.
Utilisez l'API Update si vous devez effectuer une vérification d'URL avec une latence plus faible.
Choisir les fonctionnalités client appropriées
Si vous choisissez d'utiliser l'API Update, vous n'aurez peut-être pas besoin de mettre en œuvre l'intégralité de la spécification. Certaines fonctionnalités conçues pour des clients largement distribués (tels que les navigateurs Web) sont sur-optimisées dans de nombreux cas d'affaires.
Certaines fonctionnalités peuvent être ignorées pour faciliter l'intégration.
Voici les solutions d'intégration Web Risk par ordre de complexité :
Utiliser l'API LookUp
Client de l'API Basic Update
Mettre à jour le client API à l'aide des différences
Mettre à jour le client API à l'aide des différences RICE compressées
Utiliser l'API Lookup
L'API Lookup est la moins complexe à utiliser. En cas d'URL potentiellement suspecte, il vous suffit d'appeler l'API Lookup avec l'URL pour obtenir un résultat.
La mise en forme canonique et le formatage de l'URL sont gérés par le serveur Web Risk. Cette solution devrait être valide pour la plupart des clients, sauf si la latence moyenne dépasse les exigences.
Client de l'API Basic Update
L'API Update présente la complexité supplémentaire de gérer une base de données locale et des URL canoniques avant les requêtes.
Lors d'une intégration client classique à l'aide de Web Risk, un client appliquera les différences de bases de données pour rester à jour. La mise en œuvre de la logique d'application des différences peut prendre un certain temps. Dans les cas les plus simples, nous recommandons que les clients ignorent les différences et demandent une nouvelle base de données complète à chaque cycle Web Risk. Cette base de données sera toujours stockée en mémoire pour obtenir des requêtes plus efficaces. Pour demander la réinitialisation complète de la base de données, laissez le champ versionToken vide dans la requête threatLists.computeDiff.
Cette solution devrait être valide pour tous les clients, sauf si la latence de synchronisation de la bande passante ou de la base de données dépasse les exigences.
Utiliser l'API Update et demander des mises à jour de différences
Cette solution présente la complexité supplémentaire de mettre en œuvre la logique d'application des différences dans la base de données locale. Pour en savoir plus, consultez la section Différences de bases de données. L'application des différences permet de réduire l'utilisation de la bande passante au prix d'une certaine complexité, par rapport à la demande d'une nouvelle base de données à chaque cycle. Une mise à jour complète de la base de données peut être de l'ordre de quelques mégaoctets.
Cette solution devrait être suffisante pour la plupart des clients professionnels.
Utiliser l'API Update et demander des mises à jour de différences des données encodées RICE
Cette solution offre l'intégration client la plus efficace possible. L'encodage RICE compresse les tailles DIFF et réduit davantage la bande passante pour la mise à jour. Cette solution est destinée aux clients les plus limités en bande passante. Par exemple, cette solution peut être pertinente si les requêtes Web Risk sont intégrées dans une application pour téléphone. Les utilisateurs d'une telle application apprécieront sûrement une solution à faible bande passante s'ils doivent mettre à jour la base de données à l'aide des données du téléphone.
Pour en savoir plus, consultez la section Compression.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Detect malicious URLs with Web Risk\n===================================\n\nBefore you begin\n----------------\n\n- Create a Google Cloud project. [Learn how to create a Google Cloud project](/resource-manager/docs/creating-managing-projects#creating_a_project).\n\n-\n\n\n [Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n \u003cbr /\u003e\n\nSet up authentication and enable the Web Risk API\n-------------------------------------------------\n\nSign in to your Google Cloud account. If you're new to Google Cloud, [create an account](https://console.cloud.google.com/freetrial) to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.\n\n\n[Install](/sdk/docs/install) the Google Cloud CLI.\n\nAfter installation,\n[initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n```bash\ngcloud init\n```\n\n\nIf you're using an external identity provider (IdP), you must first\n[sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n[Create or select a Google Cloud project](https://cloud.google.com/resource-manager/docs/creating-managing-projects).\n| **Note**: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.\n\n- Create a Google Cloud project:\n\n ```\n gcloud projects create PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with a name for the Google Cloud project you are creating.\n- Select the Google Cloud project that you created:\n\n ```\n gcloud config set project PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your Google Cloud project name.\n\n\n[Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n\nEnable the Web Risk API:\n\n\n```bash\ngcloud services enable webrisk.googleapis.com\n``` \n\n[Install](/sdk/docs/install) the Google Cloud CLI.\n\nAfter installation,\n[initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n```bash\ngcloud init\n```\n\n\nIf you're using an external identity provider (IdP), you must first\n[sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n[Create or select a Google Cloud project](https://cloud.google.com/resource-manager/docs/creating-managing-projects).\n| **Note**: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.\n\n- Create a Google Cloud project:\n\n ```\n gcloud projects create PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with a name for the Google Cloud project you are creating.\n- Select the Google Cloud project that you created:\n\n ```\n gcloud config set project PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your Google Cloud project name.\n\n\n[Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n\nEnable the Web Risk API:\n\n\n```bash\ngcloud services enable webrisk.googleapis.com\n```\n\n\u003cbr /\u003e\n\nUsing the APIs\n--------------\n\nWhen you use the Web Risk APIs, make sure you're familiar with Web Risk's [Service Level Agreement](/web-risk/sla) and [usage limits](/web-risk/quotas).\n\nTo start using Web Risk, see these topics:\n\n- [Using the Lookup API](/web-risk/docs/lookup-api)\n- [Using the Update API](/web-risk/docs/update-api)\n\nWhich API is right for me? Lookup or Update?\n--------------------------------------------\n\nWeb Risk provides two different APIs that you may integrate with. These\nAPIs are the [Lookup API](/web-risk/docs/lookup-api) and the [Update API](/web-risk/docs/update-api). Both of\nthese APIs provide the same information. That is, whether a URL has been\nidentified as malicious. The easiest to use is the Lookup API. Using the Lookup\nAPI, you will query Web Risk for every URL you wish to check.\n\nThe Update API is more complex but has some desirable properties. Using the\nUpdate API, you will maintain a local database. This database may be checked\nto see if a URL is malicious. This database acts as a bloom filter. That is,\nthere may be false positives (a URL is identified as malicious but isn't) but\nthere should not be any false negatives (a URL is identified as not malicious,\nbut is). Because of this, the Web Risk servers are rarely contacted, and are\nonly contacted to confirm matches and disambiguate false positives. In most\ncases, when checking a URL using the Update API you won't need to contact the\nWeb Risk servers at all. You are expected to contact Web Risk servers only when\nupdating the local database and when confirming a URL is harmful.\n\nIn summary, use the Lookup API if you want to get set up quickly and easily.\nUse the Update API if you need lower latency URL checking.\n\nChoosing the Right Client Features\n----------------------------------\n\nIf you chose to use the Update API, you may not need to implement the entire\nspecification. There are some features that were designed for widely distributed\nclients (like web browsers) that are over-optimizations in many enterprise\ncases.\n\nThere are some features that may be ignored for easier integration.\n\nHere are the Web Risk integration solutions in order of complexity\n\n1. Use the LookUp API\n2. Basic Update API client\n3. Update API client using diffs\n4. Update API client using RICE compressed diffs\n\n### Using the Lookup API\n\nUsing the Lookup API has the lowest complexity. Whenever there is a potentially\nsuspicious URL, simply call the Lookup API with the URL to see a verdict.\nCanonicalization and formatting the URL is handled by the Web Risk\nserver. This solution should be valid for most clients unless average latency\nexceeds requirements.\n\n### Basic Update API client\n\nThe Update API requires the additional complexity of managing a local database\nand canonicalized URLs before queries.\n\nIn a typical client integration with Web Risk, a client will apply database\ndiffs to remain up-to-date. The diff application logic may take some time to\nimplement correctly, so in the simplest cases we recommend clients ignore diffs\nand request a full new database from Web Risk every cycle. This database will\nstill be stored in memory for efficient querying. Requesting a full database\nreset is done by leaving the `versionToken` field empty in the\n[`threatLists.computeDiff` request](/web-risk/docs/update-api#http_get_request).\nThis solution should be valid for clients unless bandwidth or database\nsynchronization latency exceeds requirements.\n\n### Use the Update API and request diff updates\n\nThis solution has the added complexity of applying the diff logic to the local\ndatabase. For more information, see\n[Database Diffs](/web-risk/docs/local-databases#full-updates). Using diffs will reduce\nbandwidth at the expense of complexity, compared to requesting a new database\neach cycle. A full database update may be on the order of a few megabytes.\nThis solution should be sufficient for most enterprise clients.\n\n### Use the Update API and request RICE encoded diff updates\n\nThis solution is the most efficient client integration possible. RICE encoding\ncompresses DIFF sizes and further reduces update bandwidth. This solution is\nintended to be used by the most bandwidth constrained customers. An example\nwhere this may be relevant is if Web Risk queries are built into a phone App.\nThe users of such an app would surely appreciate a lower bandwidth solution if\nthey needed to update the database over phone data.\nFor more information, see [Compression](/web-risk/docs/compression)."]]
