Pero en este aplicaría esta vulnerabilidad ya que se esta manejando todo de manera local por así decirlo, en un caso practico por ejemplo con un token de sesión el servidor me retornaría un 401 y eso dispararía el cierre de sesión del usuario
Introducción
¿Qué tan seguro es tu sitio?
Validación de entradas
A1: injection
A7: cross-site scripting o XSS
Validando el user input en la página El Muro
Otras reglas de prevención
Autenticación rota
A2: broken authentication
Protección de sesiones en el cliente
¿Dónde guardar una sesión?
¿Dónde guardar tokens JWT?
Otras estrategias avanzadas de seguridad
Exposición de datos sensibles
A3: sensitive data exposure
Tokens firmados y encriptados
Próximos pasos
¿Quieres más cursos de Next.js?
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Aportes 3
Preguntas 0
Pero en este aplicaría esta vulnerabilidad ya que se esta manejando todo de manera local por así decirlo, en un caso practico por ejemplo con un token de sesión el servidor me retornaría un 401 y eso dispararía el cierre de sesión del usuario
El trabajo del componente Protected se podria hacer tambien de forma automatica desde src/pages/middleware.ts, con la función de Middleware de NextAuth, que me protege bien sea toda la aplicación o solo las páginas que se le indiquen en el matcher. La información está acá: https://next-auth.js.org/configuration/nextjs#middleware
Desde el servidor se proteje las rutas con una redireccion:
if (session == null) {
return {
redirect: {
destination: '/api/auth/signin',
permanent: false,
},
}
}
En el cliente se protege usando la verificacion del hook useSession:
if (session == null) {
return <AccessDenied />
}
Componente reutilizable que verifica la existencia de sesion:
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
o inicia sesión.