Overview

What are the Safe Browsing APIs?

The following Safe Browsing APIs are for non-commercial use only. If you need to use APIs to detect malicious URLs for commercial purposes – meaning “for sale or revenue-generating purposes” – please refer to the Web Risk API.

The Safe Browsing APIs (v4) let your client applications check URLs against Google's constantly updated lists of unsafe web resources. Examples of unsafe web resources are social engineering sites (phishing and deceptive sites) and sites that host malware or unwanted software. Any URL found on a Safe Browsing list is considered unsafe.

To determine if a URL is on any of the Safe Browsing lists, clients can use either the Lookup API (v4) or the Update API (v4).

Lookup API (v4)

The Lookup API lets your client applications send URLs to the Google Safe Browsing server to check their status. The API is simple and easy to use, as it avoids the complexities of the Update API.

Advantages:

  • Simple URL checks: You send an HTTP POST request with the actual URLs, and the server responds with the state of the URLs (safe or unsafe).

Drawbacks:

  • Privacy: URLs are not hashed, so the server knows which URLs you look up.
  • Response time: Every lookup request is processed by the server. We don't provide guarantees on lookup response time.

If you are not too concerned about the privacy of the queried URLs, and you can tolerate the latency induced by a network request, consider using the Lookup API since it's fairly easy to use.

Update API (v4)

The Update API lets your client applications download encrypted versions of the Safe Browsing lists for local, client-side checks of URLs. The Update API is designed for clients that require high frequency, low-latency verdicts. Several web browsers and software platforms use this API to protect large sets of users.

Advantages:

  • Privacy: You exchange data with the server infrequently (only after a local hash prefix match) and using hashed URLs, so the server never knows the actual URLs queried by the clients.
  • Response time: You maintain a local database that contains copies of the Safe Browsing lists; they do not need to query the server every time they want to check a URL.

Drawbacks:

  • Implementation: You need to set up a local database and then download, and periodically update, the local copies of the Safe Browsing lists (stored as variable-length SHA256 hashes).
  • Complex URL checks: You need to know how to canonicalize URLs, create suffix/prefix expressions, and compute SHA256 hashes (for comparison with the local copies of the Safe Browsing lists as well as the Safe Browsing lists stored on the server).

If you are concerned about the privacy of the queried URLs or the latency induced by a network request, use the Update API.