Un portal necesita recibir facturas, fotos o documentos justificativos. La función visible parece sencilla: elegir archivo y pulsar un botón. Después, la aplicación asume recibir contenido no confiable, almacenarlo, decidir quién accede y quizá enviarlo a analizadores, parsers o servicios de IA.
Por eso debe diseñarse como un proceso documental con estados explícitos. «Recibido» no equivale necesariamente a «comprobado», y «almacenado» no significa disponible para quien conozca la dirección. Los límites claros protegen la aplicación y ayudan a entender cuándo están listas las pruebas para el siguiente paso.
Define la finalidad y el contenido permitido
Empieza por el uso de negocio. Una factura, una foto de campo y una hoja de importación tienen necesidades y riesgos distintos. Enumera formatos, tamaños y operaciones posteriores. Evita permitir muchos tipos solo porque el navegador pueda seleccionarlos.
En un portal hipotético de mantenimiento, los técnicos pueden enviar fotos y la oficina adjuntar PDF. Establece si son pruebas que conservar, contenido que mostrar o entradas para extraer datos. La finalidad influye en validación, transformación, retención y presentación del original al revisor.
Las guías de Microsoft y OWASP describen riesgos y precauciones. Úsalas para revisar toda la ruta, desde la solicitud hasta el acceso posterior, en lugar de reducir el diseño a validar extensiones. Carga de archivos en ASP.NET Core y riesgos de carga de archivos de OWASP.
Establece un límite de recepción
Autentica y autoriza cuando lo requiera el proceso. Verifica la relación del usuario con el registro de destino, como un trabajo o cuenta de proveedor. Conocer un identificador válido no debe bastar para adjuntar material al trabajo de otro cliente.
Utiliza identificadores de almacenamiento controlados por el servidor. Trata nombre y tipo declarado como metadatos no confiables y valida el contenido real con un enfoque adecuado a los formatos. Conserva el nombre original solo para una finalidad legítima de visualización o auditoría y trátalo de forma segura.
Limita los recursos consumibles. Considera tamaño individual, cuota total, duración y concurrencia, incluido procesamiento posterior. Un archivo técnicamente válido puede causar un problema si se admiten envíos ilimitados o análisis caros sin límites.
Mantén los archivos sin verificar fuera de la publicación normal
Introduce un estado de recepción en el que el archivo todavía no está disponible para uso general. Guárdalo con ubicación y acceso adecuados para contenido no confiable. Decide qué comprobaciones deben terminar antes de verlo, descargarlo o procesarlo después.
Si el análisis es asíncrono, muestra un estado pendiente significativo y registra el resultado. Que el analizador no esté disponible no debe convertirse silenciosamente en aprobación. Define la política de fallo, incluida sustitución por el usuario o investigación de soporte.
Conserva la relación entre contenido comprobado y servido. Si una transformación crea una vista previa o documento normalizado, sigue ese derivado por separado. Evita que un archivo cambie después de verificarse y conserve la aprobación anterior.
Diseña el acceso a través de los límites de la aplicación
Decide quién puede recuperar el archivo y durante cuánto tiempo. En documentos de clientes, el acceso normalmente debe reflejar el registro propietario y los permisos actuales. Una URL difícil de adivinar reduce descubrimientos accidentales, pero no debe ser la única decisión de acceso a material protegido.
Decide entre mostrar en línea o descargar y configura la entrega según tipo y finalidad. Incluye vistas previas y miniaturas en el mismo límite. Proteger el original no basta si su vista previa queda pública en otro lugar.
Prueba cambios de acceso posteriores. Un técnico puede salir del proyecto, suspenderse un cliente o retirarse un documento. Recuperación y compartición deben responder según la política, incluidos enlaces temporales ya emitidos.
Trata análisis y extracción como pasos separados
Una carga aceptada puede fallar al interpretar documentos, transformar imágenes o extraer datos. Da a esos pasos estados y límites propios. Mantén actualizadas las bibliotecas y no les concedas más acceso del necesario.
Si los datos extraídos provocan una acción, valídalos según las reglas pertinentes. Un lector puede producir una referencia de factura o cantidad plausible e incorrecta. Aceptar la carga no demuestra la corrección de todas las interpretaciones, incluidas las de IA.
En el portal de mantenimiento, conserva el informe para el revisor autorizado cuando un valor extraído sea incierto. Ofrece corrección que registre el valor revisado sin sobrescribir a la ligera las pruebas. Esto ayuda al soporte y a la conciliación posterior.
Asume la retención, los fallos y la comunicación al usuario
Indica la etapa alcanzada y qué hacer después. Distingue formato rechazado, tamaño excesivo, procesamiento fallido y problema temporal. Conserva una referencia útil para soporte sin exponer rutas internas o detalles sensibles.
Define limpieza de cargas abandonadas, rechazadas y derivados. Ajusta la retención a la finalidad y contempla procesamiento pendiente. Una eliminación programada no debe borrar material que se comunicó como aceptado y aún se necesita para una tarea activa.
Worktechlabs implementa documentos en portales empresariales y procesos de extracción con IA. Trata recepción, comprobación, procesamiento y compartición como responsabilidades distintas y verifica todo el recorrido con documentos válidos y fallos controlados para que la fiabilidad vaya más allá del botón de carga.
Fuentes oficiales y lecturas adicionales
- Microsoft: carga de archivos en ASP.NET Core — tratamiento y consideraciones de implementación.
- OWASP Foundation: carga irrestricta de archivos — riesgos y diseño defensivo.
