威胁防护

通过由您的组织控制的策略，在所有端点上封禁对高风险 URL 的请求，并在服务端强制执行。

威胁防护可让您的组织阻止 Firecrawl 访问高风险 URL。启用后，请求通过 API 将要获取的每个 URL——无论是抓取目标、搜索结果、爬取过程中发现的链接，还是代理的起始 URL——都会根据您组织的策略进行检查，未通过策略的 URL 会被拒绝访问。检查在 URL 级别进行：单个恶意页面可被封禁，而其所在站点的其余部分仍可访问；被标记的站点则会在所有页面上被封禁。

该策略只需在组织级别定义一次，便会自动应用到所有端点。您也可以允许按请求进行调整，或锁定该策略，使任何请求都无法削弱它。

威胁防护是一项企业版功能，按组织开通。如需为您的账户启用此功能，请联系您的 Firecrawl 账户团队。

​

模式

威胁防护 提供两种模式，可在组织级别设置：

• 关闭 (默认值) — 不进行任何检查。
• 正常 — URL 会与 Google Web Risk 进行比对；该服务会标记与恶意软件、社会工程攻击 (网络钓鱼) 和有害软件相关的页面和网站。每扫描一个 URL 需消耗 +2 额度。

这些检查旨在保护你的数据：对于绝大多数请求，检查都会基于定期同步的威胁列表在本地完成，因此你抓取的 URL 绝不会发送给分类器，Firecrawl 也不会存储关于你流量的任何判定结果。

​

策略控制

除了分类器外，策略还可以包含：

• 自定义黑名单 —— 始终封禁的精确域名或 glob (例如 *.example.com) ，无需调用分类器。
• 自定义白名单 —— 始终允许的精确域名或 glob。白名单优先于所有其他规则，因此你信任的域名绝不会被封禁。
• 封禁的 TLD —— 直接封禁的顶级域名 (例如 zip) ，按标签边界匹配。
• 风险评分阈值 —— 归一化分数 (0–100) ；达到或高于该分数时，分类器的判定会被视为封禁。数值越低，策略越严格。默认值为 75。
• 失败策略 —— 当无法访问分类器时的处理方式：封禁 (closed，默认值，也是安全控制场景下的推荐设置) 或 允许 (open) 。

自定义黑名单、白名单以及 blocked-TLD 规则都属于域名级别 —— 它们匹配的是被检查 URL 的主机；只有分类器会基于完整 URL 运行。你加入黑名单或白名单的自定义域名，会使用与分类器相同的主机规范化方式进行匹配，因此无法通过地址的其他编码形式 (例如整数形式的 IP) 绕过列表规则。

​

配置策略

团队管理员可在 Dashboard 的 Enterprise Controls → Threat Protection 中配置威胁防护：

1. 打开 Enterprise Controls → Threat Protection。
2. 选择一种模式，设置风险评分阈值，并添加黑名单、白名单或封禁的 TLD 条目。
3. 选择是否允许单次请求覆盖，并设置失败策略。
4. 保存。更改会立即生效——下一个请求将按新策略进行评估。

只有团队管理员可以查看或修改此策略。其他人只能看到只读视图。

​

单次请求覆盖

所有接受 URL 的端点也都支持可选的 threatProtection 对象，因此你可以针对单次请求收紧该次调用的策略 (或者，如果你的组织允许，也可以进行调整) ：

{
  "url": "https://example.com",
  "threatProtection": {
    "mode": "normal",
    "riskScoreThreshold": 50,
    "blacklist": ["*.risky.example"]
  }
}

覆盖项会按字段逐一合并到组织策略中。如果你的组织已禁用请求覆盖，任何包含 threatProtection 对象的请求都会被拒绝，并返回 403——这样管理员就能确保组织策略是每个请求都必须遵守的最低基线。

如果你的团队已强制执行威胁防护，覆盖项仍然可以收紧策略，但不能包含 "mode": "off"——任何试图这样做的请求都会被拒绝，并返回 403。

​

当 URL 被封禁时

被封禁的请求会以 403 失败，并返回一个固定的错误代码：

{
  "success": false,
  "code": "unsafe_domain_blocked",
  "error": "This URL (https://risky.example/landing) is blocked by your organization's threat protection policy (rule: blacklist). If you believe this is a mistake, contact your organization administrator to adjust the policy (e.g. whitelist the domain)."
}

不同端点的行为略有差异，会采用最实用的处理方式：

• Scrape, batch scrape, extract, 代理 — 被封禁的目标会针对该 URL 返回 unsafe_domain_blocked 错误。
• Crawl — 被封禁的种子 URL 会导致请求失败；在爬取过程中发现的被封禁链接会被跳过，爬取会继续。
• Search, map — 被封禁的 URL 会从返回结果中移除，而不是返回后再拒绝。

如果请求被重定向到其他 URL——包括站点内重定向到其他页面——系统会再次检查目标地址，并且绝不会返回来自被封禁目标地址的内容。对于 代理，该策略适用于起始 URL 以及代理通过 Firecrawl API 获取的所有内容；远程浏览器在页面内执行的导航不会被拦截。

​

计费

在 正常 模式下，URL 扫描会在请求的基础成本之外，按每个扫描 URL 额外收取 +2 额度。补充说明如下：

• 如果判定完全基于你自己的策略 (黑名单、白名单或 blocked-TLD 匹配) ，则不会调用分类器，因此不会收取扫描费用。
• 即使请求被封禁，生成该判定结果的扫描仍会照常收费。
• 在单次抓取中，扫描会去重：如果重定向复检最终解析到同一个 URL，则会复用原始扫描；而落到不同 URL 的重定向则算作第二次扫描。
• 抓取和批量抓取会独立检查每个页面。判定结果绝不会在页面之间复用——不会存储任何与你的流量有关的信息 (见上文) ——因此在 正常 模式下，预计会按每个抓取页面额外 +2 额度收费。在抓取过程中发现并被封禁的链接，无论有多少页面链接到它，每次抓取都只会对其扫描收费一次。
• 搜索和 map会在每次请求中对结果集里的每个唯一 URL 扫描一次，因此它们的扫描费用会随扫描结果数量增加——当结果因你的 limit 被截断时，这个数量可能会略高于最终返回的结果数。

​

错误参考

状态	何时出现
403	请求的目标 URL 被策略封禁 (code: unsafe_domain_blocked)。
403	请求包含 threatProtection 覆盖，但该组织已禁用覆盖设置。
403	团队强制启用威胁防护时，threatProtection 覆盖将 mode: "off"。
403	团队强制启用威胁防护时，组织策略被更新为 mode: "off"。
403	在未启用该功能的团队中使用了威胁防护选项。
403	团队强制启用威胁防护时调用了已弃用的 v0 endpoint (v0 不支持威胁防护) 。

​

说明

• 该策略在整个组织范围内生效：会自动应用于每个 API 密钥和每个端点。
• 白名单始终优先生效，因此位于被明确设为受信任域名上的 URL 绝不会被分类器或 TLD 规则封禁。
• 错误代码 unsafe_domain_blocked 会保持稳定以确保兼容性，尽管检查是在 URL 级别进行的。
• 当失败策略设为 closed (默认值) 时，如果分类器发生故障，受影响的请求会被封禁，而不会被默认放行。