Merge pull request #2688 from vlondonoma/patch-13

[es] Update part5a.md

Author: mluukkai

src/content/5/es/part5a.md

@@ -639,11 +639,11 @@ Las notificaciones deben estar visibles durante unos segundos. No es obligatorio
 
 ### Nota sobre el uso del almacenamiento local
 
-Al final de la ultima [parte](/en/part4/token_authentication#problems-of-token-based-authentication) mencionamos que el desafío de la autenticación basada en tokens es cómo afrontar la situación en la cual el acceso a la API de el poseedor del token necesita ser revocado.
+Al final de la última [parte](/es/part4/autenticacion_de_token#problemas-de-la-autenticacion-basada-en-tokens) mencionamos que el desafío de la autenticación basada en tokens es cómo afrontar la situación en la cual el acceso a la API del poseedor del token necesita ser revocado.
 
 Hay dos soluciones para este problema. La primera es limitar el periodo de validez de un token. Esto fuerza al usuario a iniciar sesión otra vez una vez que el token ha expirado. El otro enfoque es guardar la información de validez de cada token en la base de datos del backend. Esta solución es llamada frecuentemente <i>server side session</i>.
 
-No importa cómo la validez de los tokens es revisada y asegurada, guardar un token en el almacenamiento local puede significar un riesgo de seguridad si la aplicación tiene una vulnerabilidad que permite un ataque de [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/). Un ataque XSS es posible si la aplicación permite al usuario inyectar arbitrariamente código de JavaScript (ej. usar un formulario), que la aplicación luego puede ejecutar. Si usamos React correctamente esto no debería ser posible, ya que [React desinfecta](https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks) todo el texto que renderiza, lo que significa que no está ejecutando el contenido renderizado como JavaScript.
+No importa cómo la validez de los tokens es revisada y asegurada, guardar un token en el almacenamiento local puede significar un riesgo de seguridad si la aplicación tiene una vulnerabilidad que permite un ataque de [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/). Un ataque XSS es posible si la aplicación permite al usuario inyectar arbitrariamente código de JavaScript (ej. usar un formulario), que la aplicación luego puede ejecutar. Si usamos React correctamente, esto no debería ser posible, ya que [React desinfecta](https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks) todo el texto que renderiza, lo que significa que no está ejecutando el contenido renderizado como JavaScript.
 
 Si uno quiere estar seguro, la mejor opción es no almacenar un token en el almacenamiento local. Esta puede ser una opción en situaciones en las que filtrar un token puede tener consecuencias trágicas.