Safe Browsing Lookup API (v4)
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
概览
借助 Lookup API,您的客户端应用可以向安全浏览功能发送请求
服务器来检查网址是否包含在任何安全浏览列表中。如果网址存在于某一个或
更多列表,则返回匹配信息。
检查网址
要检查某个网址是否在安全浏览列表中,请将 HTTP POST
请求发送到
threatMatches.find
方法:
- HTTP
POST
请求最多可包含 500 个网址。网址必须有效
(请参阅 RFC 2396)
但无需进行规范化或编码。
- HTTP
POST
响应会返回匹配的网址以及缓存时长。
示例:tallMatches.find
HTTP POST 请求
在以下示例中,系统会将两个安全浏览列表和三个网址发送给服务器,
确定是否存在匹配。
请求标头包含请求网址和内容类型。请务必将
您在网址中为 API_KEY
设置的 API 密钥。
POST https://safebrowsing.googleapis.com/v4/threatMatches:find?key=API_KEY HTTP/1.1
Content-Type: application/json
请求正文
请求正文包含客户端信息(ID 和版本)以及威胁信息
(列表名称和网址)。有关详情,请参阅
threatMatches.find 请求正文
以及相应代码示例的说明。
{
"client": {
"clientId": "yourcompanyname",
"clientVersion": "1.5.2"
},
"threatInfo": {
"threatTypes": ["MALWARE", "SOCIAL_ENGINEERING"],
"platformTypes": ["WINDOWS"],
"threatEntryTypes": ["URL"],
"threatEntries": [
{"url": "http://www.urltocheck1.org/"},
{"url": "http://www.urltocheck2.org/"},
{"url": "http://www.urltocheck3.com/"}
]
}
}
clientID
和 clientVersion
字段应唯一标识客户端实现,而不是
单个用户(客户端信息用于服务器端日志记录和计算。您可以选择
但我们建议您选择一个可代表客户端 ID 的真实身份的名称,
客户(如您的公司名称)以全小写字母显示。
安全浏览列表
threatType
、platformType
和 threatEntryType
字段
组合在一起来识别(名称)安全浏览列表。此示例中标识了两个列表:
MALWARE/WINDOWS/网址 和 SOCIAL_ENGINEERING/WINDOWS/网址。在发送请求前,请确保请求类型
指定的组合有效(请参阅安全浏览列表)。
威胁网址
在此示例中,threatEntries
数组包含三个网址(urltocheck1.org、urltocheck2.org、
和 urltocheck3.org)将会被对照两个安全浏览列表进行检查。
注意:Lookup API 和 threatMatches
方法应始终使用 URL
字段,
一律不使用 hash
字段(请参阅 ThreatEntry)。
HTTP POST 响应
在以下示例中,响应会返回一个匹配项;在
会在请求中指定的两个安全浏览列表之一中找到此类请求。
响应标头包含 HTTP 状态代码
和内容类型
HTTP/1.1 200 OK
Content-Type: application/json
响应正文
响应正文包括匹配信息(列表名称和在以下位置找到的网址:
这些列表、元数据(如果有)和缓存时长)。有关详情,请参阅
threatMatches.find 响应正文
以及相应代码示例的说明。
注意:如果没有匹配项(即没有指定任何网址),
(例如请求中指定的任何列表上)发现,则 HTTP POST
响应
只会在响应正文中返回一个空对象。
{
"matches": [{
"threatType": "MALWARE",
"platformType": "WINDOWS",
"threatEntryType": "URL",
"threat": {"url": "http://www.urltocheck1.org/"},
"threatEntryMetadata": {
"entries": [{
"key": "malware_threat_type",
"value": "landing"
}]
},
"cacheDuration": "300.000s"
}, {
"threatType": "MALWARE",
"platformType": "WINDOWS",
"threatEntryType": "URL",
"threat": {"url": "http://www.urltocheck2.org/"},
"threatEntryMetadata": {
"entries": [{
"key": "malware_threat_type",
"value": "landing"
}]
},
"cacheDuration": "300.000s"
}]
}
匹配
matches
对象会列出安全浏览列表的名称和网址(如果
匹配。在该示例中,我们在某个网页上发现两个网址(urltocheck1.org 和 urltocheck2.org)
安全浏览列表(恶意软件/窗口/网址),因此会返回匹配的信息。第三个网址
(urltocheck3.org) 在这两个列表中都找不到,因此系统不会返回此网址的任何信息。
threatEntryMetadata
字段为可选字段,提供
威胁匹配。目前,元数据适用于恶意软件/WINDOWS/网址安全浏览列表
(请参阅元数据)。
缓存时长
cacheDuration
字段用于指明在多长时间内网址必须被视为不安全网址
(请参阅缓存)。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-25。
[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eThe Lookup API allows client applications to send requests to Safe Browsing servers to check if URLs are on any Safe Browsing lists, returning matching information if found.\u003c/p\u003e\n"],["\u003cp\u003eTo check URLs, send an HTTP \u003ccode\u003ePOST\u003c/code\u003e request to the \u003ccode\u003ethreatMatches.find\u003c/code\u003e method, including up to 500 URLs in the request body with desired threat types and platform types.\u003c/p\u003e\n"],["\u003cp\u003eThe API response returns an empty object if no matches are found, or a \u003ccode\u003ematches\u003c/code\u003e object containing matching URLs, list names, metadata (if available), and cache durations.\u003c/p\u003e\n"],["\u003cp\u003eClient applications should uniquely identify themselves using \u003ccode\u003eclientId\u003c/code\u003e and \u003ccode\u003eclientVersion\u003c/code\u003e fields in the request body for server-side logging and accounting.\u003c/p\u003e\n"],["\u003cp\u003eThe API uses the \u003ccode\u003eURL\u003c/code\u003e field for threat entries and currently provides metadata for the MALWARE/WINDOWS/URL Safe Browsing list.\u003c/p\u003e\n"]]],["The Lookup API checks URLs against Safe Browsing lists via HTTP `POST` requests to the `threatMatches.find` method, which can include up to 500 URLs. Requests specify client and threat information, including threat types, platform types, and URLs. The response indicates matches, providing the list names, matching URLs, optional metadata, and cache duration. If no matches are found, the response returns an empty object. Client information must uniquely identify client implementations.\n"],null,["# Safe Browsing Lookup API (v4)\n\nOverview\n--------\n\nThe Lookup API lets your client applications send requests to the Safe Browsing\nservers to check if URLs are included on any of the Safe Browsing lists. If a URL is found on one or\nmore lists, the matching information is returned.\n\nChecking URLs\n-------------\n\nTo check if a URL is on a Safe Browsing list, send an HTTP `POST` request to the\n[threatMatches.find](/safe-browsing/reference/rest/v4/threatMatches/find)\nmethod:\n\n- The HTTP `POST` request can include up to 500 URLs. The URLs must be valid (see [RFC 2396](http://www.ietf.org/rfc/rfc2396.txt)) but they do not need to be canonicalized or encoded.\n- The HTTP `POST` response returns the matching URLs along with the cache duration.\n\nExample: threatMatches.find\n---------------------------\n\n### HTTP POST request\n\nIn the following example, two Safe Browsing lists and three URLs are sent to the server to\ndetermine if there is a match.\n\n#### Request header\n\nThe request header includes the request URL and the content type. Remember to substitute\nyour API key for `API_KEY` in the URL. \n\n```scdoc\n POST https://safebrowsing.googleapis.com/v4/threatMatches:find?key=API_KEY HTTP/1.1\n Content-Type: application/json\n \n```\n\n#### Request body\n\nThe request body includes the client information (ID and version) and the threat information\n(the list names and the URLs). For more details, see the\n[threatMatches.find request body](/safe-browsing/reference/rest/v4/threatMatches/find#request-body)\nand the explanations that follow the code example. \n\n```scdoc\n {\n \"client\": {\n \"clientId\": \"yourcompanyname\",\n \"clientVersion\": \"1.5.2\"\n },\n \"threatInfo\": {\n \"threatTypes\": [\"MALWARE\", \"SOCIAL_ENGINEERING\"],\n \"platformTypes\": [\"WINDOWS\"],\n \"threatEntryTypes\": [\"URL\"],\n \"threatEntries\": [\n {\"url\": \"http://www.urltocheck1.org/\"},\n {\"url\": \"http://www.urltocheck2.org/\"},\n {\"url\": \"http://www.urltocheck3.com/\"}\n ]\n }\n }\n```\n\n###### Client information\n\nThe `clientID` and `clientVersion` fields should uniquely identify a client implementation, not an\nindividual user. (Client information is used for server-side logging and accounting. You can choose\nany name for the client ID, but we suggest you choose a name that represents the true identity of the\nclient, such as your company name, presented as all one word, in all-lowercase letters.)\n\n###### Safe Browsing lists\n\nThe `threatType`, `platformType`, and `threatEntryType` fields\nare combined to identify (name) Safe Browsing lists. In the example, two lists are identified:\nMALWARE/WINDOWS/URL and SOCIAL_ENGINEERING/WINDOWS/URL. Before sending a request, make sure the type\ncombinations you specify are valid (see [Safe Browsing Lists](/safe-browsing/v4/lists)).\n\n###### Threat URLs\n\nIn the example, the `threatEntries` array contains three URLs (urltocheck1.org, urltocheck2.org,\nand urltocheck3.org) that will be checked against the two Safe Browsing lists.\n\n**Note:** The Lookup API and the `threatMatches` method should always use the `URL` field,\nnever the `hash` field (see [ThreatEntry](/safe-browsing/reference/rest/v4/ThreatEntry)).\n\n### HTTP POST response\n\nIn the following example, the response returns a match; two of the three URLs specified in the\nrequest are found on one of the two Safe Browsing lists specified in the request.\n\n#### Response header\n\nThe response header includes the [HTTP status code](/safe-browsing/v4/status-codes)\nand the content type. \n\n```http\nHTTP/1.1 200 OK\nContent-Type: application/json\n```\n\n#### Response body\n\nThe response body includes the match information (the list names and the URLs found on\nthose lists, the metadata, if available, and the cache durations). For more details, see the\n[threatMatches.find response body](/safe-browsing/reference/rest/v4/threatMatches/find#response-body)\nand the explanations that follow the code example.\n\n**Note:** If there are no matches (that is, if *none* of the URLs specified\nin the request are found on *any* of the lists specified in a request), the HTTP `POST` response\nsimply returns an empty object in the response body. \n\n```carbon\n{\n \"matches\": [{\n \"threatType\": \"MALWARE\",\n \"platformType\": \"WINDOWS\",\n \"threatEntryType\": \"URL\",\n \"threat\": {\"url\": \"http://www.urltocheck1.org/\"},\n \"threatEntryMetadata\": {\n \"entries\": [{\n \"key\": \"malware_threat_type\",\n \"value\": \"landing\"\n }]\n },\n \"cacheDuration\": \"300.000s\"\n }, {\n \"threatType\": \"MALWARE\",\n \"platformType\": \"WINDOWS\",\n \"threatEntryType\": \"URL\",\n \"threat\": {\"url\": \"http://www.urltocheck2.org/\"},\n \"threatEntryMetadata\": {\n \"entries\": [{\n \"key\": \"malware_threat_type\",\n \"value\": \"landing\"\n }]\n },\n \"cacheDuration\": \"300.000s\"\n }]\n}\n```\n\n###### Matches\n\nThe `matches` object lists the names of the Safe Browsing lists and the URLs---if\nthere is match. In the example, two URLs (urltocheck1.org and urltocheck2.org) were found on one of\nthe Safe Browsing lists (MALWARE/WINDOWS/URL) so the matching information is returned. The third URL\n(urltocheck3.org) was not found on either list, so no information is returned for this URL.\n\n###### Metadata\n\nThe `threatEntryMetadata` field is optional and provides additional information about\nthe threat match. Currently, metadata is available for the MALWARE/WINDOWS/URL Safe Browsing list\n(see [Metadata](/safe-browsing/v4/metadata)).\n\n###### Cache durations\n\nThe `cacheDuration` field indicates the amount of time the URL must be considered unsafe\n(see [Caching](/safe-browsing/v4/caching))."]]