Una captura de pantalla puede mostrar con gran claridad qué aparecía en un navegador. Puede incorporar la URL, la fecha y hasta un sello de tiempo. Sin embargo, por sí sola no responde a una pregunta decisiva: ¿esa publicación fue realmente servida por el sitio web declarado o pudo haberse construido en un entorno local antes de capturarla?
Esta diferencia importa cada vez más. Las publicaciones web son dinámicas, efímeras y personalizadas. Pueden depender de JavaScript, recursos distribuidos, geolocalización, sesión, credenciales o decisiones de un algoritmo. Una misma URL puede producir representaciones distintas para dos usuarios o cambiar mientras se tramita una diligencia. La adquisición probatoria ya no puede reducirse a fotografiar una pantalla.
La práctica técnica contemporánea tiende, por ello, a combinar métodos. La guía de SWGDE para la adquisición de contenido en línea distingue capturas visuales, herramientas del navegador, utilidades de adquisición y mecanismos nativos de la plataforma; recomienda preservar el contenido en su forma más próxima al original, aplicar hashes, registrar el proceso y emplear varias técnicas cuando sea necesario. Del mismo modo, ISO/IEC 27037 sitúa la identificación, recogida, adquisición y preservación dentro de un mismo proceso forense.
El objetivo no es acumular archivos. Es construir una explicación técnicamente contrastable que conecte lo visto con el origen remoto observado, conserve lo adquirido y declare con precisión sus límites.
Cuatro preguntas distintas que no deben confundirse
En el lenguaje cotidiano, «autenticidad» y «veracidad» se utilizan a veces como sinónimos. En prueba digital conviene separarlas:
| Pregunta | Proposición que se intenta acreditar | Evidencia necesaria |
|---|---|---|
| ¿Existió la publicación en ese origen? | En un momento y contexto de acceso declarados, el origen HTTPS lógico de la URL sirvió una representación concreta. | URL solicitada y efectiva, HTTP, DNS/IP, TLS, contenido recibido, renderizado, entorno y cronología. |
| ¿Se ha conservado íntegra? | Los artefactos no han sufrido alteraciones detectables desde su fijación. | Hashes, manifiesto, firma o sello, sellado temporal y cadena de custodia. |
| ¿Quién la publicó? | Una cuenta y, en un grado probatorio superior, una persona determinada crearon o controlaron la publicación. | Metadatos y registros del proveedor, accesos, dispositivos, contexto de la cuenta y corroboraciones externas. |
| ¿Es verdadero lo publicado? | El texto relata hechos ciertos o la imagen, audio o vídeo representa la realidad y no ha sido manipulado. | Investigación de los hechos y análisis forense específico del contenido multimedia. |
En este artículo, autenticidad de la publicación tiene un alcance deliberadamente acotado: evidencia de que una representación concreta existía y fue obtenida del origen web identificado en el contexto documentado. No significa que el mensaje sea cierto, que una fotografía no esté manipulada o que una persona concreta pulsara «publicar».
También debe matizarse la palabra origen. En HTTP es la combinación de esquema, host y puerto. Un CDN o un proxy inverso autorizado puede responder legítimamente en nombre de ese origen lógico. Cuando el cliente verifica correctamente la cadena y la identidad de servicio frente a un almacén de confianza adecuado, TLS aporta evidencia de que el endpoint controla una clave autorizada para ese dominio y protege el canal; aun así, no identifica al autor humano ni convierte el cuerpo HTTP en un documento firmado por este. Este alcance se desprende de RFC 9110, RFC 8446 y las reglas de identidad de servicio de RFC 9525.
El estado del arte: de los píxeles a la adquisición multicapa
No existe una técnica aislada que resuelva todas las preguntas probatorias. Cada método conserva una parte diferente del evento:
| Método | Qué aporta | Qué no acredita por sí solo |
|---|---|---|
| Captura de pantalla o vídeo | Apariencia visual y secuencia perceptible. | Respuesta HTTP, recursos, URL efectiva, servidor, elementos no mostrados u origen remoto. |
| Captura de página completa | Mayor cobertura visual del documento renderizado. | Contexto de red, estado interactivo, recursos omitidos o autoría. |
| Impresión PDF o archivo de página | Representación portable y, a veces, texto buscable. | Fidelidad completa al estado interactivo, cabeceras, sesión o identidad TLS. |
| Hash y sello de tiempo | Integridad posterior y prueba de existencia del hash antes de un instante. | Procedencia web, verdad del contenido o ausencia de fabricación anterior al hash. |
| Crawler o WARC | Respuestas, recursos y metadatos incluidos por el proceso. | Captura completa de sitios dinámicos, autenticados o personalizados; autenticidad automática de lo archivado. |
| API o exportación del proveedor | Metadatos nativos y estructura que pueden mejorar la atribución. | Lo que un usuario concreto vio en su navegador o la verdad material del mensaje. |
| Adquisición instrumentada multicapa | Correlación de origen técnico, transacción, render, contexto, cronología, integridad y custodia. | Autoría humana y veracidad intrínseca, que requieren pruebas adicionales. |
El formato WARC, normalizado como ISO 28500, puede almacenar recursos y metadatos de protocolos web. Es muy valioso, pero el contenedor no garantiza que la herramienta haya capturado todo. Los propios archivos web reconocen límites ante autenticación, JavaScript complejo, peticiones POST, streaming y contenido incrustado; véase la relación de limitaciones del UK Government Web Archive.
El punto ciego de una cadena de custodia que empieza demasiado tarde
La cadena de custodia es imprescindible, pero responde principalmente a lo ocurrido después de incorporar un objeto al proceso. Si el objeto ya era falso antes de calcular su hash, una custodia impecable conservará fielmente esa falsificación.
El ataque conceptual es sencillo:
- Se replica una página real en un servidor local o en un entorno controlado por quien fabrica la evidencia.
- Se modifica el contenido para simular una publicación legítima.
- Se presenta en un navegador con una apariencia, URL visible y fecha plausibles.
- Se toma una captura, se calcula su hash y se obtiene un sello de tiempo.
- A partir de ahí, la cadena de custodia puede ser formalmente perfecta.
El hash solo vincula una huella con unos bytes. La autoridad de sellado de tiempo recibe normalmente esa huella; no navega a la URL ni determina de dónde procedían los datos. RFC 3161 permite probar que un dato existía antes de un instante, pero no que fuese verdadero ni que hubiese sido obtenido de Internet. NIST formula el mismo problema para la preservación de evidencia digital: debe documentarse la fuente y el modo de creación o transferencia, porque un archivo puede modificarse antes de ser hasheado (NIST IR 8387).
Un hash o un sello sobre una captura fabricada solo preserva la fabricación.
Por eso la procedencia no debe añadirse como una etiqueta al final. Debe observarse y registrarse durante la adquisición.
Cómo se documenta el origen remoto
Una metodología robusta correlaciona observaciones diferentes que deberían contar la misma historia:
- La URL inicial, la URL efectiva y la cadena de redirecciones.
- La solicitud y la respuesta HTTP, con su estado, cabeceras, cuerpo y recursos.
- La resolución DNS, la dirección IP y el puerto remoto observados en tiempo UTC.
- La sesión TLS: nombre presentado, SAN, emisor, vigencia, cadena, protocolo, cifrado y huella del certificado.
- El peer observado por el navegador y, cuando procede, una comprobación de red complementaria.
- El HTML o DOM preservado, el texto visible, las capturas inicial y completa, y los demás artefactos derivados.
- Las versiones y la configuración del navegador, motor, sistema, zona horaria, locale, viewport, proxy y almacén de confianza.
- La secuencia de acciones, esperas, avisos, errores y elementos que no pudieron adquirirse.
Para vincular la representación con el origen lógico, la respuesta HTTP, el peer remoto y la sesión TLS deben proceder de la misma navegación o quedar asociados a ella de forma inequívoca. Una sonda paralela o posterior solo es corroborativa: no sustituye la telemetría de la transacción que entregó el contenido preservado.
La correlación reduce la plausibilidad de una simple página local: ya no basta con imitar sus píxeles; la simulación tendría que explicar de forma coherente la resolución, el endpoint, el certificado, la transacción, los recursos y la cronología.
Este último límite es importante. Una raíz privada instalada en el sistema puede hacer que un proxy de inspección genere certificados que el propio equipo considere válidos: el trust anchor es una entrada local del proceso de validación descrito en RFC 5280. Del mismo modo, un archivo hosts, un proxy transparente o una plataforma de adquisición comprometida podrían alterar varias capas a la vez.
Los controles deben ser proporcionales al riesgo: entorno limpio y versionado, inventario del almacén de confianza y de la configuración de red, anclaje externo temprano y, para asuntos críticos, repetición desde nodos, redes o resolutores realmente independientes. Ningún procedimiento elimina toda hipótesis lógica de fraude; sí puede hacerla mucho más exigente, visible y susceptible de contradicción pericial.
Qué hace diferente a Extracción Web de PROBATIA
Extracción Web está diseñada para que la adquisición no termine en una imagen. Su flujo organiza, documenta y preserva las capas necesarias para que otro profesional pueda inspeccionar qué se pidió, qué respondió el origen observado, qué se renderizó y cómo quedó protegido.
1. Define el objeto y el contexto jurídico
La captura parte de una o varias URL, una referencia de evidencia y un solicitante. Puede vincularse a un caso, incorporar la designación del perito y declarar la base de autorización cuando el acceso requiere autenticación. Esta información no adorna el informe: delimita el objeto de la diligencia, el contexto de acceso y la responsabilidad sobre la adquisición.
2. Diferencia acceso público y autenticado
Una publicación pública se observa sin una sesión reservada. En un área autenticada, la conclusión es más precisa: el origen sirvió esa representación a la sesión o perfil autorizado empleado. Eso no permite afirmar automáticamente que cualquier usuario pudiera verla.
Las credenciales no deben escribirse en el formulario de evidencia ni exponerse en los artefactos trasladables. El flujo utiliza perfiles de autenticación separados y registra una referencia al contexto autorizado. Cookies, tokens y materiales sensibles requieren custodia restringida y, si se genera un derivado para terceros, una redacción trazable mediante hashes.
3. Ejecuta una adquisición controlada
El motor visita la URL, registra el inicio y fin en UTC, conserva la URL efectiva, los estados y la secuencia de eventos. Para contenido efímero, la prioridad puede declararse expresamente. Los fallos no se borran ni se «corrigen» sobre el mismo registro: forman parte del historial, y una nueva tentativa produce una nueva adquisición.
4. Correlaciona publicación y origen técnico observado
La respuesta HTTP, el peer remoto y la sesión TLS observados durante la navegación quedan asociados a la representación adquirida. Una comprobación de red complementaria puede corroborar resolución, endpoint y certificado. La convergencia permite explicar por qué la representación se asocia al origen HTTPS lógico declarado, con los límites técnicos ya expuestos.
5. Conserva artefactos complementarios
La vista inicial y la página completa sirven para la lectura inmediata. El HTML renderizado, el texto visible, el archivo de red y otros derivados permiten analizar estructura, recursos y transacciones. Cada artefacto responde a una pregunta distinta; ninguno sustituye por completo a los demás.
6. Registra la adquisición, incluidos sus incidentes
La cronología deja constancia de la selección del motor, el contexto de autorización, la navegación, las esperas y los avisos. Una advertencia visible —por ejemplo, un selector que agotó su tiempo— es mejor evidencia que un proceso opaco que presenta únicamente un resultado «limpio».
7. Identifica y manifiesta cada objeto
Cada artefacto recibe una huella SHA-256 y se integra en un manifiesto con identificadores, tamaños, tiempos y relaciones. El paquete de exportación permite recalcular las huellas y comprobar si los objetos conservados corresponden al inventario.
8. Ancla, empaqueta e informa con estados verificables
La firma o el sello temporal protegen la integridad y la existencia del paquete a partir de su emisión. Si un anclaje se encuentra pendiente, diferido o no disponible, ese estado debe constar expresamente: no puede presentarse como una validación ya obtenida. El informe final separa resultado, incidencias, artefactos, origen técnico, integridad y custodia.
Sellado temporal: una capa importante, no una explicación del origen
En el marco europeo también hay que distinguir un sello RFC 3161 de un sello de tiempo electrónico cualificado. El artículo 41 del Reglamento eIDAS impide negar efectos jurídicos a un sello por su forma electrónica y atribuye al cualificado una presunción sobre la exactitud de la fecha y hora y la integridad de los datos vinculados. La condición de cualificado depende del prestador y del servicio inscrito con ese estado en una Trusted List de la Unión Europea; no nace solo por utilizar el protocolo RFC 3161.
Incluso un sello cualificado cubre la fecha, la hora y la integridad en el alcance legal correspondiente. No demuestra por sí mismo que el objeto procediera del sitio web declarado. Esa inferencia debe descansar en la adquisición documentada.
Repetibilidad y reproducibilidad sin promesas imposibles
Una web viva puede variar por sesión, tiempo, ubicación, idioma, publicidad, personalización o pruebas A/B. Por tanto, reproducibilidad no debe significar que una nueva visita devolverá necesariamente los mismos bytes.
Una formulación rigurosa es: procedimiento auditable, repetible y reproducible dentro de condiciones y límites declarados.
- Verificación reproducible: otro perito puede recalcular hashes, revisar el manifiesto, validar firmas o sellos y examinar los recursos preservados.
- Repetición metodológica: otro perito puede ejecutar de nuevo el procedimiento descrito con condiciones conocidas.
- Identidad del resultado: no se garantiza frente a una fuente dinámica que puede haber cambiado.
Este enfoque es coherente con ISO/IEC 27041, sobre idoneidad y validación del método, y ISO/IEC 27042, que trata continuidad, validez, reproducibilidad, repetibilidad y escrutinio independiente.
Qué puede sostener el perito y qué requiere otra investigación
Una conclusión bien calibrada podría expresar que, en las condiciones documentadas:
- una representación determinada fue obtenida al solicitar una URL concreta;
- el origen HTTPS lógico observado respondió con los datos preservados;
- el contenido visual, estructural y de red se corresponde dentro de las comprobaciones realizadas;
- los artefactos no presentan alteraciones respecto de sus huellas y manifiesto;
- la cronología, los incidentes y el estado de los anclajes están documentados.
No debería convertir esas observaciones en afirmaciones distintas:
- que una persona concreta creó o controlaba la cuenta;
- que la publicación era visible para todos si se accedió mediante credenciales;
- que el texto publicado es verdadero;
- que una imagen, audio o vídeo son originales o no han sido manipulados;
- que una página dinámica se capturó en toda su extensión histórica;
- que el resultado tendrá un valor probatorio predeterminado en cualquier procedimiento.
La atribución puede requerir datos nativos del proveedor, registros de acceso, dispositivos y otras corroboraciones. La veracidad o autenticidad intrínseca de una imagen, un audio, un vídeo o un texto exige una pericial diferente. PROBATIA dispone de flujos de investigación y análisis para esas cuestiones, pero no deben confundirse con el objeto específico de la extracción web.
Lectura procesal: hacer posible la contradicción
Los artículos 382 y 384 de la Ley de Enjuiciamiento Civil contemplan reproducciones e instrumentos que archivan o reproducen datos, permiten aportar medios instrumentales y dictámenes para sostener o contradecir su autenticidad y exactitud, y remiten su valoración a las reglas de la sana crítica. La calidad del paquete no sustituye la valoración judicial, pero puede hacer la prueba más examinable.
La STS 300/2015 advirtió, en un caso relativo a conversaciones de una red social, de la posibilidad de manipulación y falsa identidad en meras impresiones. Conviene citarla con prudencia —no establece una regla automática para toda página web—, pero ilustra por qué la apariencia visual y la atribución de una cuenta no deben darse por supuestas. La síntesis oficial se encuentra en la doctrina jurisprudencial de la Sala de lo Penal correspondiente a 2015.
Para el abogado, la ventaja de una adquisición multicapa no es una etiqueta de «prueba irrefutable». Es la posibilidad de preguntar, comprobar y contradecir:
- qué URL se solicitó y cuál respondió;
- qué identidad técnica presentó el endpoint;
- qué datos viajaron por la red y qué se renderizó;
- qué entorno y qué autorización se utilizaron;
- qué se conservó, con qué hash y desde cuándo;
- qué falló o quedó fuera;
- y qué hipótesis alternativas siguen abiertas.
Lista de comprobación antes de aportar una publicación web
- ¿Está definida la proposición probatoria: existencia, integridad, atribución o veracidad?
- ¿Constan URL inicial, URL efectiva, redirecciones y hora UTC?
- ¿Se ha registrado la transacción HTTP y el contenido recibido, además de la vista visual?
- ¿Se documentan DNS, IP, puerto, TLS y certificado del origen observado?
- ¿Se conoce la configuración relevante del entorno, incluidos proxy y almacén de confianza?
- ¿El acceso era público o autenticado y existe base de autorización?
- ¿Se conservan artefactos complementarios y los errores de adquisición?
- ¿Cada objeto tiene hash y figura en un manifiesto verificable?
- ¿El estado de la firma o del sello temporal está comprobado y descrito sin ambigüedad?
- ¿Puede un tercero verificar el paquete sin depender de la plataforma que lo generó?
- ¿Se han separado los materiales sensibles y documentado cualquier redacción?
- ¿El informe declara con claridad qué demuestra y qué no demuestra la extracción?
Más que una fotografía: una hipótesis comprobable
La fortaleza de una evidencia web no está en una señal aislada. Está en que observaciones distintas —la transacción, el endpoint, el certificado, los artefactos, la cronología y los anclajes— converjan y puedan ser revisadas por un tercero.
Extracción Web de PROBATIA convierte una visita fugaz en un expediente técnico estructurado: documenta la existencia y el origen remoto de la representación obtenida, preserva su integridad y conserva las condiciones necesarias para la revisión pericial. No certifica que el mensaje sea verdadero ni atribuye automáticamente su autoría. Hace algo previo y esencial: permite sostener, dentro de las condiciones documentadas, qué representación se recibió desde un origen HTTPS lógico concreto, cuándo, en qué contexto de acceso y cómo se preservó.
¿Necesitas preservar una publicación antes de que cambie o desaparezca?
Crea una cuenta en PROBATIA para iniciar una extracción web o suscríbete al boletín para recibir guías técnicas sobre prueba digital.
Este artículo ofrece información técnica general y no sustituye el análisis jurídico o pericial del caso concreto.
Referencias técnicas y jurídicas
- SWGDE, Best Practices for Acquiring Online Content, 21-F-001-1.1, 2024: https://www.swgde.org/documents/published-complete-listing/21-f-001-best-practices-for-acquiring-online-content/
- ISO/IEC 27037:2012: https://www.iso.org/standard/44381.html
- ISO/IEC 27041:2015: https://www.iso.org/standard/44405.html
- ISO/IEC 27042:2015: https://www.iso.org/standard/44406.html
- ISO 28500:2017, WARC: https://www.iso.org/standard/68004.html
- RFC 9110, HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110.html
- RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: https://www.rfc-editor.org/info/rfc8446/
- RFC 9525, Service Identity in TLS: https://www.rfc-editor.org/rfc/rfc9525.html
- RFC 5280, PKIX: https://www.rfc-editor.org/rfc/rfc5280.html
- RFC 3161, Time-Stamp Protocol: https://www.rfc-editor.org/info/rfc3161/
- NIST IR 8387, Digital Evidence Preservation: https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8387.pdf
- Reglamento (UE) 910/2014 (eIDAS), texto consolidado: https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:02014R0910-20241018
- Comisión Europea, EU Trusted Lists: https://digital-strategy.ec.europa.eu/en/policies/eu-trusted-lists
- Ley 1/2000, de Enjuiciamiento Civil: https://www.boe.es/buscar/act.php?id=BOE-A-2000-323
Fuentes consultadas y vigencia comprobada el 28 de agosto de 2026.
