Escenario
Eres responsable de una plataforma web multisitio. El equipo de seguridad desea reportes centralizados de CSP, Permissions-Policy, obsolescencia e intervenciones para que los incidentes no dependan de capturas de pantalla de los usuarios. Ingeniería propone la Reporting API: declarar endpoints con Reporting-Endpoints, recibir application/reports+json y, opcionalmente, observar reportes en la página con ReportingObserver. Explica la decisión de adopción, el lanzamiento por etapas y las métricas de éxito.
Qué evalúa el entrevistador
- Transformar la detección temprana de problemas en el navegador en resultados medibles para el usuario y el negocio.
- Comprender que la Reporting API funciona bajo el principio de mejor esfuerzo (best-effort) y no es un canal de mensajería confiable.
- Gestionar el soporte de navegadores, la seguridad de los endpoints, la privacidad y la gobernanza de datos.
- Diseñar un despliegue progresivo, deduplicación y criterios de reversión (rollback gates).
Preguntas para clarificar
Confirma los tipos de reportes, los navegadores objetivo, el número de sitios, la línea base actual de CSP/obsolescencia, los requisitos de retención y la capacidad de gestión de alertas. Pregunta si el endpoint ya cuenta con autenticación, si se pueden enviar fragmentos de URL y si el objetivo es reducir incidentes, disminuir el tiempo de reparación u obtener evidencia de cumplimiento.
Respuesta de 30 segundos
La adoptaría como una señal de diagnóstico de bajo costo y no crítica. Comenzaría con el modo de solo reporte (report-only) y una muestra pequeña de sitios; aceptaría únicamente tipos de reportes aprobados y añadiría límites de tasa (rate limits), deduplicación y anonimización/redacción, conservando al mismo tiempo los registros existentes. Mediría la tasa de reportes accionables, el tiempo desde el primer reporte hasta la solución, la tasa de falsos positivos, el costo del endpoint y la cobertura en navegadores antiguos. Expandiría solo después de una revisión de calidad de datos y privacidad. Ninguna decisión de seguridad debe depender de una entrega garantizada.
Razonamiento paso a paso
1. Plantear el problema y las alternativas
La Reporting API puede transportar reportes de CSP, Permissions-Policy, COEP, Integrity, obsolescencia, caídas (crashes) e intervenciones. Compárala con SDKs de RUM existentes, registros del servidor y consolas del navegador en términos de cobertura incremental, costo en el cliente, sensibilidad de los datos y operaciones.
2. Definir una señal mínima viable
Comienza con csp-violation y deprecation, utilizando una cola lógica por tipo. Valida Content-Type: application/reports+json en el lado del servidor; limita el tamaño del payload, el origen y los campos; deduplica por sitio, versión y huella digital (fingerprint). Una interrupción del endpoint solo debe provocar la pérdida de diagnósticos, nunca de solicitudes de página.
3. Gestionar la confiabilidad y la compatibilidad
La especificación establece que la entrega no está garantizada; los agentes de usuario pueden descartar reportes debido a condiciones de red o de políticas. MDN señala que el soporte es más sólido en navegadores más recientes y puede no estar presente en dispositivos más antiguos. Segmenta la cobertura por versión de navegador y mantén los registros del servidor junto con ReportingObserver como complementos. Recibir cero reportes nunca demuestra que haya cero infracciones.
4. Establecer criterios de privacidad, seguridad y lanzamiento
Los reportes pueden incluir URLs, user agents y detalles de políticas. Utiliza HTTPS, autenticación o rutas no adivinables, filtrado de parámetros de consulta (query parameters), retención acotada y auditorías de acceso. Comienza con solo reporte en sitios internos y en el 1% del tráfico; monitorea la carga del endpoint, los campos sensibles y la tasa accionable. Desactiva la configuración del endpoint si se filtra PII, los costos se disparan o se genera una tormenta de alertas.
Respuesta de muestra de alta calidad
Posicionaría esto como una capa de diagnóstico temprano para políticas del navegador y obsolescencias, no como un nuevo sistema de registro. La decisión consta de tres fases de validación (gates). Primero, valor: muestrear 10 sitios representativos en modo de solo reporte, verificar que los reportes localicen tickets existentes y establecer la línea base del tiempo medio de detección. Segundo, riesgo: revisión de seguridad y privacidad sobre los campos del endpoint, retención, aislamiento entre sitios y control de acceso. Tercero, operaciones: pruebas de carga ante ráfagas de reportes y establecimiento de cuotas por origen, claves de deduplicación y monitoreo de la tasa de descarte. Dado que la entrega es de mejor esfuerzo, se deben conservar RUM, registros del servidor y una alternativa manual. Después del lanzamiento, muestra la cobertura por familia de navegadores y rastrea la tasa accionable, el MTTR, los falsos positivos, los reportes por millón de páginas y el costo por tipo de reporte. Si un navegador tiene baja cobertura, limita las conclusiones al tráfico cubierto. Si el endpoint falla, elimina el encabezado de respuesta Reporting-Endpoints para revertir los cambios sin alterar las solicitudes principales de la página.
Errores comunes
- Tratar la Reporting API como una cola confiable o un registro de auditoría de cumplimiento.
- Declarar el éxito basándose en una disminución de reportes sin corregir por la cobertura del navegador.
- Almacenar URLs sin procesar, parámetros de consulta y user agents indefinidamente.
- Discutir la integración del SDK sin considerar los límites de tasa del endpoint, la deduplicación, el costo o la propiedad del sistema.
- Habilitar todos los sitios a la vez sin modo de solo reporte, muestreo o criterios de reversión.
Preguntas de seguimiento y respuestas
“¿Por qué no usar ReportingObserver?”
Es más fácil para experimentos en la página y manejo personalizado, pero una página que ha sufrido una caída no puede seguir observando. Un endpoint remoto puede recibir reportes independientemente del ciclo de vida de la página. Pueden complementarse entre sí, pero ninguno garantiza la entrega.
“¿Cómo demostrarías que el producto funciona?”
Utiliza una comparación de antes y después del tiempo de detección, tiempo de reparación, tasa accionable y falsos positivos para problemas confirmados, segmentada por cobertura de navegador. Monitorea el costo del endpoint y los eventos de privacidad al mismo tiempo.
“¿Qué pasa con los navegadores no compatibles?”
Trata la matriz de compatibilidad como una restricción del producto, conserva los registros del servidor y RUM, y delimita las conclusiones al tráfico cubierto. No inyectes un polyfill costoso simplemente para hacer que la cobertura parezca uniforme.