Skip to main content
La Protección contra amenazas permite a tu organización impedir que Firecrawl acceda a URL riesgosas. Cuando está habilitada, cada URL que una solicitud intentaría obtener a través de la API —un objetivo de scraping, un resultado de búsqueda, un enlace descubierto durante un rastreo o la URL inicial de un agente— se comprueba con la política de tu organización, y las URL que no cumplan la política se bloquean. Las comprobaciones se realizan a nivel de URL: se puede bloquear una sola página maliciosa mientras el resto de su sitio sigue siendo accesible, y un sitio marcado se bloquea en todas sus páginas. La política se define una sola vez a nivel de la organización y se aplica automáticamente a todos los endpoints. También puedes permitir ajustes por solicitud o bloquear la política para que ninguna solicitud pueda debilitarla.
La Protección contra amenazas es una función empresarial y se habilita por organización. Ponte en contacto con el equipo de cuenta de Firecrawl para activarla en tu cuenta.

​
Modos

Threat Protection tiene tres modos, configurados a nivel de la organización:
  • Desactivado (predeterminado) — no se realizan verificaciones.
  • Normal — las URL se verifican con Google Web Risk, que marca páginas y sitios asociados con malware, ingeniería social (phishing) y software no deseado. +2 créditos por URL escaneada.
  • Zscaler — las URL se verifican con el tenant de Zscaler Internet Access (ZIA) de tu organización: las categorías de URL definidas por Zscaler que selecciones bloquear, además de tus categorías de URL personalizadas y listas de URL personalizadas. Consulta el modo Zscaler a continuación. Sin tarifas de escaneo — la clasificación se realiza en tu propio tenant.
Las verificaciones están diseñadas para proteger tus datos. En el modo Normal, la inmensa mayoría de las solicitudes se resuelven localmente con una lista de amenazas sincronizada periódicamente, por lo que las URL que extraes nunca se envían al clasificador. En el modo Zscaler, la clasificación de URL se realiza en tu propio tenant de ZIA — el mismo sistema que ya conoce la política web de tu organización. En todos los modos, Firecrawl nunca almacena ningún veredicto sobre tu tráfico.

​
Controles de la política

Además del clasificador, una política puede incluir:
  • Lista negra personalizada — dominios exactos o patrones globales (p. ej., *.example.com) que siempre se bloquean, sin llamar al clasificador.
  • Lista blanca personalizada — dominios exactos o patrones globales que siempre se permiten. La lista blanca prevalece sobre cualquier otra regla, por lo que un dominio de confianza nunca se bloquea.
  • TLD bloqueados — dominios de nivel superior que se bloquean directamente (p. ej., zip), con coincidencia en los límites de las etiquetas.
  • Umbral de puntuación de riesgo — la puntuación normalizada (0–100) a partir de la cual un veredicto del clasificador se considera un bloqueo. Cuanto más bajo, más estricto. El valor predeterminado es 75. Se aplica al modo Normal; el modo Zscaler bloquea por categoría en su lugar.
  • Política ante fallos — qué hacer cuando no se puede acceder al clasificador: bloquear (closed, la opción predeterminada y recomendada para un control de seguridad) o permitir (open).
Las reglas personalizadas de lista negra, lista blanca y TLD bloqueados son a nivel de dominio: coinciden con el host de la URL que se está comprobando; solo el clasificador opera sobre URL completas. Los dominios personalizados que incluyas en la lista negra o blanca se comparan usando la misma canonicalización de host que el clasificador, de modo que no se puedan usar codificaciones alternativas de una dirección (por ejemplo, una IP en formato entero) para eludir una entrada de la lista.

​
Modo Zscaler

El modo Zscaler permite a las organizaciones que ya mantienen políticas de URL en ZIA aplicarlas al tráfico de Firecrawl sin tener que mantener una taxonomía paralela. Funcionan en conjunto dos mecanismos:
  • Clasificación en línea — las URL se clasifican mediante la API URL Lookup de tu tenant en categorías definidas por Zscaler, y se bloquean las URL que pertenezcan a una categoría que hayas denegado.
  • Reglas personalizadas sincronizadas — tus categorías de URL personalizadas (listas de URL y palabras clave), así como las categorías definidas por Zscaler que hayas ampliado, se sincronizan periódicamente desde el tenant y Firecrawl las evalúa directamente, ya que la API de consulta de ZIA no devuelve clasificaciones personalizadas. Las entradas eliminadas en ZIA desaparecen en la siguiente sincronización; también puedes seleccionar manualmente Sincronizar ahora en el dashboard.
La garantía es tus listas personalizadas más las categorías de Zscaler que hayas seleccionado, no «idéntico a tu política de ZIA». Las reglas de ZIA también pueden depender de usuarios, grupos, ubicaciones, la hora del día y el contexto de la solicitud, aspectos que Firecrawl no reproduce. Las reglas de palabras clave de las categorías personalizadas se aplican según el mejor esfuerzo (coincidencia de URL sin distinción entre mayúsculas y minúsculas); las entradas exactas de las listas de URL deben coincidir exactamente.

​
Conecta tu tenant

Los administradores del equipo conectan el tenant desde el dashboard (consulta más abajo) mediante un cliente OAuth de Zidentity: ID de cliente, secreto de cliente y tu dominio personalizado de Zidentity. Usa un rol de API con privilegios mínimos limitado a Categorías de URL. El botón Probar conexión verifica por separado las credenciales, el acceso a la taxonomía y el acceso a URL Lookup, de modo que un rol que puede leer categorías pero no clasificar URL se detecta durante la configuración, en lugar de en tu primer scraping. El secreto de cliente es de solo escritura y está cifrado en reposo; la compatibilidad de Zscaler con dos secretos activos te permite rotarlos sin tiempo de inactividad. Después de conectarlo, elige las categorías que quieres bloquear de la propia taxonomía de tu tenant; en el selector aparecen tanto las categorías definidas por Zscaler como las personalizadas. El tráfico de clasificación hacia tu tenant procede de una IP estática dedicada para incluir en la lista de permitido; solicita la dirección a tu equipo de cuenta.

​
Capacidad y comportamiento

La API URL Lookup de ZIA permite 1 solicitud por segundo y 400 solicitudes por hora por tenant. Firecrawl agrupa las consultas en lotes (hasta 100 URL por solicitud) y aplica estos límites a nivel de tenant, lo que permite una clasificación sostenida de aproximadamente 11 URL por segundo. El rendimiento de scraping nunca se limita: cuando la demanda supera el presupuesto o se agota el presupuesto horario, las solicitudes afectadas se resuelven de inmediato según su política de fallos, en lugar de quedar en cola indefinidamente. Dos diferencias a nivel de endpoint respecto al modo Normal:
  • Los resultados de mapeo se evalúan únicamente según reglas locales (sus listas y las reglas personalizadas sincronizadas), en lugar de clasificarse en línea: un mapeo puede devolver miles de URL, y clasificarlas consumiría el presupuesto horario en enlaces que quizá nunca se obtengan. Cada URL sigue sometiéndose a la comprobación completa cuando comienza su scraping.
  • Los resultados de búsqueda se clasifican en línea y los resultados bloqueados se eliminan, igual que en el modo Normal; cada resultado único consume parte del presupuesto horario de consultas.
Los veredictos nunca se almacenan en caché ni se guardan (como en todos los modos), por lo que un cambio de clasificación en Zscaler se aplica en la siguiente solicitud, y los cambios en las listas personalizadas, en la siguiente sincronización.

​
Configuración de la política

Los administradores del equipo configuran la Protección contra amenazas desde Controles empresariales → Protección contra amenazas en el dashboard:
  1. Abre Controles empresariales → Protección contra amenazas.
  2. Selecciona un modo, define el umbral de puntuación de riesgo y añade cualquier entrada a la lista negra, lista blanca o TLD bloqueados.
  3. Para el modo Zscaler: introduce la conexión del tenant, ejecuta la prueba de conexión, selecciona las categorías que quieres bloquear y define el intervalo de sincronización.
  4. Selecciona si se permiten anulaciones por solicitud y define la política ante fallos.
  5. Guarda. Los cambios se aplican de inmediato: la siguiente solicitud se evalúa según la nueva política.
Solo los administradores del equipo pueden ver o cambiar la política. El resto solo puede verla en modo de solo lectura.

​
Anulaciones por solicitud

Cada endpoint que acepta URL también acepta un objeto threatProtection opcional, de modo que una solicitud concreta puede reforzar (o, si su organización lo permite, ajustar) la política para esa llamada:
Las anulaciones se aplican a la política de la organización campo por campo. Si su organización ha deshabilitado las anulaciones de solicitud, cualquier solicitud que incluya un objeto threatProtection se rechaza con un 403; esto permite a un administrador garantizar que la política de la organización sea el nivel mínimo para cada solicitud. Una anulación puede seleccionar "mode": "zscaler" solo cuando la organización tiene configurada una conexión de Zscaler; la conexión en sí y la selección de categorías denegadas son de nivel organizacional y no se pueden establecer por solicitud. Si la Protección contra amenazas se aplica a su equipo, una anulación aún puede reforzar la política, pero no puede incluir "mode": "off"; una solicitud que lo intente se rechaza con un 403.

​
Cuando una URL está bloqueada

Una solicitud bloqueada devuelve un 403 y un código de error estable:
El comportamiento varía ligeramente según el endpoint, en función de lo que sea más útil:
  • Scrape, extracción por lotes, extract, agent — un objetivo bloqueado devuelve el error unsafe_domain_blocked para esa URL.
  • Crawl — una URL semilla bloqueada hace que falle la solicitud; los enlaces bloqueados que se descubren durante el rastreo se omiten y el rastreo continúa.
  • Search, map — las URL bloqueadas se eliminan de los resultados devueltos en lugar de mostrarse y ser rechazadas.
Si una solicitud se redirige a una URL distinta — incluida una redirección dentro del mismo sitio hacia otra página — el destino se vuelve a comprobar, y nunca se devuelve contenido de un destino bloqueado. Para agent, la política cubre las URL iniciales y todo lo que el agent obtiene mediante la API de Firecrawl; las navegaciones que el browser remoto realiza dentro de una página no se interceptan.

​
Facturación

En modo Normal, un escaneo cuesta +2 créditos por URL analizada, además del costo base de la solicitud. El modo Zscaler no tiene cargos por escaneo: la clasificación se realiza en tu propio tenant de ZIA, con tus credenciales y tu cuota de API, por lo que los detalles sobre los cargos por escaneo a continuación se aplican solo al modo Normal. Algunos detalles:
  • Las decisiones tomadas exclusivamente según tu propia política (coincidencias con listas negras, listas blancas o TLD bloqueados) no pasan por el clasificador y no generan ningún cargo por escaneo.
  • Una solicitud bloqueada igualmente genera el cargo por el escaneo que produjo el veredicto.
  • Los escaneos se deduplican dentro de un solo scraping: una nueva comprobación de una redirección que se resuelve en la misma URL comparte el escaneo original, mientras que una redirección que llega a una URL diferente cuenta como un segundo escaneo.
  • Los rastreos y las extracciones por lotes verifican cada página de forma independiente. Los veredictos nunca se reutilizan entre páginas — no se almacena nada sobre tu tráfico (consulta arriba) — así que, en modo Normal, debes prever +2 créditos por página extraída. Un enlace que se descubre durante el rastreo y se bloquea factura su escaneo una vez por rastreo, sin importar cuántas páginas enlacen a él.
  • Las búsquedas y los mapeos escanean cada URL única del conjunto de resultados una vez por solicitud, por lo que sus cargos por escaneo aumentan en función de la cantidad de resultados escaneados, que puede superar ligeramente la cantidad devuelta cuando los resultados se recortan a tu limit.

​
Referencia de errores

​
Notas

  • La política abarca toda la organización: se aplica automáticamente a cada API key y a cada endpoint.
  • La lista blanca siempre prevalece, por lo que una URL en un dominio marcado explícitamente como de confianza nunca es bloqueada por el clasificador ni por una regla de TLD.
  • El código de error unsafe_domain_blocked se mantiene estable por compatibilidad, aunque las comprobaciones se realizan a nivel de URL.
  • Con la política de fallos establecida en closed (la predeterminada), una interrupción del clasificador hace que las solicitudes afectadas se bloqueen en lugar de permitirse silenciosamente.
  • Con SIEM Audit Logging configurado, cada decisión es visible en tu registro de auditoría: los eventos incluyen la regla que determinó la decisión, el clasificador consultado, las categorías de amenazas y —en el caso de las URL clasificadas por Zscaler— una marca security_alert cuando la URL tiene una clasificación de alerta de seguridad.