Cabeceras Fetch Metadata: contexto CSRF y privacidad
Usa Sec-Fetch-* como contexto limitado para políticas del servidor, nunca como identidad, autenticación o garantía de privacidad.
BotBrowser Team
Quieres la documentación estructurada de Red?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
BotBrowser puede repetir un recorrido sintético autorizado con versión, perfil, ruta y aserción declarados. No convierte Sec-Fetch-* en identidad, no sustituye la autenticación, no prueba la intención de una persona ni garantiza que todos los navegadores y proxies envíen los mismos datos. La práctica segura es usar Fetch Metadata como una señal limitada de contexto y mantener separados el token CSRF, las cookies, la autorización y la revisión de privacidad.
TL;DR
- Fetch Metadata describe relación entre sitios, destino, modo y navegación; no son credenciales.
Sec-Fetch-Sitepuede añadir defensa CSRF para rechazar cambios de estado inesperados entre sitios.- Los encabezados pueden faltar. Define una rama de compatibilidad para clientes antiguos, nativos o no navegadores.
- Son metadatos de petición: reduce su retención y no los conviertas en huella o identidad.
- Prueba una matriz pequeña de mismo origen, mismo sitio, entre sitios, navegación superior y cliente sin encabezados.
Contents
- Qué describe Fetch Metadata
- Qué significa cada encabezado
- Construir una política CSRF
- Clientes sin encabezados y casos inusuales
- Límites de privacidad y observabilidad
- Fixture de política copiable
- Probar con BotBrowser
- Conclusión práctica
- FAQ
Qué describe Fetch Metadata
La especificación W3C Fetch Metadata permite observar el contexto en que un navegador inicia una petición. Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User y Sec-Fetch-Dest ayudan a distinguir una navegación de un recurso y una relación same-origin, same-site o cross-site. No dicen quién usa el navegador, si aprobó una acción ni si existe una cuenta autorizada. Una petición same-origin puede proceder de una página comprometida; una cross-site puede ser una imagen pública o un retorno OAuth legítimo. Clientes nativos, navegadores antiguos, workers, extensiones o intermediarios pueden omitirlos. La autenticación del servidor sigue siendo obligatoria.
Sec-Fetch-Site incluye same-origin, same-site, cross-site y none; same-site no equivale a same-origin. Sec-Fetch-Mode y Sec-Fetch-Dest ayudan a detectar una mutación con forma de subrecurso. Sec-Fetch-User: ?1 es una pista de navegación activada por usuario, no aprobación de pago ni atajo de login. Consulta MDN Fetch metadata y MDN Sec-Fetch-Site para la versión probada.
Qué significa cada encabezado
Define primero la transición de estado de la ruta. Un POST que cambia una cuenta necesita sesión, autorización y defensa CSRF. Usa Fetch Metadata como comprobación adicional: rechaza o desafía una mutación cross-site inesperada, pero permite un recurso público sin estado. Si falta el encabezado, exige token y autorización normales; no lo permitas automáticamente. Las excepciones de OAuth o pagos deben tener allowlist y state firmado.
Construir una política CSRF
Escribe una tabla de decisión antes del middleware: mutación same-origin con sesión y token válidos continúa; mutación cross-site se rechaza; lectura pública continúa; ausencia entra en compatibilidad. Comprueba método, ruta, sesión, token, Origin o Referer cuando corresponda y los campos Fetch Metadata juntos. Conserva sólo un código de motivo. No declares que cualquier subdominio same-site es de confianza si sus propietarios son distintos. Para rutas de alto riesgo puedes exigir una señal más fuerte, sin romper clientes documentados.
Clientes sin encabezados y casos inusuales
Apps móviles, CLI, WebView y gateways pueden omitir o modificar encabezados. Usa tokens, firmas o mTLS en sus contratos; no les pidas imitar un navegador. Observa por separado el borde y el origen. Las redirecciones, la precarga, los reintentos, los trabajadores del servicio y las extensiones generan combinaciones poco comunes: márcalas como observadas o desconocidas y ofrece una alternativa segura.
Límites de privacidad y observabilidad
Los campos revelan una relación y un destino aproximados al servidor. Minimiza retención, agrega métricas y no los unas a cuentas para seguimiento entre sitios. No son una huella estable: cambian por versión, navegación, extensión y proxy. BotBrowser puede observarlos en una ruta sintética autorizada, pero no prueba retención de terceros ni el impacto de un pipeline productivo. Usa valores sintéticos y consulta la documentación de cabeceras HTTP personalizadas.
Fixture de política copiable
function contextDecision(req) {
const changing = ['POST', 'PUT', 'PATCH', 'DELETE'].includes(req.method);
const site = req.headers['sec-fetch-site'];
const mode = req.headers['sec-fetch-mode'];
const dest = req.headers['sec-fetch-dest'];
if (!changing) return { action: 'continue', reason: 'read-only' };
if (!req.user || !validCsrfToken(req)) return { action: 'reject', reason: 'authentication-or-csrf' };
if (site === 'cross-site') return { action: 'reject', reason: 'unexpected-cross-site' };
if (site === undefined) return { action: 'challenge', reason: 'missing-context' };
if (mode === 'no-cors' || dest === 'image' || dest === 'script')
return { action: 'reject', reason: 'subresource-shape' };
return { action: 'continue', reason: 'declared-context' };
}
El resultado esperado es continuar sólo con sesión y token válidos en un contexto permitido; rechazar cross-site y forma de subrecurso; y desafiar la ausencia. Aún se validan cuerpo, autorización, replay y reglas de negocio.
Probar con BotBrowser
Usa un endpoint sintético que devuelva una decisión redactada. Fija navegador, perfil, origen, método, destino y estado esperado. Ejecuta same-origin, same-site, cross-site mutation, imagen pública cross-site, navegación superior y cliente sin campos, además de un token inválido. Registra entrada declarada, presencia y valores, decisión, estado y limitaciones. No recolectes cuentas, credenciales, URLs privadas ni inventarios amplios. Repite la misma fixture después de una actualización para comparar.
Conclusión práctica
Fetch Metadata es contexto limitado. Combínalo con autenticación, autorización, CSRF, Origin, semántica de ruta y contratos de callback. Define la ausencia antes de aplicar enforcement, minimiza los motivos de registro y pide al responsable del servicio que apruebe excepciones. Nunca afirmes que Sec-Fetch-* prueba persona, navegador confiable, consentimiento o privacidad.
FAQ
¿Puede Sec-Fetch-Site reemplazar un token CSRF?
No. Puede faltar y no es un secreto validado. Mantén una defensa CSRF explícita.
¿same-origin significa autenticado?
No. Valida sesión, autorización, token y reglas de negocio por separado.
¿Debo rechazar toda petición sin Fetch Metadata?
No necesariamente. Clientes legítimos pueden omitirlo; usa una política por ruta.
¿Son una huella?
No son identidad estable. Cambian con navegador, navegación e intermediarios; no los uses para seguimiento.
¿Qué valida BotBrowser?
Una observación repetible de una ruta sintética declarada, no la retención de terceros ni la conducta universal.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.