[Eslopes]

WASM-013 — Arquitectura de seguridad y modelo de amenazas de la línea WebAssembly
Estado: borrador. Depende de WASM-002, 003, 005, 009, 010 y 012. Es responsable de las reglas que estos citan (WASM-002 R7, R14; WASM-003 R14–R17; WASM-005 R14, R17; WASM-006 R7–R8; WASM-007 R13; WASM-008 R8).

Requisitos

El modelo

R1 — Modelo de amenazas de la serie: activos (cuentas, tokens, datos, secretos, código fuente del desarrollador); actores (anónimo, autenticado, página maliciosa que integra o abre la aplicación, cliente de backend malicioso, dependencia maliciosa, archivo de proyecto malicioso abierto en el IDE); fronteras de confianza (navegador ⇄ backend, página anfitriona ⇄ módulo, módulo ⇄ player, IDE ⇄ vista web de Preview, shell móvil ⇄ frontend, backend ⇄ proveedor y datos). Para cada amenaza: control y prueba que lo demuestra. Se revisa en /analyze de cada fase.
Políticas que genera la compilación

R2 — Página anfitriona con CSP de denegación predeterminada: scripts del origen y 'wasm-unsafe-eval', sin 'unsafe-eval' ni 'unsafe-inline' (nonce o hash donde sea inevitable); estilos del origen y hashes; imágenes y fuentes del origen; connect-src limitado a las direcciones del backend; base-uri y form-action restringidos; frame-ancestors según el modo de integración. Se exige Trusted Types donde se admita.
R3 — Los hosts estáticos pueden no permitir definir cabeceras. Build entrega la política como <meta> (lo que meta puede expresar) y como conjunto de cabeceras listo para hosts comunes (lo que meta no puede expresar: frame-ancestors, report-only, HSTS), e imprime cuál es cuál.
R4 — El backend envía Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy restrictiva y Permissions-Policy; la configuración TLS rechaza versiones y cifrados por debajo de un mínimo declarado.
XSS

R5 — Todo valor que llega a la página (caption, elemento, celda, tooltip, mensaje) se inserta como texto, nunca se analiza como markup. El player no tiene ninguna API que inserte cadenas HTML (innerHTML, outerHTML, insertAdjacentHTML, document.write), y una prueba busca esos puntos de inserción en el código. El único control que renderiza markup, el subconjunto HTML de Viewer, construye nodos DOM (createElement, setAttribute, textContent) a partir de un árbol analizado y filtrado mediante una lista de elementos, atributos y esquemas de URL permitidos.
CSRF, CORS y origen

R6 — Las llamadas que modifican el estado se autorizan mediante un bearer token añadido por la página, nunca solo mediante una cookie. Una solicitud que depende de cookies (renovación de WASM-009 R5) utiliza SameSite, un token CSRF o una cabecera que el navegador no añade entre sitios. Se verifica Origin del WebSocket (WASM-003 R14). Superficie HTTPS con lista explícita de orígenes permitidos, nunca un comodín con credenciales.
Secretos

R7 — Análisis de secretos que bloquea Build web o móvil (WASM-002 R7), con los patrones de esta especificación: claves y tokens de nube, bloques de claves privadas, JSON Web Tokens, cadenas de conexión, formatos de claves API, cadenas de alta entropía por encima de una longitud configurable. Se ejecuta sobre el paquete, formularios, copybooks y hojas de estilos. Falla indicando el archivo y el patrón, nunca el valor.
R8 — Una clave de backend o de firma nunca recurre al texto sin cifrar: sin el almacén del SO, el producto se detiene y lo comunica (WASM-012 R4).
Cadena de suministro

R9 — Todo crate de frontend, player, backend y shell pasa por una lista de permitidos protegida por dependency-guard (ampliado de la especificación 063 AC8 / 103), con archivo de bloqueo, auditoría de vulnerabilidades, comprobación de licencias y ningún script de compilación que descargue de la red, salvo los declarados. El JavaScript de la página anfitriona se escribe a mano y es pequeño (WASM-002 Q6), sin árbol de gestor de paquetes.
R10 — Cada Build escribe un SBOM en un formato estándar, y los recursos de la página anfitriona incluyen hashes de integridad.
Seguro de forma predeterminada

R11 — Toda relajación (token de desarrollo, ws:// para una dirección que no sea loopback, origen comodín, CSP debilitada, omitir el análisis de secretos) es una configuración explícita cuyo nombre incluye unsafe, muestra una advertencia en el IDE y hace fallar Build de release.
R12 — El backend de desarrollo se vincula a loopback salvo instrucción en contrario, y la vista web de Preview carga solo su origen (WASM-008 R8).
Logs y privacidad

R13 — Los logs, informes de fallos y telemetría del backend, del frontend y del IDE nunca contienen tokens, contraseñas, secretos o campos marcados como sensibles. El plan enumera los datos personales tratados y adónde se envían.
Móvil

R14 — La lista de capacidades del shell da a cada ventana el acceso nativo mínimo, ninguno al origen remoto, y se genera a partir de las funcionalidades declaradas (WASM-012 R7, R12).
Garantía

R15 — La suite incluye: auditoría de dependencias y licencias; análisis de secretos frente a secretos introducidos deliberadamente; prueba de que la CSP y las cabeceras generadas coinciden con el texto esperado y de que una página bajo ellas no ejecuta scripts inline ni eval; búsqueda de puntos de inserción XSS; fuzzing del tratamiento de frames WebSocket, del mapeo JSON (WASM-005) y de la validación de tokens (WASM-003 R10), con un presupuesto de ejecución declarado.
R15b — (restricción) La aplicación utiliza aislamiento entre orígenes e hilos cuando la página los ofrece, y funciona sin ellos (operador, 2026-10-20; WASM-017 R19). Con aislamiento (COOP: same-origin, COEP: require-corp o credentialless), la página dispone de SharedArrayBuffer. Coste: todo recurso entre orígenes debe enviar CORS o CORP, o cargarse bajo credentialless. La vía plain es una alternativa probada como vía completa. La memoria del módulo nunca crece, la arena es fija, la memoria compartida tiene un máximo declarado y el cargador libera por completo las regiones, el módulo y los Workers de los formularios y aplicaciones destruidos (WASM-017 R2, R5, R7, R8).
R16 — Cuando la serie llega a release candidate, se registra antes del lanzamiento una revisión por alguien distinto del autor y, si el operador lo decide (Q1), una prueba de penetración externa.
Objetivos: modelo de amenazas con fronteras de confianza identificadas y un control por amenaza; CSP estricta y conjunto de cabeceras generado y probado; reglas de XSS, CSRF, CORS, tokens, secretos, cadena de suministro y logs, cada una verificable; valores predeterminados seguros con relajación explícita y rechazada en release; comprobaciones automatizadas (dependencias, análisis de secretos, política, puntos de inserción, fuzzing).
Fuera del alcance: refuerzo de seguridad del SO, protección contra manipulación, detección de root o jailbreak; WAF; detalles internos de proveedores de identidad; certificación de cumplimiento (propuesta en WASM-030).

Cuestiones:

Q1 — Prueba de penetración externa — abierto: obligatoria antes de la versión 2.0 o revisión por un segundo lector; el presupuesto y el proveedor corresponden al operador.
Q2 — Trusted Types — abierto: se exigen solo donde se admiten y requieren que el código del player los cumpla.
Q3 — Rigor del análisis de secretos — recomendado: alta entropía como advertencia; formatos conocidos como error.
Q4 — Contacto de seguridad y política de divulgación (archivo SECURITY) — abierto; necesario antes de la versión 2.0.
Q5 — Fijación de certificados para el backend del shell móvil — abierto: opción, exigencia o elección del desarrollador.
Estado: borrador. No iniciado según PROGRESS (PROG-83).

WASM-014 — Contrato del backend y su evolución
Estado: borrador. Depende de WASM-003 y WASM-005. Relacionado con WASM-009, 012 y 013.

Requisitos

Versiones y handshake

R1 — Toda compilación del backend tiene una versión de contrato y una versión de protocolo de transmisión. Toda compilación del frontend lleva la versión de contrato contra la que se compiló. Ambas se incluyen en la descripción de interfaz (WASM-003 R4).
R2 — Al abrir la conexión, ambos lados intercambian versiones y el backend responde accepted, accepted with a warning (cliente más antiguo, compatible) o refused, con el motivo y, cuando sea posible, la versión a la que debe actualizarse. El frontend dispara un evento definido; en caso de rechazo, la aplicación puede solicitar una actualización (enlace de la tienda en móvil).
R3 — La versión del protocolo permite servir más de una versión a la vez, dentro de una ventana declarada. Un cliente fuera de la ventana se rechaza con un mensaje de actualización, nunca con un error de protocolo.
Compatibilidad

R4 — Reglas de cambios compatibles e incompatibles en un programa exportado, escritas y comprobadas durante la compilación. Compatible: campo final opcional, nuevo programa exportado, ampliación de OCCURS, nueva clase de error. Incompatible: eliminar o renombrar un campo, cambiar PICTURE o USAGE de forma incompatible, reducir OCCURS, cambiar los roles requeridos, eliminar un programa.
R5 — Durante la compilación del backend, la nueva descripción de interfaz se compara con la última publicada (guardada en el proyecto). Cada cambio incompatible se notifica con el programa, el elemento y la regla. Release Build falla, salvo que el desarrollador incremente deliberadamente la versión mayor del contrato.
R6 — Un programa puede marcarse como deprecated, con un mensaje y una versión de eliminación. Llamarlo tiene éxito y dispara un evento de advertencia en el frontend.
Errores

R7 — Todo fallo tiene una clase de una lista cerrada: transport (sin conexión, cerrada, tiempo de espera agotado), authentication (ausente, inválida, caducada), authorisation (rol rechazado), validation (el payload no cabe en la disposición de datos), not found, version (R2), rate or size limit, application (el programa notificó un fallo), server. Tiene un código numérico estable, un mensaje en inglés para los logs y un campo para detalles del programa. Una clase desconocida se interpreta como server.
R8 — Clase application: un programa de backend notifica un fallo de negocio (pedido rechazado, clave duplicada) con un código y datos que el frontend lee en ON EXCEPTION, distinto de las clases de la plataforma. El mecanismo se decide en /plan (Q1).
Repetición y orden

R9 — El programa declara si es seguro repetirlo (idempotente). Tras una pérdida de conexión, el runtime solo repite si el programa se ha declarado seguro. En caso contrario, notifica transport e indica si la llamada puede haberse recibido (Q2).
R10 — Una llamada no idempotente puede llevar una idempotency key generada por el runtime; una repetición elegida por el desarrollador se responde con el resultado almacenado, durante un plazo declarado, sin ejecutar dos veces.
R11 — Las llamadas de una conexión se ejecutan en el orden en que se hicieron, salvo que el programa se declare independiente. Varias llamadas en curso (WASM-003 R6) no modifican el orden.
Tamaño, duración y streams

R12 — Un payload por encima del tamaño configurado se rechaza con size limit. Un resultado legítimamente grande utiliza fragmentación (reensamblada por el runtime, R13) o transferencia de archivos (R15).
R13 — (Opcional) Llamada de larga duración: el backend envía mensajes de progreso y una respuesta final. El frontend dispara un evento de progreso; el usuario o el programa puede cancelar, y el backend respeta la cancelación en el siguiente punto seguro.
R14 — (Opcional) Programa stream (feed, contador, log): el frontend recibe eventos, realiza subscribe y unsubscribe explícitos y se vuelve a suscribir tras una reconexión. Un cliente sin suscripción no supone ningún coste para el servidor (Q3).
Archivos

R15 — La carga y descarga forman parte del contrato: transferencia por fragmentos con tamaño declarado, lista de tipos permitidos y checksum, reanudable tras una caída, sujeta a límites de tamaño y tasa, con evento de progreso. El backend rechaza las rutas o nombres elegidos por el navegador (WASM-005 R15) y asigna los nombres a los archivos. La dirección de descarga se emite por solicitud, es de corta duración y está vinculada al llamador (Q4).
Evolución del contrato

R16 — Las reglas del propio contrato tienen una versión: cambiar el handshake, la lista de errores o el protocolo de archivos implica un cambio de versión del protocolo, con la ventana de R3.
R17 — El proyecto Desktop no se ve afectado.
Objetivos: versión de contrato en cada compilación y handshake en la conexión; regla de compatibilidad impuesta por una herramienta; modelo de errores con clases; comportamiento definido para reintentos, llamadas grandes y largas, streams y archivos.
Fuera del alcance: segundo protocolo (REST, GraphQL, gRPC); refuerzo de seguridad del transporte (WASM-003, WASM-013); el mapeo JSON en sí (WASM-005); servidores multiversión más allá de lo permitido por la compatibilidad.
Base existente: dos precedentes de formato de transmisión versionado (bincode FormIpcMessage, JSON lines RemoteDebugCmd) y la versión de manifiesto CURRENT_STRUCTURE.

Cuestiones:

Q1 — Cómo notifica un programa un fallo application — recomendado: built-in COBOL::"…" que el programa llama para que la plataforma distinga un fallo deliberado de un fallo real.
Q2 — “Puede haberse recibido” — abierto: declarar la garantía (at-most-once de forma predeterminada, at-least-once para programas seguros) y decidir si la clase application puede consultar el backend después.
Q3 — Streams — abierto: exigen estado de servidor por suscriptor, en tensión con WASM-003 Q2. Entran en la versión 2.0 o quedan para una especificación posterior.
Q4 — Desde dónde descargar un archivo — recomendado: dirección HTTPS de corta duración para la descarga; fragmentos por WebSocket para la carga.
Q5 — Retención de resultados de idempotencia y de descripciones de interfaz anteriores — abierto, junto con la especificación de operaciones.
Estado: borrador. No iniciado según PROGRESS (el contrato de WebSocket depende del backend, PROG-79).