Configurar la autenticación y habilitar la 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.
Instala Google Cloud CLI.
Después de la instalación,
inicializa la CLI de Google Cloud ejecutando el siguiente comando:
¿Qué API es la más adecuada para mí? ¿Buscar o actualizar?
Web Risk ofrece dos APIs diferentes que puede integrar. Estas APIs son la API Lookup y la API Update. Ambas APIs proporcionan la misma información. Es decir, si se ha identificado una URL como maliciosa. La más fácil de usar es la API Lookup. Con la API Lookup, consultarás Web Risk para cada URL que quieras comprobar.
La API Update es más compleja, pero tiene algunas propiedades interesantes. Con la API Update, mantendrás una base de datos local. Esta base de datos se puede consultar para comprobar si una URL es maliciosa. Esta base de datos actúa como filtro Bloom. Es decir, puede haber falsos positivos (se identifica una URL como maliciosa, pero no lo es), pero no debería haber falsos negativos (se identifica una URL como no maliciosa, pero sí lo es). Por este motivo, los servidores de Web Risk rara vez se contactan y solo se contactan para confirmar coincidencias y desambiguar falsos positivos. En la mayoría de los casos, cuando compruebe una URL con la API Update, no tendrá que ponerse en contacto con los servidores de Riesgo web. Solo debes ponerte en contacto con los servidores de Web Risk cuando actualices la base de datos local y cuando confirmes que una URL es dañina.
En resumen, usa la API Lookup si quieres configurarla de forma rápida y sencilla.
Usa la API Update si necesitas comprobar URLs con una latencia más baja.
Elegir las funciones de cliente adecuadas
Si has elegido usar la API Update, puede que no tengas que implementar toda la especificación. Hay algunas funciones que se han diseñado para clientes distribuidos ampliamente (como los navegadores web) que son optimizaciones excesivas en muchos casos empresariales.
Hay algunas funciones que se pueden ignorar para facilitar la integración.
Estas son las soluciones de integración de Web Risk ordenadas por complejidad:
Usar la API LookUp
Cliente de la API Basic Update
Actualizar el cliente de la API mediante diferencias
Actualizar el cliente de API mediante diferencias comprimidas de RICE
Usar la API Lookup
Usar la API Lookup es la opción menos compleja. Cuando haya una URL potencialmente sospechosa, solo tienes que llamar a la API Lookup con la URL para ver un veredicto.
El servidor de Web Risk se encarga de la canonicalización y el formato de la URL. Esta solución debería ser válida para la mayoría de los clientes, a menos que la latencia media supere los requisitos.
Cliente de la API Basic Update
La API Update requiere la complejidad adicional de gestionar una base de datos local y URLs canonizadas antes de las consultas.
En una integración de cliente típica con Web Risk, un cliente aplicará diferencias de base de datos para mantenerse al día. La lógica de la aplicación de diferencias puede tardar un tiempo en implementarse correctamente, por lo que, en los casos más sencillos, recomendamos que los clientes ignoren las diferencias y soliciten una base de datos nueva completa a Riesgo web en cada ciclo. Esta base de datos se seguirá almacenando en la memoria para que las consultas sean eficientes. Para solicitar un restablecimiento completo de la base de datos, deje el campo versionToken vacío en la solicitud threatLists.computeDiff.
Esta solución debería ser válida para los clientes, a menos que la latencia de sincronización de la base de datos o el ancho de banda supere los requisitos.
Usar la API Update y solicitar actualizaciones de diferencias
Esta solución tiene la complejidad añadida de aplicar la lógica de diferencias a la base de datos local. Para obtener más información, consulta Diferencias de bases de datos. El uso de las diferencias reducirá el ancho de banda a costa de la complejidad, en comparación con la solicitud de una nueva base de datos en cada ciclo. Una actualización completa de la base de datos puede ser de unos pocos megabytes.
Esta solución debería ser suficiente para la mayoría de los clientes empresariales.
Usar la API Update y solicitar actualizaciones de diferencias codificadas en RICE
Esta solución es la integración de cliente más eficiente posible. La codificación RICE
comprime los tamaños de las diferencias y reduce aún más el ancho de banda de las actualizaciones. Esta solución está pensada para los clientes con las mayores limitaciones de ancho de banda. Un ejemplo de situación en la que esto puede ser relevante es si las consultas de Riesgo web están integradas en una aplicación de teléfono. Los usuarios de esta aplicación seguramente agradecerían una solución con un menor ancho de banda si tuvieran que actualizar la base de datos a través de datos móviles.
Para obtener más información, consulta Compresión.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-19 (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)."]]
