Recodificar imágenes en Express no basta: hay que auditar los bytes finales

Si publicas imágenes que suben tus usuarios desde Express, quitar el EXIF no es suficiente. Hay que decodificar los píxeles, recodificar una copia nueva y auditar esos bytes concretos antes de devolver la URL pública. El motivo es que el middleware puede limpiar un búfer mientras el generador de miniaturas, el corrector de orientación o una transformación en el CDN escriben otro distinto.

La invariante está en el output, no en la imagen en memoria

La representación publicada no puede contener GPS IFD, GPSLatitude, GPSLongitude, GPSPosition ni un equivalente en las notas del fabricante, y a la vez tiene que seguir cumpliendo el umbral de legibilidad del producto. El punto de fallo es el archivo codificado. Consultar original.getexif() demuestra lo que llegó, no lo que emitió el codificador de aguas abajo: ahí es donde se cuela el tag.

El camino crítico tiene cuatro etapas. Limitar la subida por tipo declarado y detectado, dimensiones y número de bytes. Decodificar píxeles y orientación en un objeto nuevo. Codificar una representación desde cero sin arrastrar metadatos de la aplicación. Y parsear exactamente ese resultado para rechazarlo si queda algún campo de localización. El autor lo ejemplifica con un script en Python sobre Pillow que puede correr en un worker, en un test de release o como fixture local aunque el handler sea Node y Express. La comprobación va después del guardado a propósito.

Tres fronteras que no son intercambiables

• Eliminar etiquetas concretas in situ: conserva los píxeles originales y suele ser el menor delta en bytes, pero la confianza depende de cubrir todos los contenedores de metadatos.
• Recodificar a las dimensiones originales: gasta CPU y altera el tamaño del JPEG o el detalle del texto fino, pero emite un contenedor nuevo a partir de los píxeles.
• Redimensionar y luego recodificar: el menor ancho de banda cuando se conoce el tamaño de visualización, siempre que se audite la salida redimensionada.

Ninguna vale cuando el archivo original es una prueba, un escáner médico o un diagrama sin pérdida cuyos píxeles importan tal cual. Eso se queda en un almacén restringido y se publica una copia derivada. Para texto diminuto, fijar solo un parámetro de calidad es una política floja: conviene medir OCR o legibilidad humana sobre imágenes representativas y fijar además una dimensión mínima.

Ojo con usar el peso como proxy de privacidad. Una foto de móvil de 12 MB puede rechazarse antes de decodificar, pero una miniatura de 300 KB revela las mismas coordenadas. La aserción útil es la de metadatos, no el tamaño del fichero.

En Express, el handler orquesta

El handler autentica, aplica límites de bytes y píxeles, manda el búfer al worker y publica solo el resultado verificado. La clave del objeto se queda privada hasta que pasa la comprobación. Una cola ayuda cuando el coste de decodificar es irregular; el procesado síncrono vale para avatares pequeños si el timeout de la petición está puesto. Merece la pena guardar un correlation ID y hashes de entrada y salida, dimensiones, ajustes del codificador y el veredicto de metadatos, pero nunca el búfer original ni un valor de GPS. Un 415 indica tipo fuera de política; un 422, que el archivo decodificó pero incumplió el contrato de publicación. Esa distinción hace que los reintentos del cliente y los paneles de rate limit tengan sentido.

Detecta el formato por bytes y no por extensión, y normaliza la orientación antes del chequeo: una imagen con orientación EXIF 6 se ve girada en un visor y correcta en otro. Al final lo que se prueba no es la limpieza, sino el byte exacto que va a servir el CDN.