Revisar un módulo entero buscando el contexto equivocado

Un barrido de salidas se hace con método: buscar todas las inserciones (en plantillas, las llaves dobles y las salidas sin escape; en JavaScript, las asignaciones a innerHTML, outerHTML, insertAdjacentHTML y sus parecidos frente a textContent), y para cada una anotar archivo y línea, contexto, estrategia que se aplica y de dónde viene el dato. La pregunta de cada fila es la misma: ¿la estrategia es la del intérprete que lee el valor en ese punto?

Abre el laboratorio y lee barrido-insercion.txt en la carpeta tinajacoa-agenda, con sus notas al final. Recuerda que todas las plantillas escapan para HTML por extensión, que parrafos escapa antes de añadir saltos y que |e('url') codifica para una dirección.

No todas las salidas las arma el servidor. Un archivo de JavaScript que concatena datos y los asigna como HTML crea el mismo problema que una plantilla sin escape, solo que en el navegador. La forma correcta en el cliente es tratar el dato como texto con textContent o crear los nodos uno a uno.

Pasar datos al script como JSON es la idea correcta, pero un bloque <script> lo cierra el analizador de HTML al ver la secuencia de cierre de etiqueta, sin importar si está dentro de una cadena de JavaScript. Por eso el JSON que se inserta dentro de un script necesita que < y > salgan como secuencias de escape. AgendaController.php arma agenda_json con los títulos de los organizadores; SedeController.php, de otro módulo, hace lo mismo con las sedes.

Cinco puntos mal codificados no pesan lo mismo. La prioridad la marca quién controla el dato, cuántas personas lo ven y qué tan fácil es que el valor salga del contexto. Lee otra vez el origen de los datos en encargo.txt.

Un barrido manual encuentra lo de hoy. Lo de mañana lo encuentra una regla automática y una prueba que se repite en cada cambio.