¿Puedo simplemente redactar el archivo a mano en un editor de texto?

Puedes — un archivo HAR es JSON, y cualquier editor de texto puede abrir uno — pero la redacción a mano es exactamente cómo sobreviven los secretos: el mismo token aparece en una cabecera, una lista de cookies, la cadena de la URL y los parámetros de consulta, y perder una copia deja la credencial viva. Una pasada automática que sustituye valores por regla, en todos los lugares donde aparecen, es la forma aburrida y correcta. Hagas lo que hagas, busca en el archivo terminado un fragmento de cada secreto que sabías que contenía antes de enviarlo.

¿Un HAR redactado sigue sirviendo al ingeniero de soporte?

Sí — ese es el sentido de redactar valores en lugar de eliminar entradas. El ingeniero conserva la secuencia de peticiones, los métodos, las formas de las URL, los nombres de cabecera, los estados, tamaños y tiempos, que es lo que el diagnóstico realmente usa; lo que pierde es solo los valores de credencial en vivo, que nunca necesitó. Si un ingeniero necesita de verdad ver un valor, eso es una conversación que hay que tener explícitamente — y normalmente termina con él aceptando que el archivo redactado basta.

Ya envié un archivo HAR sin redactar. ¿Qué debo hacer ahora?

Trata la sesión que contiene como pública. Cierra la sesión del servicio en todas partes (la mayoría de los servicios tienen un control de «cerrar todas las sesiones», que invalida las cookies capturadas), vuelve a entrar y rota cualquier clave de API o token que apareciera en la captura. Luego responde en el mismo ticket o hilo pidiendo que se borre el adjunto. No envíes un segundo archivo redactado y lo des por arreglado — la redacción protege las copias futuras, no la ya entregada.

Antes de enviar ese archivo HAR, lee lo que lleva dentro

By John · Former Microsoft engineer with 20 years of experience.

«¿Podrías enviarnos un archivo HAR?» es una petición razonable — y una de las entregas de archivos más casualmente peligrosas del trabajo de soporte cotidiano. Un archivo HAR es una grabación completa de una sesión del navegador: cada petición y cada respuesta, con las cookies, las cabeceras de autorización, los tokens y el contenido de los formularios que las hicieron funcionar. Es exactamente lo que un ingeniero de soporte necesita para reproducir tu problema, y exactamente lo que un atacante querría para reproducir tu sesión. Este artículo explica qué es un archivo HAR, cómo capturar uno en Chrome, Edge o Firefox, qué filtra y cómo inspeccionarlo y redactarlo antes de que vaya a ninguna parte.

Qué es un archivo HAR

HAR — HTTP Archive — es un formato JSON para grabar tráfico HTTP, estandarizado en la especificación HAR 1.2 y exportado por las herramientas de desarrollo de todos los navegadores importantes y por proxies de depuración como mitmproxy. El archivo contiene un objeto log con un array entries: una entrada por petición, cada una con el método y la URL completa, las cabeceras de petición y respuesta, las cookies en ambas direcciones, la cadena de consulta desglosada en parámetros, cualquier cuerpo POST, el estado, tamaño y tipo de contenido de la respuesta, y los tiempos desglosados por fase — DNS, conexión, TLS, envío, espera, recepción.

En otras palabras, no es una captura de pantalla del problema; es el problema, reproducible. Todo lo que consume tráfico HTTP trabaja con el formato — herramientas del navegador, analizadores de rendimiento, ingenieros de soporte y, cada vez más, agentes: la pila REA tratada en ¿pueden los agentes de IA hacer ingeniería inversa de tu app? lee capturas HAR de forma nativa, porque para muchas aplicaciones el tráfico de la API explica más que el código. Esa utilidad es exactamente la razón por la que el archivo merece una lectura antes de merecer un envío.

Por qué los equipos de soporte y los proveedores piden uno

Porque pone fin a las discusiones. «La página va lenta» se convierte en una cascada con peticiones nombradas y tiempos. «La API falla» se convierte en la petición exacta que devolvió 500, con la carga exacta y las cabeceras exactas. «En mi máquina funciona» deja de importar, porque la grabación es de tu máquina, tu red, tu cuenta, en el momento en que se rompió. Un buen ingeniero de soporte puede hacer más con un archivo HAR honesto que con una semana de capturas de pantalla y recuerdos.

Por eso también la petición se reenvía tan a menudo sin pensar. El ticket dice «adjunta un HAR», el usuario exporta uno en treinta segundos, y el archivo —grabado mientras estaba conectado, haciendo trabajo real— empieza a viajar: a un sistema de tickets, a un hilo de correo, a veces a un foro público o una unidad compartida, acumulando copias en cada salto. Nadie en esa cadena es exactamente descuidado; el formato simplemente oculta lo que contiene. Un archivo .har parece un diagnóstico inerte. Se parece más a un llavero.

Cómo capturar uno en Chrome, Edge o Firefox

En Chrome o Edge: abre la página, pulsa F12 para las DevTools y ve al panel Red (la referencia de red de Chrome DevTools documenta cada control). Asegúrate de que el botón rojo de grabación está activo y marca Conservar registro si el problema abarca una navegación. Reproduce el problema una vez, de principio a fin. Luego haz clic derecho en cualquier petición de la lista y elige Guardar todo como HAR con contenido (Edge lo formula como guardar el registro de red). En Firefox el flujo tiene la misma forma: DevTools → Red, reproducir, clic derecho → Guardar todo como HAR.

Dos hábitos de captura importan más que cualquier ajuste. Primero, graba la sesión más corta que muestre el problema: cada minuto extra de navegación es tráfico extra — y secretos extra — en el archivo, incluido lo que otras pestañas y peticiones en segundo plano estaban haciendo. Segundo, si puedes, reproduce el problema en un perfil de navegador nuevo o en una ventana privada, conectado solo al servicio en cuestión. Una captura de un perfil limpio contiene esa única sesión y nada más: ni pestaña del banco, ni correo web, ni tokens de otras aplicaciones viajando dentro.

Qué filtra

Tu sesión, en primer lugar. Las cabeceras Cookie y Set-Cookie y las listas de cookies llevan tus identificadores de sesión, y la mayoría de las cookies de sesión son credenciales al portador en el sentido más llano: quien presenta una es tratado como tú hasta que caduca o se revoca. La cabecera Authorization añade tokens portadores y, a veces, credenciales Basic. Nada en el formato marca estos valores como especiales; son solo cabeceras, grabadas fielmente.

Luego, las cosas que nadie considera cabeceras. Los tokens viajan en las URL todo el tiempo — claves de API, enlaces de restablecimiento de contraseña y verificación de correo, URL de descarga firmadas, devoluciones de llamada de OAuth — y el HAR graba la URL completa más la cadena de consulta desglosada para leerla cómodamente. Los cuerpos POST llevan lo que llevaban los formularios: la contraseña con la que iniciaste sesión durante la captura, ediciones de perfil, mensajes, datos personales. Los cuerpos de respuesta pueden traer la misma clase de datos de vuelta. Un archivo HAR de una sesión real es, en efecto, una transcripción parcial de tu cuenta — por eso las herramientas que leen el tráfico de red en la línea, como el PCAP Analyzer, y las que lo leen en el navegador, como esta página, están hechas para mostrar las credenciales con claridad, para que veas lo que tienes entre manos.

Inspecciónalo y redáctalo antes de enviarlo

Así que: abre el archivo antes que nadie. Para eso está el HAR File Analyzer de este sitio — suelta el .har en la página y se analiza localmente, en tu dispositivo, nunca subido, con los valores sensibles enmascarados por defecto: cabeceras Authorization, Cookie y Set-Cookie, cada valor de cookie, y cualquier cabecera, parámetro de consulta, campo de formulario o clave JSON cuyo nombre parezca un token, una clave, un secreto, una sesión o una contraseña. Revisa el resumen y las peticiones más lentas y grandes; comprueba qué hosts aparecen — una captura a veces contiene tráfico de sitios que ni estabas mirando — y usa el interruptor «mostrar valores», solo en tu pantalla, si necesitas confirmar qué hay realmente dentro.

Luego descarga el .har redactado y envía ese en su lugar. La redacción conserva la estructura que un ingeniero de soporte necesita — las mismas entradas, cabeceras, URL como formas, estados y tiempos — y sustituye los valores de credencial por el texto literal REDACTED, en cabeceras, cookies, cadenas de consulta, datos de formulario y cuerpos JSON por igual. Un límite está impreso en la herramienta y se repite aquí: un cuerpo POST que no sea JSON ni datos de formulario ordinarios no puede analizarse con seguridad, así que se conserva sin cambios — si tu captura contiene un cuerpo así, léelo tú mismo antes de que el archivo viaje. El resumen CSV enmascarado existe por la misma razón: es el archivo que adjuntas cuando el ingeniero pide «solo la lista de peticiones».

Lo que la redacción no puede hacer

La redacción quita las llaves; no quita el mapa. Un HAR redactado sigue mostrando tus hosts y endpoints, tus nombres de parámetros, la forma y el tamaño de las respuestas, la secuencia y los tiempos de las llamadas — un esbozo funcional de la API de tu aplicación, que en sí mismo puede ser información que no publicas. Tampoco puede retirar copias: una vez que un archivo en bruto ha entrado en un sistema de tickets o en una bandeja de entrada, redactar tu copia no cambia nada de la suya. Comparte el archivo redactado por el canal privado que te dio el proveedor — el propio ticket, no una publicación pública ni un enlace público — y pide, en el ticket, que el archivo se borre cuando se cierre el caso. Las organizaciones de soporte serias hacen esto de forma rutinaria; pedirlo no cuesta nada.

Y si un HAR sin redactar ya se ha escapado — enviado a la dirección equivocada, adjunto a un problema público, dejado en una carpeta compartida — trata la sesión como expuesta, porque lo está: cierra la sesión del servicio (lo que normalmente invalida la sesión en el servidor), vuelve a entrar y rota cualquier clave de API que apareciera en él. Es la misma regla que para cualquier credencial filtrada, y es la razón por la que la letra pequeña de las demás herramientas de archivos de este sitio es idéntica — el Binary File Inspector lee ejecutables localmente por la misma razón por la que esta página lee capturas localmente: los archivos que más necesitan inspección son exactamente los que no deberían subirse para inspeccionarlos.