Mapear rutas, entradas y permisos del código

Una aplicación web es, para quien la evalúa, una lista de puertas: cada combinación de método y ruta que acepta. En el código esa lista vive en los enrutadores, y al lado de cada puerta está lo que se exige para cruzarla: una sesión, un rol, una firma. Leer primero ese mapa tiene dos ventajas. Dice dónde entra cada dato de fuera, que es donde empiezan casi todos los fallos, y deja ver de un vistazo las puertas que no exigen nada.

El inventario se arma con tres columnas por ruta: método y ruta completa, de qué datos de la petición depende (parámetros de la dirección, de la consulta, del cuerpo, cabeceras, cookies) y qué comprobaciones corren antes del manejador. La ruta completa no siempre está escrita en un solo sitio: un enrutador se monta bajo un prefijo en otro archivo.

En Express las comprobaciones se encadenan: app.use('/pedidos', requiereSesion, ...) pone la sesión delante de todo lo que cuelga de ese prefijo, y router.get('/perfil', requiereSesion, ...) la pone delante de una sola ruta. Para saber qué exige una ruta hay que mirar los dos sitios: dónde se monta el enrutador y cómo se registra la ruta dentro de él.

Abre el laboratorio. Empieza por api/app.js y recorre después cada archivo de api/rutas.

La documentación de Express es clara en un punto que se olvida a menudo: lo que se registra primero se ejecuta primero, y un manejador que responde termina el recorrido. Dentro de un enrutador, router.use(requiereSesion) protege solo lo que se registra después de esa línea. Una ruta escrita encima queda fuera, aunque esté en el mismo archivo y el desarrollador crea que todo el archivo está protegido.

Este tipo de fallo casi nunca lo marca una herramienta: el código es correcto línea a línea, y el problema está en el orden. Lee el enrutador del panel de administración y la nota del evaluador sobre Express.

No toda ruta sin sesión es un hallazgo. El registro y el ingreso son públicos por definición. Un aviso de la pasarela de pagos tampoco puede llevar la sesión de un cliente: lo envía un servidor del proveedor. Lo que una ruta así debe exigir es otra cosa, que se lee en su manejador: una firma del proveedor calculada con una clave compartida, y el rechazo del aviso si no coincide.

Sigue la ruta de los avisos hasta su manejador.

El mapa termina en una lista corta de pruebas. Una prueba dirigida no recorre la aplicación entera: comprueba una hipótesis que salió del código, con la petición mínima que la confirma o la descarta, en el entorno que autoriza la carta. Para una ruta que se cree sin protección, la petición mínima es la misma ruta sin ninguna credencial; si responde con datos, la lectura queda confirmada.