Entrevista de backend: ¿Cómo diseñar una API segura de carga de archivos?

Prompt y escenarios aplicables

Un servicio de documentos B2B multiinquilino permite a los usuarios autenticados cargar archivos adjuntos PDF, JPEG y PNG, con un límite de 20 MiB por archivo. Tras el procesamiento, solo los miembros autorizados del mismo inquilino pueden descargar un archivo. El cliente controla los bytes, el nombre de archivo original, la extensión, Content-Type y el tamaño declarado, por lo que cada uno de esos valores se considera no confiable.

Diseñe APIs seguras de carga, escaneo, publicación y descarga. Explique cómo el diseño previene:

• web shells, tipos falseados (spoofed types), extensiones dobles, path traversal y sobrescritura de objetos;
• PDFs maliciosos, exploits en parsers de imágenes, malware y archivos políglotas;
• acceso entre inquilinos (cross-tenant), URLs de objetos públicos filtradas y renderizado en línea peligroso;
• solicitudes de tamaño excesivo, cuotas de almacenamiento agotadas, contención de escaneo y caídas del escáner;
• que un archivo sea reemplazado después de superar el escaneo, además de la corrupción de estado por llamadas de finalización duplicadas.

El límite de 20 MiB, los tres formatos permitidos y el modelo de inquilinos B2B son restricciones de la entrevista más que recomendaciones universales de seguridad. El candidato debe conectar la identidad, el protocolo de carga, el almacenamiento de objetos, el trabajo asíncrono y la autorización de descarga en un límite defendible. La competencia central es la seguridad de servicios y APIs de backend, por lo que la categoría es backend.

Qué evalúa el entrevistador

Primero, ¿puede el candidato establecer invariantes? Los bytes que no han superado una decisión de seguridad permanecen en cuarentena y los usuarios de negocio no pueden leerlos, la aplicación no puede analizarlos ni pueden servirse desde el origen primario de la aplicación. El nombre de archivo proporcionado por el cliente nunca se convierte en una ruta de almacenamiento. Cada lectura se autoriza nuevamente.

Segundo, ¿entiende la defensa en profundidad para la validación de tipos? Una extensión, el Content-Type de la solicitud, la firma del archivo y el resultado del parser proporcionan, cada uno, solo evidencia parcial. El servicio debe combinar una lista blanca de negocio, normalización, análisis estructural (structural parsing), escaneo de malware y, cuando sea apropiado, recodificación o desarmado y reconstrucción de contenido (content disarm and reconstruction).

Tercero, ¿puede diseñar una máquina de estados asíncrona explícita? Recibir bytes solo significa que un objeto llegó a la cuarentena. No significa que el archivo esté disponible. La API necesita estados de procesamiento, disponible, rechazado y falla técnica, con reglas precisas de reintento, tiempo de espera y limpieza.

Cuarto, ¿detecta la condición de carrera en el escaneo? Un escáner evalúa una secuencia específica de bytes. Si la misma clave de objeto se puede sobrescribir después, un registro AVAILABLE puede apuntar a contenido que nunca fue escaneado. El veredicto debe vincularse a una versión inmutable del objeto o a un hash del contenido, y la publicación debe ser condicional.

Quinto, ¿incluye la recuperación en el modelo de amenazas? Una clave aleatoria reduce la capacidad de adivinación pero no reemplaza la autorización del inquilino y del objeto. Las descargas necesitan un manejador controlado o una URL firmada de corta duración, encabezados de respuesta seguros, un origen aislado y una política de almacenamiento en caché intencional.

Preguntas aclaratorias antes de responder

• ¿Cómo se utilizará el archivo? Solo descarga, vista previa en el navegador, extracción de texto, generación de miniaturas y procesamiento por terceros tienen riesgos diferentes. Cada parser adicional amplía la superficie de ataque.
• ¿Son suficientes los tres formatos? Este escenario puede rechazar ZIP, Office y cualquier otro formato. Admitir archivos comprimidos requeriría límites de profundidad, cantidad de elementos, tamaño descomprimido y tasa de compresión.
• ¿Cómo se autentica el usuario? La autenticación basada en cookies introduce controles CSRF. Un token de portador (bearer token) todavía necesita controles correctos de CORS, alcance (scope) y prevención de fugas.
• ¿Se requiere carga directa al almacenamiento de objetos? Una API puede transmitir archivos pequeños en streaming. Con mayor concurrencia, puede emitir una credencial de corta duración limitada a un único objeto en cuarentena y verificar el objeto real después de la carga.
• ¿Quién puede cargar, inspeccionar el estado, descargar y eliminar? Defina los roles del inquilino, la propiedad del objeto y los requisitos de auditoría por separado; verificar únicamente que un usuario haya iniciado sesión es insuficiente.
• ¿Cuál es el SLA de escaneo? Defina el tiempo de espera, la cantidad de reintentos, el comportamiento de falla cerrada (fail-closed) y el estado que se muestra al usuario durante una interrupción del servicio.
• ¿Existen requisitos de cumplimiento o residencia de datos? Las claves de cifrado, la retención, los registros de auditoría, la eliminación y la limpieza de copias de seguridad pueden estar restringidos.
• ¿Qué constituye el éxito? Bytes almacenados, escaneo superado y descarga autorizada son tres hitos que merecen semánticas de API separadas.

Estructura de respuesta en 30 segundos

"Comenzaría con tres invariantes: un archivo no escaneado existe únicamente en cuarentena; el servidor genera la clave de almacenamiento mientras el nombre original del archivo permanece como metadato restringido; y cada descarga realiza autorización de inquilino y objeto. El ciclo de vida es PENDING_UPLOAD → QUARANTINED → SCANNING → AVAILABLE/REJECTED/FAILED.

Al crear una carga, el servicio verifica el rol del usuario, la cuota, el formato permitido y el límite de 20 MiB, luego genera una clave de objeto no adivinable y no sobrescribible. Los bytes se transmiten en streaming hacia un almacenamiento de cuarentena no ejecutable y no público. El servidor verifica el tamaño real, la extensión normalizada, la firma del archivo y la salida restringida del parser; luego, un worker aislado escanea en busca de malware. El veredicto se vincula a la versión del objeto o SHA-256, y la publicación solo tiene éxito mientras esos valores sigan coincidiendo.

Para la descarga, el servicio vuelve a verificar los permisos del inquilino y del objeto, luego devuelve una URL firmada de corta duración o transmite el objeto con Content-Disposition: attachment, un tipo seguro y preciso, y X-Content-Type-Options: nosniff. Una falla del escáner deja el objeto no disponible y activa reintentos acotados. Las cuotas, los límites de tasa (rate limits), la concurrencia, los tiempos de espera y la limpieza del ciclo de vida restringen los recursos. Validaría el diseño con falsificación de tipos, nombres de archivo hostiles, una muestra de prueba de malware, streams sobredimensionados, finalización duplicada, reemplazo de objetos y acceso entre inquilinos."

Análisis detallado paso a paso

Paso 1: Definir el límite de confianza y las invariantes de seguridad

El cliente controla cada byte de multipart, nombre de archivo, Content-Type, tamaño declarado y secuencia de solicitudes. Las puertas de enlace de API (API gateways), los servicios de aplicación, los eventos de almacenamiento de objetos y las colas de escaneo también pueden duplicar, retrasar o reordenar el trabajo. Construya el diseño en torno a estas invariantes:

1. Un objeto en cuarentena no tiene acceso de lectura pública y un servidor web no puede ejecutarlo.
2. Solo se puede descargar un objeto AVAILABLE autorizado.
3. El tenant_id del registro de negocio proviene del contexto autenticado, no de un campo de solicitud libremente proporcionado.
4. El nombre de archivo original nunca participa en la construcción de rutas ni en la búsqueda de objetos.
5. Una decisión de seguridad se vincula a bytes inmutables; la publicación no puede transferir ese veredicto a otra versión.
6. Una excepción, un tiempo de espera o un resultado indeterminado siempre aplica falla cerrada (fails closed).

Generar un nombre de archivo aleatorio y mantener un objeto privado resuelven problemas distintos. Una clave de objeto aleatoria previene la sobrescritura, la manipulación de rutas y la adivinación sencilla. La autorización y el almacenamiento privado proporcionan confidencialidad. El diseño necesita ambos.

Paso 2: Separar la recepción de la disponibilidad mediante una máquina de estados

Una máquina de estados mínima es:

PENDING_UPLOAD
  ├─ bytes verified ─> QUARANTINED ─> SCANNING
  │                                      ├─ safe ─> AVAILABLE
  │                                      ├─ malicious/invalid ─> REJECTED
  │                                      └─ scanner unavailable ─> FAILED
  └─ expired/abandoned ─> EXPIRED

POST /uploads crea una sesión y devuelve un upload_id. Para carga directa, también devuelve una credencial de corta duración que solo puede escribir en el objeto de cuarentena designado. POST /uploads/{id}/complete activa la verificación confiable y el escaneo, por lo que 202 Accepted es apropiado. GET /uploads/{id} informa el estado. Un punto de entrada de descarga aparece únicamente para AVAILABLE.

Cada transición utiliza una condición en la base de datos. Por ejemplo, solo un registro actualmente en QUARANTINED puede pasar a SCANNING. Una entrega duplicada en cola o una llamada repetida a complete aplica, por lo tanto, la misma transición a lo sumo una vez. FAILED significa una falla técnica de procesamiento; REJECTED significa que el archivo o la política eran inválidos. Combinarlos en un único error vago debilita la recuperación y la auditabilidad.

Paso 3: Recibir bytes de forma segura y acotar los recursos

Al crear la sesión, verifique el permiso de carga, la cuota restante del inquilino, la tasa del usuario y el formato de negocio solicitado. Genere un upload_id aleatorio y una clave de objeto como quarantine/{tenant-id}/{uuid}. Normalice el nombre de archivo original en cuanto a longitud, caracteres de control y Unicode; luego consérvelo solo como metadato de visualización.

Cuando la API actúa como proxy de las cargas, transmita los bytes en streaming hacia la cuarentena y cuéntelos mientras lee. Aborte inmediatamente después de los 20 MiB en lugar de almacenar en búfer todo el archivo en la memoria del proceso. Con la carga directa, restrinja la firma tanto como el sistema de almacenamiento lo permita por método, clave de objeto, expiración y tamaño. Posteriormente, un servicio confiable aún lee los metadatos del objeto y verifica la longitud real, la versión y la propiedad. Nunca confía en la solicitud de completado del cliente.

El bucket o directorio de cuarentena es privado por defecto, no ejecutable, está aislado del origen de la aplicación principal y se accede mediante credenciales de privilegios mínimos. Las sesiones expiradas, las cargas abandonadas y los estados terminales de escaneo necesitan una limpieza de ciclo de vida para que los objetos huérfanos no consuman cuota indefinidamente.

Paso 4: Combinar validación de tipo, análisis estructural y escaneo de contenido malicioso

Las verificaciones pueden ejecutarse de menor a mayor costo, pero ninguna capa individual puede producir AVAILABLE:

1. Aplique una lista blanca de PDF, JPEG y PNG a la extensión normalizada.
2. Trate el Content-Type del cliente como una sugerencia. Rechace discordancias evidentes, pero nunca lo use como prueba.
3. Inspeccione las firmas y la estructura completa de modo que un prefijo mágico válido no sea suficiente.
4. Utilice un parser actualizado y restringido para confirmar que todo el archivo se puede analizar sintácticamente.
5. Ejecute el escaneo de malware en un worker aislado y registre las versiones del motor y de las reglas.
6. Recodifique las imágenes decodificadas y considere el desarmado y reconstrucción de contenido para PDFs cuando el modelo de riesgo lo justifique.

Los escáneres y parsers procesan bytes controlados por el atacante. Ejecútelos en un sandbox con límites de CPU, memoria, disco temporal, tiempo y acceso a la red. Este escenario rechaza archivos comprimidos, lo que elimina las ramas de bombas de descompresión, anidamiento y path traversal en archivos comprimidos. El antivirus no demuestra una seguridad absoluta, por lo que el aislamiento del almacenamiento, la recuperación segura y el análisis sintáctico mínimo siguen siendo necesarios.

Paso 5: Vincular el veredicto a bytes inmutables antes de la publicación

El trabajo de escaneo lee un version_id de cuarentena inmutable y calcula SHA-256. Su resultado incluye al menos el upload_id, la versión del objeto, el hash, el tamaño real, el tipo detectado, la versión del motor de escaneo y el veredicto.

La publicación realiza una transición condicional en la base de datos. El registro aún debe estar en SCANNING, y la versión de su objeto y su hash aún deben coincidir con la entrada del escaneo antes de que pueda pasar a AVAILABLE. El almacenamiento de objetos también evita que esa versión se sobrescriba. Si el sistema copia un archivo a un área aprobada, el destino obtiene una nueva clave aleatoria y la operación de copia identifica la versión exacta de origen. Cualquier discrepancia provoca una nueva cuarentena o el rechazo en lugar de reutilizar un veredicto anterior.

Esta vinculación cierra la brecha entre el momento de verificación y el de uso (time-of-check-to-time-of-use). Un atacante no puede cargar bytes seguros, obtener un resultado aprobado y luego reemplazar la misma clave con bytes maliciosos. Sin versionado en el almacenamiento, utilice claves de objeto de escritura única o almacenamiento direccionable por contenido, y permita que el registro de negocio apunte únicamente al objeto inmutable final.

Paso 6: Autorizar descargas y controlar la interpretación del navegador

GET /files/{id}/download deriva el inquilino actual a partir de la autenticación, luego verifica la propiedad del objeto, el rol, el estado de eliminación y el estado AVAILABLE. Un UUID no elimina ninguna de esas verificaciones. Tras la autorización, la aplicación puede transmitir el objeto en streaming o emitir una URL firmada de corta duración vinculada a un objeto y operación específicos.

Para archivos adjuntos que no necesitan vista previa, devuelva Content-Disposition: attachment, un nombre de archivo para mostrar codificado de forma segura, el tipo de medio confirmado por el servidor y X-Content-Type-Options: nosniff. Aislar el origen del archivo respecto al dominio de cookies de la aplicación principal reduce la probabilidad de que el contenido activo afecte a la sesión primaria. Mantenga las URLs firmadas con una duración corta, ya que cambiar el permiso de un usuario generalmente no revoca de inmediato una URL ya emitida.

La ruta de recuperación también necesita controles de tasa y ancho de banda, eventos de auditoría de autorización y una decisión explícita sobre si los proxies o cachés pueden retener respuestas privadas. Los registros contienen el ID del objeto, el inquilino, el actor y el resultado, pero no el contenido del archivo ni URLs firmadas reutilizables.

Paso 7: Diseñar fallas, idempotencia, cuotas y observabilidad

Cuando el escaneo agota el tiempo de espera o no está disponible, el archivo permanece no disponible. Un worker puede reintentar un número acotado de veces con retroceso (backoff). Los reintentos agotados entran en FAILED para una recuperación controlada, ya sea manual o automatizada. Un resultado definitivamente malicioso o estructuralmente inválido entra en REJECTED, y los bytes en cuarentena se eliminan de acuerdo con la política de retención.

El endpoint de creación puede aceptar una clave de idempotencia para que un tiempo de espera en el cliente no genere múltiples sesiones. La finalización, el procesamiento del escaneo y la eliminación utilizan transiciones de estado condicionales para garantizar la idempotencia. Los límites de concurrencia cubren las cargas por usuario, el total de bytes por inquilino, el tamaño por archivo, la profundidad de la cola y las ranuras de escaneo por inquilino, evitando que un solo inquilino monopolice la capacidad global.

Las métricas útiles incluyen el tiempo transcurrido en cada estado, los bytes en cuarentena, las sesiones expiradas, las tasas de aprobación/rechazo/falla del escaneo, los reintentos, la antigüedad de la cola, los tiempos de espera del parser, las denegaciones entre inquilinos y las autorizaciones de descarga fallidas. Los eventos de auditoría registran las transiciones, las versiones de los objetos, los hashes, las políticas y las versiones del escáner, lo que permite a un operador responder qué bytes exactos se evaluaron bajo qué reglas.

Paso 8: Validar la ruta completa con una matriz adversaria

Como mínimo, pruebe:

1. .jpg.php, mayúsculas y minúsculas mixtas, bytes nulos y nombres de archivo Unicode de longitud excesiva;
2. Content-Type falseado, un prefijo válido con un final hostil, PDFs malformados y archivos políglotas;
3. el archivo de prueba EICAR en un entorno seguro, además de muestras que alcancen el tiempo de espera del parser o los límites de recursos;
4. exactamente 20 MiB, un byte por encima, longitud ausente, transmisiones lentas y múltiples cargas concurrentes;
5. la misma clave de idempotencia, llamadas concurrentes a complete, mensajes duplicados en la cola y resultados de escaneo obsoletos;
6. intento de reemplazo del objeto durante el escaneo, demostrando que una discrepancia de versión o hash no permite la publicación;
7. otro inquilino intentando leer el estado, descargar o eliminar el objeto, con cada solicitud denegada;
8. caída del escáner, tiempo de espera del trabajo, reinicio de la aplicación y limpieza de huérfanos;
9. comportamiento de descarga respecto a archivos adjuntos, tipo de medio, nosniff, almacenamiento en caché y expiración de URLs firmadas.

Aprobar requiere seguridad y corrección del negocio en conjunto: los archivos rechazados nunca reciben una ruta de descarga, los archivos seguros finalmente quedan disponibles, los reintentos no crean registros duplicados, las solicitudes no autorizadas no filtran datos, las fallas se mantienen cerradas (fail-closed), el uso de recursos se mantiene acotado y la pista de auditoría reconstruye toda la cadena de decisiones.

Ejemplo de respuesta sólida

"Dividiría la carga en etapas de cuarentena, decisión y publicación, con la invariante de que los usuarios de negocio nunca pueden leer bytes que no hayan superado la decisión. Al crear una sesión, derivo tenant_id a partir de la autenticación, verifico el rol, el límite de 20 MiB, la cuota del inquilino y la lista blanca de PDF/JPEG/PNG, y genero una clave de cuarentena aleatoria y no sobrescribible. El nombre de archivo original se conserva como metadato de visualización normalizado y de longitud limitada.

Los bytes se transmiten a través de la API o mediante una credencial de corta duración restringida a esa clave de cuarentena. Al completarse, el servidor verifica el tamaño real, la versión del objeto y la propiedad, transfiere condicionalmente el registro de PENDING_UPLOAD a QUARANTINED y escanea de forma asíncrona. La validación combina la extensión, el tipo detectado por el servidor, el análisis estructural completo, el escaneo de malware y la recodificación adecuada. El escáner se ejecuta con recursos y acceso a la red acotados.

El escáner lee una versión inmutable y calcula SHA-256. Un registro puede pasar a AVAILABLE solo si aún está en SCANNING y tanto la versión como el hash coinciden con la entrada del escaneo. Por lo tanto, reemplazar un archivo seguro después de su escaneo no puede reutilizar el veredicto anterior. Una caída del escáner falla de forma cerrada con reintentos acotados; el contenido definitivamente malicioso o no conforme pasa a REJECTED.

Cada descarga verifica el inquilino, los permisos del objeto y el estado AVAILABLE antes de transmitir el flujo o emitir una URL de corta duración. Los archivos adjuntos utilizan un origen aislado, Content-Disposition: attachment y X-Content-Type-Options: nosniff. Luego probaría la falsificación de tipos, EICAR, flujos sobredimensionados, finalización duplicada, carreras de reemplazo de objetos, lecturas entre inquilinos y caídas del escáner, monitoreando la duración en los estados, los bytes en cuarentena, la antigüedad de la cola y la versión del escáner."

Errores comunes

• Verificar únicamente la extensión → extensiones dobles, cambios de mayúsculas/minúsculas y contenido disfrazado la eluden → combine una lista blanca de negocio, normalización, firmas, análisis estructural y escaneo.
• Confiar en Content-Type → el cliente puede manipular el encabezado de la solicitud → úselo solo para un filtrado temprano y detecte el tipo final en el servidor.
• Usar el nombre de archivo original como ruta → se vuelven posibles bugs de path traversal, sobrescritura y normalización del sistema de archivos → genere una clave de objeto aleatoria y conserve el nombre únicamente como metadato restringido.
• Hacer que los bytes almacenados se puedan descargar de inmediato → los bytes maliciosos quedan expuestos antes de que finalice el escaneo → utilice cuarentena y establezca AVAILABLE como la única condición de publicación.
• Afirmar que superar el antivirus garantiza seguridad → nuevas muestras, bugs en parsers y contenido activo siguen siendo posibles → mantenga el aislamiento, análisis sintáctico mínimo, encabezados seguros y autorización.
• Escanear una clave sobrescribible → un resultado aprobado podría aplicarse a bytes de reemplazo posteriores → vincule una versión inmutable o hash de contenido y publique de forma condicional.
• Tratar un UUID como autorización → un ID de objeto filtrado podría permitir lecturas entre inquilinos → ejecute autorización de objetos para estado, descarga y eliminación.
• Confiar en la finalización del cliente tras una carga directa → el cliente puede mentir sobre el tamaño, tipo o propiedad → lea metadatos de objeto confiables y evidencia en bytes en el servidor.
• Fallar de forma abierta (fail open) durante una caída del escáner → una falla de infraestructura se convierte en una brecha de seguridad → aplique falla cerrada (fail closed), reintente dentro de límites y exponga un estado de procesamiento preciso.
• Limitar únicamente el tamaño por archivo → muchos archivos individualmente válidos pueden agotar el almacenamiento y el escaneo → aplique cuotas por inquilino, tasas, concurrencia y contrapresión (backpressure) en la cola.
• Renderizar archivos arbitrarios en línea en el origen principal → la interpretación del navegador y el contenido activo pueden afectar la sesión principal → utilice descarga como archivo adjunto por defecto y aísle el origen del archivo.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué analizar la estructura completa si ya se verifican los magic bytes?

Una firma usualmente cubre solo unos pocos bytes iniciales. Un atacante puede colocar otro formato después de un encabezado válido o construir un archivo que sea aceptado por múltiples parsers. El análisis estructural completo comprueba longitudes internas, relaciones y marcadores de fin de archivo. Dado que el parser sigue procesando datos no confiables, debe mantenerse actualizado, con recursos limitados y aislado.

Pregunta de seguimiento 2: ¿La carga directa al almacenamiento de objetos elude la seguridad del backend?

Solo cambia la ruta de transferencia de bytes. El backend aún crea una sesión de corta duración vinculada a un inquilino y a una clave de objeto, y la credencial solo permite escribir en la cuarentena. Luego, el backend verifica el objeto real, el tamaño, la versión y el hash antes de escanear. El objeto no tiene permisos de lectura antes de AVAILABLE, por lo que la carga directa no puede publicarlo directamente.

Pregunta de seguimiento 3: ¿Cuál debería ser la experiencia del usuario durante una caída del escáner?

La finalización devuelve un estado de procesamiento, mientras que la consulta de estado informa que las verificaciones de seguridad continúan o que el procesamiento falló y se puede reintentar. El sistema reintenta con retroceso acotado y monitorea la antigüedad de la cola. Al superar el umbral, el registro pasa a FAILED y permanece no disponible. La recuperación reintenta la misma versión inmutable mediante una ruta controlada; la disponibilidad nunca omite la decisión.

Pregunta de seguimiento 4: ¿Por qué las descargas todavía necesitan attachment y nosniff?

La autorización determina quién recibe los bytes. Los encabezados de respuesta influyen en cómo los interpreta el navegador. attachment prioriza la descarga directa, y nosniff impide que el navegador anule el tipo declarado por el servidor mediante content sniffing. Un origen de archivos aislado restringe aún más el acceso del contenido activo a las cookies y al contexto de scripts de la aplicación principal.

Pregunta de seguimiento 5: ¿Qué controles son necesarios si se permite ZIP?

Inspeccionar cada ruta interna en un sandbox aislado, rechazar rutas absolutas y .., y limitar la profundidad de anidamiento, la cantidad de elementos, el tamaño individual, el tamaño total descomprimido, la tasa de compresión, la CPU y el tiempo. Ejecutar verificaciones de tipo y de contenido malicioso nuevamente para cada elemento extraído. Este escenario no requiere ZIP, por lo que rechazarlo ofrece una superficie de ataque menor.

Pregunta de seguimiento 6: ¿Cómo demuestra que una condición de carrera no contaminó el veredicto?

Registre la versión inmutable de entrada y el SHA-256 en el trabajo de escaneo. La publicación utiliza una actualización condicional en la base de datos que exige que el registro actual permanezca en SCANNING exactamente con esa versión y hash. Una prueba sobrescribe el objeto lógico durante el escaneo y entrega un resultado obsoleto; la publicación debe fallar. Los eventos de auditoría conectan la versión de entrada, el veredicto y el objeto aprobado final.