part 5a

Author: pablo-maff

src/content/5/es/part5a.md

@@ -627,15 +627,15 @@ Las notificaciones deben estar visibles durante unos segundos. No es obligatorio
 
 Al final de la última [parte](/es/part4/autenticacion_basada_en_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>.
+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 nuevamente cuando 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. usando un formulario), que la aplicación luego puede ejecutar. Si usamos React correctamente, esto no debería ser posible, ya que [React desinfecta](https://es.legacy.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.
 
-Ha sido sugerido que la identidad de un usuario que ha iniciado sesión debería guardarse como [httpOnly cookies](https://developer.mozilla.org/es/docs/Web/HTTP/Cookies#cookies_secure_y_httponly), para que código de JavaScript no pueda tener ningún acceso al token. El inconveniente de esta solución es que haría la implementación de aplicaciones SPA un poco mas compleja. Necesitaríamos implementar al menos una pagina separada para el inicio de sesión.
+Ha sido sugerido que la identidad de un usuario que ha iniciado sesión debería guardarse como [httpOnly cookies](https://developer.mozilla.org/es/docs/Web/HTTP/Cookies#cookies_secure_y_httponly), para que el código de JavaScript no pueda tener ningún acceso al token. El inconveniente de esta solución es que haría la implementación de aplicaciones SPA un poco mas compleja. Necesitaríamos implementar al menos una pagina separada para el inicio de sesión.
 
-Sin embargo, es importante notar que incluso el uso de cookies httpOnly no garantiza nada. Incluso se ha sugerido que las cookies httpOnly [no son mas seguras](https://academind.com/tutorials/localstorage-vs-cookies-xss/) que el uso del almacenamiento local. 
+Sin embargo, es importante notar que incluso el uso de cookies httpOnly no garantiza nada. Incluso se ha sugerido que las cookies httpOnly [no son mas seguras](https://academind.com/tutorials/localstorage-vs-cookies-xss/) que el uso del almacenamiento local.
 
 Al fin y al cabo, no importa la solución utilizada, lo mas importante es [minimizar el riesgo](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) de ataques XSS por completo.