Seguridad
Autenticar sin sesión, autorizar con precisión y no copiar código obsoleto.
Securización de APIs con Spring Security
Hasta ahora, biblio-api acepta a todo el mundo. Cualquiera puede crear un libro, borrar otro o leer el catálogo completo. En un equipo de desarrollo resulta cómodo; desde el primer despliegue, es una puerta abierta.
Proteger una API plantea dos preguntas distintas, y confundirlas es la primera fuente de errores. ¿Quién eres? corresponde a la autenticación, y la respuesta de fallo es 401 Unauthorized. ¿Tienes derecho a hacer esto? corresponde a la autorización, y la respuesta de fallo es 403 Forbidden. Un usuario correctamente autenticado que intenta borrar un libro sin tener el rol necesario debe recibir un 403, no un 401: el segundo le haría creer que sus credenciales no son válidas y lo llevaría a volver a iniciar sesión en bucle.
Quien busca ayuda en línea sobre este tema se encuentra con una dificultad particular. Spring Security 6, incluido en Spring Boot 3, ha eliminado WebSecurityConfigurerAdapter. La clase no está deprecada: ya no existe. Sin embargo, la mayoría de los artículos, respuestas y ejemplos indexados desde hace diez años se basan en ella, y el lector que los copia obtiene un error de compilación que ninguno de esos artículos explica. La configuración ahora se declara mediante beans, en particular un bean SecurityFilterChain.
Comentarios
Los comentarios funcionan con GitHub Discussions
Inicia sesión con GitHub para participar en la discusión