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.
Instale a CLI Google Cloud.
Após a instalação,
inicialize a CLI gcloud executando o seguinte comando:
Qual é a API certa para mim? Procurar ou atualizar?
O Web Risk oferece duas APIs diferentes com as quais pode fazer a integração. Estas APIs são a API Lookup e a API Update. Ambas as APIs fornecem as mesmas informações. Ou seja, se um URL foi identificado como malicioso. A mais fácil de usar é a API Lookup. Com a API Lookup, vai consultar o Navegação Segura para cada URL que quiser verificar.
A API Update é mais complexa, mas tem algumas propriedades desejáveis. Ao usar a API Update, mantém uma base de dados local. Esta base de dados pode ser verificada para ver se um URL é malicioso. Esta base de dados funciona como um filtro de Bloom. Ou seja, pode haver falsos positivos (um URL é identificado como malicioso, mas não é), mas não deve haver falsos negativos (um URL é identificado como não malicioso, mas é). Por este motivo, os servidores do Web Risk são raramente contactados e só o são para confirmar correspondências e desambiguar falsos positivos. Na maioria dos casos, quando verifica um URL através da API Update, não precisa de contactar os servidores do Web Risk. Deve contactar os servidores do Web Risk apenas quando
atualiza a base de dados local e quando confirma que um URL é prejudicial.
Em resumo, use a API Lookup se quiser fazer a configuração de forma rápida e fácil.
Use a API Update se precisar de uma verificação de URLs com menor latência.
Escolher as funcionalidades do cliente certas
Se optou por usar a API Update, pode não ter de implementar a especificação completa. Existem algumas funcionalidades concebidas para clientes amplamente distribuídos (como navegadores de Internet) que são otimizações excessivas em muitos casos empresariais.
Existem algumas funcionalidades que podem ser ignoradas para uma integração mais fácil.
Seguem-se as soluções de integração do Web Risk por ordem de complexidade
Use a API LookUp
Cliente da API Basic Update
Atualize o cliente API através de diferenças
Atualize o cliente API com diferenças comprimidas RICE
Usar a API Lookup
A utilização da API Lookup tem a complexidade mais baixa. Sempre que existir um URL potencialmente
suspeito, basta chamar a API Lookup com o URL para ver um veredito.
A canonicalização e a formatação do URL são processadas pelo servidor do Web Risk. Esta solução deve ser válida para a maioria dos clientes, a menos que a latência média exceda os requisitos.
Cliente da API Basic Update
A API Update requer a complexidade adicional de gerir uma base de dados local
e URLs canonizados antes das consultas.
Numa integração de cliente típica com o Web Risk, um cliente aplica diferenças de base de dados para se manter atualizado. A lógica da aplicação de diferenças pode demorar algum tempo a ser implementada corretamente. Por isso, nos casos mais simples, recomendamos que os clientes ignorem as diferenças e solicitem uma base de dados totalmente nova ao Web Risk em cada ciclo. Esta base de dados continua a ser armazenada na memória para consultas eficientes. Para pedir uma reposição completa da base de dados, deixe o campo versionToken vazio no pedido threatLists.computeDiff.
Esta solução deve ser válida para os clientes, a menos que a largura de banda ou a latência de sincronização da base de dados excedam os requisitos.
Use a API Update e peça atualizações de diferenças
Esta solução tem a complexidade adicional de aplicar a lógica de diferenças à base de dados local. Para mais informações, consulte o artigo
Diferenças entre bases de dados. A utilização de diferenças reduz a largura de banda à custa da complexidade, em comparação com o pedido de uma nova base de dados a cada ciclo. Uma atualização completa da base de dados pode ter alguns megabytes.
Esta solução deve ser suficiente para a maioria dos clientes empresariais.
Use a API Update e peça atualizações de diferenças codificadas em RICE
Esta solução é a integração de cliente mais eficiente possível. A codificação RICE comprime os tamanhos de DIFF e reduz ainda mais a largura de banda de atualização. Esta solução destina-se a ser usada pelos clientes com a largura de banda mais limitada. Um exemplo
em que isto pode ser relevante é se as consultas do Web Risk estiverem incorporadas numa app para telemóvel.
Os utilizadores de uma app deste tipo certamente apreciariam uma solução de largura de banda inferior se
precisassem de atualizar a base de dados através de dados do telemóvel.
Para mais informações, consulte o artigo Compressão.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
