Skip to main content
La protection contre les menaces permet à votre organisation d’empêcher Firecrawl d’accéder à des URL à risque. Lorsqu’elle est activée, chaque URL qu’une requête tenterait de récupérer via l’API — une cible de scrape, un résultat de recherche, un lien découvert lors d’un crawl, l’URL de départ d’un agent — est vérifiée par rapport à la politique de votre organisation, et les URL qui ne respectent pas cette politique sont refusées. Les vérifications s’effectuent au niveau de l’URL : une seule page malveillante peut être bloquée tandis que le reste de son site reste accessible, et un site signalé est bloqué sur chacune de ses pages. La politique est définie une seule fois au niveau de l’organisation et s’applique automatiquement à chaque point de terminaison. Vous pouvez également autoriser des ajustements par requête, ou verrouiller la politique afin qu’aucune requête ne puisse l’assouplir.
La protection contre les menaces est une fonctionnalité Enterprise et est activée au niveau de l’organisation. Contactez l’équipe de compte Firecrawl pour l’activer sur votre compte.

​
Modes

La protection contre les menaces comporte deux modes, définis au niveau de l’organisation :
  • Désactivé (par défaut) — aucune vérification n’est effectuée.
  • Normal — les URL sont vérifiées à l’aide de Google Web Risk, qui signale les pages et les sites associés à des logiciels malveillants, à l’ingénierie sociale (phishing) et à des logiciels indésirables. +2 crédits par URL analysée.
Les vérifications sont conçues pour protéger vos données : dans l’immense majorité des requêtes, la vérification s’effectue localement à partir d’une liste de menaces synchronisée régulièrement. Les URL que vous scrapez ne sont donc jamais envoyées au classificateur, et Firecrawl ne stocke jamais de verdict concernant votre trafic.

​
Paramètres de la politique

Au-delà du classificateur, une politique peut inclure :
  • Liste noire personnalisée — des domaines exacts ou des motifs glob (par ex. *.example.com) qui sont toujours bloqués, sans appel au classificateur.
  • Liste blanche personnalisée — des domaines exacts ou des motifs glob qui sont toujours autorisés. La liste blanche prévaut sur toutes les autres règles : ainsi, un domaine de confiance n’est jamais bloqué.
  • TLD bloqués — des domaines de premier niveau à bloquer d’emblée (par ex. zip), avec correspondance sur les frontières de libellé.
  • Seuil de score de risque — le score normalisé (0–100) à partir duquel un verdict du classificateur est traité comme un blocage. Plus il est bas, plus la politique est stricte. La valeur par défaut est 75.
  • Politique en cas d’échec — que faire lorsque le classificateur est inaccessible : block (closed, valeur par défaut et option recommandée pour un contrôle de sécurité) ou allow (open).
Les règles de liste noire personnalisée, de liste blanche et de blocked-TLD s’appliquent au niveau du domaine — elles portent sur l’hôte de l’URL vérifiée ; seul le classificateur opère sur des URL complètes. Les domaines personnalisés que vous ajoutez à la liste noire ou à la liste blanche sont mis en correspondance à l’aide de la même canonicalisation d’hôte que le classificateur, afin que des encodages alternatifs d’une adresse (par exemple, une IP sous forme entière) ne puissent pas servir à contourner une entrée de liste.

​
Configuration de la politique

Les administrateurs de l’équipe configurent Protection contre les menaces depuis Enterprise Controls → Threat Protection dans le dashboard :
  1. Ouvrez Enterprise Controls → Threat Protection.
  2. Choisissez un mode, définissez votre seuil de risque et ajoutez des entrées de liste noire, de liste blanche ou de TLD bloqués.
  3. Choisissez d’autoriser ou non les dérogations par requête, puis définissez la politique en cas d’échec.
  4. Save. Les modifications prennent effet immédiatement — la requête suivante est évaluée selon la nouvelle politique.
Seuls les administrateurs de l’équipe peuvent consulter ou modifier la politique. Tous les autres disposent d’une vue en lecture seule.

​
Dérogations par requête

Chaque point de terminaison qui accepte des URL accepte également un objet threatProtection facultatif, afin qu’une requête donnée puisse renforcer (ou, si votre organisation l’autorise, ajuster) la politique appliquée à cet appel :
Les dérogations sont fusionnées avec la politique de l’organisation, champ par champ. Si votre organisation a désactivé les dérogations par requête, toute requête qui inclut un objet threatProtection est rejetée avec un 403 — cela permet à un administrateur de garantir que la politique de l’organisation constitue le niveau minimal pour chaque requête. Si la Protection contre les menaces est appliquée pour votre équipe, une dérogation peut toujours renforcer la politique, mais ne peut pas inclure "mode": "off" — toute requête qui tente de le faire est rejetée avec un 403.

​
Lorsqu’une URL est bloquée

Une requête bloquée renvoie un 403 et un code d’erreur stable :
Le comportement diffère légèrement selon le point de terminaison, selon ce qui est le plus utile :
  • Scrape, extraction par lot, extraction, agent — une cible bloquée renvoie l’erreur unsafe_domain_blocked pour cette URL.
  • Crawl — une URL de départ bloquée fait échouer la requête ; les liens bloqués découverts en cours de crawl sont ignorés et le crawl se poursuit.
  • Recherche, cartographie — les URL bloquées sont retirées des résultats renvoyés au lieu d’apparaître puis d’être refusées.
Si une requête est redirigée vers une URL différente — y compris une redirection sur le même site vers une autre page — la destination est vérifiée à nouveau, et le contenu d’une destination bloquée n’est jamais renvoyé. Pour agent, la politique couvre les URL de départ et tout ce que l’agent récupère via l’API Firecrawl ; les navigations que le Browser distant effectue dans une page ne sont pas interceptées.

​
Facturation

Un scan coûte +2 crédits par URL analysée en mode Normal, en plus du coût de base de la requête. Quelques précisions :
  • Les décisions prises uniquement sur la base de votre propre politique (liste noire, liste blanche ou correspondances avec des TLD bloqués) ne font pas appel au classificateur et n’entraînent pas de frais de scan.
  • Une requête bloquée est tout de même facturée pour le scan qui a produit le verdict.
  • Les scans sont dédupliqués au sein d’un même scrape : une revérification de redirection qui aboutit à la même URL réutilise le scan d’origine, tandis qu’une redirection vers une autre URL constitue un second scan.
  • Les crawls et les extractions par lot vérifient chaque page indépendamment. Les verdicts ne sont jamais réutilisés d’une page à l’autre — rien concernant votre trafic n’est stocké (voir ci-dessus) — donc, en mode Normal, comptez +2 crédits par page extraite. Le scan d’un lien découvert en cours de crawl et bloqué n’est facturé qu’une fois par crawl, quel que soit le nombre de pages qui pointent vers lui.
  • La recherche et la cartographie analysent chaque URL unique de l’ensemble de résultats une fois par requête ; leurs frais de scan dépendent donc du nombre de résultats analysés — qui peut légèrement dépasser le nombre renvoyé lorsque les résultats sont limités à votre limit.

​
Référence des erreurs

​
Remarques

  • La politique s’applique à toute l’organisation : elle concerne automatiquement chaque clé API et chaque point de terminaison.
  • La liste blanche a toujours priorité : une URL d’un domaine explicitement approuvé n’est donc jamais bloquée par le classificateur ni par une règle de TLD.
  • Le code d’erreur unsafe_domain_blocked est maintenu stable pour des raisons de compatibilité, même si les vérifications se font au niveau de l’URL.
  • Lorsque la politique en cas d’échec est définie sur closed (par défaut), une panne du classificateur entraîne le blocage des requêtes concernées au lieu de les autoriser silencieusement.