Por framework
Seguridad de ASP.NET Core — errores en producción, secretos y autorización
ASP.NET Core es sólido, pero los incidentes vienen de la configuración: errores detallados expuestos en producción, secretos incrustados en appsettings y [Authorize] ausente. Oculta los errores de prod, carga los secretos fuera de la configuración, autoriza de forma explícita. Defensivo, sin pasos de ataque.
Para: cualquiera que ejecute una app o API en ASP.NET Core. Aquí no hay pasos de ataque, solo mantener funcionando la base sólida mientras cierras los huecos que abre la configuración. Para el panorama completo, consulta el centro de seguridad por framework.
Los tres grandes tropiezos (se abren en la configuración)
Los mecanismos de ASP.NET Core son excelentes, pero estos tres son tuyos para protegerlos en la configuración y el código.
① Errores detallados en prod
La Developer Exception Page, etc. filtra detalles internos. Extraídos mediante errores deliberados.
② Secretos en appsettings
Cadenas de conexión/claves incrustadas. Fuga por commit accidental o exposición.
③ [Authorize] ausente
Si lo olvidas, cualquiera lo alcanza. Tampoco hay comprobación de propietario.
Vigila también la deserialización insegura (BinaryFormatter, etc.), el over-posting en el model binding y los CVE de dependencias NuGet sin parchear.
Cómo cerrarlas (3 pasos)
Oculta los errores detallados en producción
Carga los secretos fuera de la configuración
Haz la autorización explícita y corta las rutas de entrada peligrosas
[Authorize] y comprobaciones de propietario a los endpoints (inclina hacia denegar por defecto). Limita el over-posting con DTO o [Bind], y no deserialices datos no confiables con formatos inseguros. Mantén las dependencias NuGet con CVE monitoreados + parcheados rápido (→ qué es IDOR).Común (peligroso)
- Developer Exception Page expuesta en producción
- secretos incrustados en
appsettings.json [Authorize]olvidado, sin comprobación de propietario- modelos que aceptan todos los campos (over-posting)
Correcto
- producción oculta los errores detallados
- secretos desde User Secrets/entorno/Key Vault
- autorización explícita (denegar por defecto, comprobaciones de propietario)
- DTO/[Bind] para limitar el binding
La visión de este sitio: incluso sobre una base sólida, la configuración y la autorización corren de tu cuenta
ASP.NET Core tiene mecanismos sólidos para la autenticación, la autorización y la protección de datos, pero los ajustes de producción y aplicar la autorización son cosas que debes acertar por entorno y por endpoint. Este sitio corre sobre otra pila, pero el principio es el mismo: no filtres los detalles internos en producción, mantén los secretos fuera de la configuración, escribe siempre autorización en los puntos de entrada públicos y monitorea las dependencias en busca de CVE. Una base sólida solo rinde con una configuración correcta y una autorización explícita.
Sigue leyendo
- Centro: seguridad por framework · seguridad de Spring Boot (también empresarial, forma de dependencias/autorización similar)
- Secretos: mantén los secretos fuera de los directorios públicos · Práctica: el manual de respuesta a vulnerabilidades
- Glosario: qué es IDOR · qué es RCE
FAQ
Q¿ASP.NET Core es seguro?
ASP.NET Core es una base madura y sólida con mecanismos potentes para la autenticación, la autorización y la Data Protection. Usado correctamente es potente, pero los incidentes no vienen del núcleo sino de la configuración. Exponer errores detallados en producción, incrustar secretos en appsettings y olvidar los atributos de autorización se repiten menos como problemas específicos del framework que como problemas de configuración/operación.
Q¿Dónde deberían ir los secretos (cadenas de conexión, claves de API)?
La regla es: no incrustados en appsettings.json. En desarrollo usa User Secrets; en producción cárgalos desde variables de entorno o un gestor de secretos en la nube (p. ej. Key Vault). appsettings.json tiende a terminar en el repositorio y se filtra fácilmente por un directorio público o un commit accidental. Si uno se filtra, rota la cadena de conexión o la clave de inmediato.
Q¿Cómo evito olvidar los atributos de autorización?
Olvida [Authorize] en un controlador o endpoint y cualquiera puede alcanzarlo sin autenticación. Inclina el valor por defecto hacia 'denegar' (una política de reserva que rechaza las peticiones no autenticadas), haz los permisos explícitos con autorización basada en roles/políticas y escribe comprobaciones de propietario del recurso. No te quedes en 'con sesión = permitido': verifica también el propietario del objetivo.