Entrada y privacidad de una PWA Web Share Target

Una PWA Web Share Target puede recibir una solicitud de compartir mediada por el navegador, pero no sabe por qué una persona eligió el origen ni si cada campo debía salir de él. BotBrowser puede repetir un fixture propio e inspeccionar la ruta receptora, el estado de validación y la alternativa; no puede elegir el origen del sistema operativo ni certificar la decisión de divulgación de una persona.

TL;DR

• Trata share_target como un contrato de entrada no confiable, no como una señal de identidad.
• Valida los valores de consulta GET y los datos de formulario POST antes de mostrarlos o guardarlos.
• Mantén estrechos el scope, la ruta y los campos aceptados del manifiesto.
• Haz idempotentes las entregas duplicadas y conserva solo los datos necesarios.
• Conserva una navegación normal o una alternativa de copiar cuando el navegador no pueda instalar o invocar la PWA.

Contenido

• Manifiesto y análisis de la solicitud
• Validación, privacidad y alternativa
• Implementación y aceptación
• Conclusión práctica

Manifiesto y análisis de la solicitud

La propuesta Web Share Target de WICG define el miembro share_target del manifiesto para asignar un compartir entrante a una URL, un método y nombres de parámetros. La referencia de MDN sobre Web Share Target API describe la función como una entrega a una PWA instalada. La declaración no es un token de autenticación, una identidad del emisor ni una promesa de que los datos compartidos sean seguros de conservar. Para el estado local separado de esta entrada, consulta límites de Badging API para notificaciones PWA.

BotBrowser puede repetir un fixture autorizado del mismo origen y comprobar la ruta visible, la validación y la alternativa. No puede elegir el origen del sistema operativo ni certificar lo que una persona decidió divulgar; esos límites deben quedar en el contrato del producto.

Mantén la declaración explícita y pequeña. Un destino público de solo URL puede ser:

{
  "share_target": {
    "action": "/inbox/share",
    "method": "GET",
    "params": { "title": "title", "text": "text", "url": "url" }
  },
  "acceptanceMetadata": { "fixtureRevision": 3 }
}

action debe permanecer dentro del ámbito de la aplicación. No uses una ruta comodín cuando basta una ruta de bandeja. Para un límite de almacenamiento más amplio, consulta el modelo de almacenamiento del navegador, que separa el estado del origen en vez de tratar el perfil PWA como un bloque opaco.

GET coloca los valores asignados en la URL de acción. Una URL puede acabar en historial, registros, referrers, capturas o analítica; nunca pongas tokens portadores, texto privado o identificadores de cuenta en parámetros de consulta. Normaliza longitud y codificación antes del primer renderizado.

POST mantiene el cuerpo fuera de la URL, pero cruza el límite entre navegador y aplicación. El manifiesto puede declarar application/x-www-form-urlencoded o multipart/form-data; el receptor debe rechazar un tipo inesperado y limitar el cuerpo antes de analizarlo. Los archivos requieren límites separados de tamaño, tipo y malware. Analizar correctamente no autoriza a persistir el cuerpo original.

Usa un registro acotado para comparar resultados sin conservar contenido:

{
  "method": "POST",
  "route": "/inbox/share",
  "fields": ["title", "text", "url"],
  "bodyBytes": 4096,
  "outcome": "validated-local-draft",
  "fixtureRevision": 3
}

El miembro share_target del manifiesto en MDN enumera la forma y el mapeo. Conserva el mismo mapeo en manifiesto, parser y pruebas; que url quede vacío por un renombrado silencioso es pérdida de datos, no privacidad.

Validación, privacidad y alternativa

El service worker puede recibir la navegación y dirigirla a un cliente controlado, o la página puede procesarla después de navegar. En ambos casos valida origen, método, tipo de contenido, longitud de campo y esquema de URL antes de mostrar datos. Rechaza javascript: y credenciales incrustadas inesperadas aunque parezcan enlaces.

No deduzcas el emisor por Referer, user-agent o tiempo. Pueden faltar o estar incompletos. Un registro de service worker tampoco prueba que la página actual esté controlada: comprueba la ruta visible y el marcador de versión de la aplicación. Para carreras de actualización y propiedad de caché, consulta ciclo de caché de service worker y privacidad, que explica por qué un worker antiguo puede servir una respuesta anterior.

Trata un worker obsoleto como un fallo acotado. Muestra los valores solo después de validar, conserva la ruta original si falla el análisis y ofrece reintentar o copiar. No devuelvas un POST fallido al destino sin una clave de idempotencia.

El origen puede reintentar tras un tiempo de espera y una persona puede invocar dos veces el mismo destino. Crea un identificador de solicitud propio, deduplica durante una ventana breve y registra solo un estado como accepted, rejected o expired. No registres texto, bytes de archivo ni la URL completa si basta un identificador opaco de fixture.

Conserva el contenido privado local hasta que la persona confirme la siguiente acción. Un botón de guardar puede crear un registro de servidor con autorización y retención propias; abrir el destino no debe hacerlo. Borra datos temporales después de aceptar o cancelar el borrador visible. La caché del service worker no debe convertirse en un archivo accidental.

La entrega del navegador no crea una relación de cuenta. Si el producto invita a un colaborador, ejecuta una operación confirmada aparte y audítala por separado. Un destino de compartir es una entrada conveniente, no una decisión de control de acceso. Consulta límites de permisos de Web Share y alternativas seguras, que separa una solicitud de la confirmación de entrega. La guía sobre Web Share API y uso compartido iniciado por la persona añade las restricciones de activación y cancelación que deben cumplirse antes de recibir datos.

Prueba con solicitudes sintéticas GET y POST, cuerpo demasiado grande, campo desconocido, URL inválida, identificador duplicado y service worker ausente. Comprueba estados visibles y el registro acotado, no un selector del sistema operativo. Un fixture controlado puede verificar el límite de 4096 bytes; no demuestra qué enviará una aplicación real.

Conserva una navegación /inbox/share, una acción de copiar o un campo de pegado cuando falte instalación, manifiesto o soporte. La alternativa debe conservar la tarea sin importar los mismos datos por una ruta más amplia. La guía de MDN para compartir datos entre aplicaciones describe la relación visible; no sustituye la revisión de retención.

Implementación y aceptación

El manifiesto es configuración, no un parser. Lee su miembro share_target durante la compilación, rechaza un action fuera del scope de la aplicación y genera una lista permitida que el runtime pueda comparar con la solicitud entrante. Un artefacto útil de revisión registra action, method, enctype y cada nombre de parámetro. También debe registrar la revisión del manifiesto, porque un worker y una página pueden actualizarse en momentos distintos. Una solicitud atendida por la revisión 2 no debe compararse silenciosamente con una expectativa escrita para la revisión 3.

Para un destino GET, construye una URL a partir de la URL de la solicitud y lee solo las claves declaradas. URLSearchParams.get() devuelve el primer valor, mientras getAll() permite inspeccionar claves repetidas. Decide si las repeticiones se rechazan o se reducen a un valor; no dejes que lo decidan los valores predeterminados del framework. Decodifica los escapes porcentuales una sola vez, convierte el UTF-8 inválido en rechazo, recorta solo cuando lo permita el contrato del campo y aplica los límites después de decodificar. Por ejemplo, comprueba antes de renderizar un título de 120 valores escalares Unicode y un texto de 4.000 valores, no después de que una columna de base de datos los trunque.

La URL es sensible aunque los valores parezcan inocuos. Un proxy inverso puede registrar la ruta completa, el historial del navegador puede sincronizarla, un referrer puede exponerla a otro origen y una captura o evento de analítica puede copiarla. Configura una Referrer-Policy adecuada, elimina la cadena de consulta con una redirección del mismo origen después de crear un borrador validado y asegúrate de que la redirección no convierta una solicitud rechazada en aceptada. La redirección limpia datos; no autoriza.

Para POST, comprueba primero request.method, la cabecera Content-Type y el enctype declarado. Analiza application/x-www-form-urlencoded con un máximo de bytes y de campos. Para multipart/form-data, exige un boundary, rechaza partes multipart anidadas salvo soporte explícito y limita tanto los bytes totales como cada parte. Comprueba Content-Length cuando exista, pero aplica también un límite de streaming porque las solicitudes chunked no tienen una longitud declarada fiable. Aborta el lector del cuerpo al superar el límite y devuelve un 413 estable o el estado visible too-large.

El ejemplo solo establece un límite del parser. El código de producción aún necesita una implementación de streaming, una biblioteca multipart con límite explícito y un mapeo de errores que nunca repita el cuerpo. No muestres un mensaje de excepción que contenga un valor de campo. Un parser que acepta un campo desconocido como admin, redirect o callback amplía el contrato aunque la aplicación lo ignore después; rechaza nombres desconocidos antes de la lógica de negocio.

El campo url tiene su propia política. Analízalo como URL, exige https: o una excepción http: revisada explícitamente, rechaza componentes de usuario y contraseña y decide si se descartan los fragmentos. Una URL que apunte al mismo endpoint de compartir puede crear un bucle de redirección, mientras que una URL data: puede contener megabytes de contenido codificado. Si el producto acepta solo enlaces públicos, rechaza nombres de host de redes privadas en el límite del servidor y esquemas peligrosos en la página. Esto valida la entrada; no afirma que el destino del enlace sea seguro.

Archivos, repetición y CSRF. multipart/form-data puede transportar un archivo aunque el producto visible solo pida título y URL. Define una lista permitida de archivos, tamaño máximo y cantidad máxima separados. Usa el MIME declarado para enrutar y luego inspecciona los bytes mágicos en cuarentena; la cabecera la proporciona el emisor. Para un fixture de imagen pequeño, una política podría permitir image/png y image/jpeg hasta 2 MiB, un archivo y un límite de píxeles decodificados. Rechaza archivos comprimidos, scripts y archivos poliglota salvo revisión explícita. No pongas una ruta temporal subida en el registro de aceptación. Mantén los bytes del archivo en una cuarentena breve propiedad de la solicitud, no en la caché del service worker ni en una base de datos compartida del navegador. Escanea o procesa antes de un guardado aprobado, separa el nombre temporal del nombre original y elimina al cancelar, agotar el tiempo, fallar el análisis o expirar. Un MIME válido no es un análisis de malware, y un borrador local no es consentimiento para subirlo. Si el entorno no puede inspeccionar un archivo, muestra file-review-unavailable y conserva la alternativa en vez de aceptarlo silenciosamente.

Web Share Target es una entrada de estilo navegación, por lo que también aplican las suposiciones normales de CSRF. Una solicitud del mismo origen puede llevar cookies ambientales y la ruta puede abrirse fuera de la hoja de compartir del sistema operativo. Exige una sesión de aplicación, un token CSRF de corta duración para persistencia que cambie estado o una confirmación explícita antes de guardar en servidor. La presencia de share_target no demuestra que el navegador haya invocado la ruta mediante compartir. La ruta debe ser segura al pegarla en la barra de direcciones y al abrirla con un enlace normal.

Una clave de idempotencia evita que los reintentos creen dos borradores, pero no autentica al emisor. Genera un identificador aleatorio en el límite de la aplicación, vincúlalo a la sesión actual y a la revisión del manifiesto y hazlo expirar en una ventana breve y documentada. Si la misma clave llega con detalles de método distintos o con otra sesión, clasifícala como key-conflict y no mezcles los registros. Una repetición idéntica puede devolver el resultado acotado original, como accepted-local, duplicate o expired, sin devolver los campos privados.

No uses solo una marca de tiempo como clave de repetición. La desviación del reloj, la entrega retrasada y dos comparticiones legítimas en el mismo segundo la vuelven ambigua. No derives un marcador de repetición del texto sin procesar y lo llames anónimo: un título o URL corto se puede adivinar y comparar. Prefiere un ID de fixture opaco en los registros y conserva cualquier registro de comparación con acceso controlado y por poco tiempo. El límite de privacidad incluye telemetría, informes de fallos, reproducción de sesiones, cuerpos de solicitudes en colas y exportaciones de soporte, no solo la base de datos principal.

Registros de aceptación. Un registro de aceptación es útil si permite a un revisor reproducir una rama visible sin conservar el material compartido. Incluye la revisión del fixture, la etiqueta del navegador y sistema operativo, ruta, método, enctype declarado, cantidad de bytes, nombres de campos aceptados, resultado de validación, clasificación de duplicado, estado de alternativa y fecha límite de borrado. Excluye texto del título, valores URL, nombres de archivo, bytes, cookies, cabeceras de autorización y la cadena de consulta completa. Un registro estable se puede comparar entre versiones del navegador sin convertirse en un archivo de contenido.

{
  "fixtureRevision": 3,
  "route": "/inbox/share",
  "method": "POST",
  "enctype": "multipart/form-data",
  "bodyBytes": 4096,
  "fields": ["title", "text", "url"],
  "fileCount": 0,
  "validation": "accepted-local",
  "replay": "new",
  "csrf": "confirmed",
  "retention": "delete-after-cancel"
}

Una tabla de decisiones hace revisable el contrato:

Límite	Qué establece el resultado	Siguiente acción segura
Manifiesto no compatible o destino no instalado	El navegador no puede invocar esta entrada	Mantén la navegación normal y la alternativa de pegar
GET con campo demasiado grande o repetido	El contrato de URL no es válido	Elimina la consulta, muestra un error acotado y no guardes
POST con tipo MIME inesperado	No se cumplió el contrato declarado del cuerpo	Aborta el análisis y devuelve content-type-rejected
Archivo sobre el límite por archivo	Se superó la política de archivos	Borra la parte temporal y muestra la regla de tamaño
Campos válidos sin confirmación	Puede mostrarse un borrador local	Déjalo local; no crees un registro de servidor
Misma clave de idempotencia y mismos detalles	Se observó una entrega duplicada	Devuelve el resultado general anterior sin el cuerpo
Misma clave con detalles o sesión distintos	Existe un conflicto de repetición	Rechaza, avisa mínimamente y exige una acción nueva
Service worker ausente u obsoleto	La ruta prevista del worker no está disponible	Conserva la ruta y ofrece copiar o reintentar

La tabla separa lo que establece una observación del navegador de lo que el producto quisiera afirmar. Un estado visible accepted-local demuestra que este fixture pasó las comprobaciones de la página. No demuestra que la aplicación fuente enviara solo esos campos, que la persona quisiera cada valor ni que un guardado posterior del servidor respete el plazo de retención declarado.

Capacidad y limitación de BotBrowser. Para este tema de Web Share Target, BotBrowser puede repetir un fixture autorizado del mismo origen GET o POST, inspeccionar la ruta del manifiesto, ejercitar la validación del service worker y comprobar estados visibles de aceptado, rechazado, duplicado, demasiado grande, worker ausente y alternativa. La documentación de plataforma de BotBrowser describe el límite del navegador controlado. BotBrowser no puede abrir un selector de compartir del sistema operativo, elegir una aplicación fuente real, observar la decisión de divulgación de una persona, escanear una canalización de archivos externa ni certificar un borrado realizado por un servidor fuera del fixture.

Mantén el resultado estrecho y explícito: registra accepted-local, duplicate, rawContentKept=false, osShareSource=not-observed y serverRetention=not-certified en lugar de afirmar que se observó un selector del sistema o un borrado del servidor.

Repite el mismo fixture después de cambiar una sola variable: action, scope, campos aceptados, enctype, límite del cuerpo, versión del service worker, ventana de idempotencia o ruta alternativa. Compara la primera divergencia de estado visible. Un aprobado en contexto controlado aporta evidencia del contrato de página y solicitud; no es una declaración de compatibilidad universal con todas las superficies de compartir del sistema operativo ni una certificación de privacidad.

Fuentes

• Web Share Target de WICG
• MDN: Web Share Target API
• MDN: miembro share_target
• MDN: compartir datos entre aplicaciones

Conclusión práctica

Declara un share_target estrecho, analiza GET y POST con las mismas reglas y separa aceptación de persistencia. Un fixture idempotente y una alternativa visible hacen revisable la variación del navegador sin convertir una entrega mediada en identidad o prueba de entrega. Repite el fixture tras cada cambio de manifiesto, service worker, campo aceptado o política de retención.