Cómo se audita una aplicación de Tauri
El procedimiento de dos horas: qué ficheros se abren, en qué orden, y qué pregunta responde cada uno. La ruta que convierte ocho niveles de teoría en una lista de hallazgos.
La ruta
Seis paradas, en este orden, y el orden importa: cada una da el contexto que hace útil la siguiente.
El paso 3 es la mitad del tiempo y es donde están los hallazgos serios. Los pasos 1 y 2 son rápidos y dan el marco; sin ellos, leer comandos es leer código sin saber cuáles están expuestos de verdad.
Qué pregunta responde cada parada
La parada 3, que es donde se va el tiempo
Leer comandos es la parte lenta y conviene hacerla con un criterio fijo, no leyendo por leer. Tres preguntas por comando, en este orden:
- ¿Qué recibe de la webview? Si recibe una ruta, una URL, una consulta o un nombre de programa, ya hay algo que mirar. Nivel 14.4.
- ¿Qué hace con eso antes de usarlo? Si la respuesta es «nada», el hallazgo está.
- ¿Es de dominio o primitivo? Un comando llamado «leer fichero» es un hallazgo por su forma, aunque hoy nadie le pase nada raro.
Y un atajo que ahorra la mitad del tiempo: empieza por los comandos que las capabilities exponen de verdad. Una aplicación puede tener cuarenta comandos y exponer doce; los otros veintiocho no son superficie hoy — aunque conviene anotarlos, porque una capability futura los convierte en superficie sin tocar el código.
Lo que no se ve leyendo
Y por eso está la parada 6:
- Qué guarda en el navegador. Nivel 31.3, y siempre hay algo.
- Qué avisos hay en la consola. Bloqueos de la política que alguien lleva meses ignorando, o peor, ninguno porque no hay política.
- Qué llama de verdad. El truco del nivel 32.2 —activar el aislamiento con un hook que solo registre— vale también aquí, y en una aplicación ajena es la forma más rápida de saber qué se usa.