Nueva categoría de riesgo en el Top Ten de OWASP: Esperar lo inesperado
Con la publicación por parte de OWASP de su Top Ten 2025, las empresas tienen un par de nuevas categorías de riesgo a las que prestar especial atención, incluida una categoría completamente nueva que demuestra, de una vez por todas, que lo que no sabes puede hacerte daño.
La nueva categoría, Mishandling of Exceptional Conditions, describe lo que puede salir mal cuando las organizaciones no están preparadas para prevenir, detectar y responder a situaciones inusuales o impredecibles. Según OWASP, esta vulnerabilidad puede desencadenarse cuando una aplicación no evita que ocurra algo inusual, no identifica un problema cuando surge y/o responde mal o no responde en absoluto cuando se produce una situación inesperada.
La idea de que las empresas deben estar preparadas para lo que no vieron venir refleja la realidad de los sistemas actuales, altamente distribuidos e interconectados. Y no es que OWASP esté hablando de problemas desconocidos: el manejo incorrecto de circunstancias excepcionales contiene 24 enumeraciones de debilidades comunes (CWE). Es sólo que esas CWEs, que implican un manejo inadecuado de errores, fallos en la apertura de eventos, errores lógicos y otros escenarios, pueden ocurrir bajo condiciones anormales. Esto puede resultar, por ejemplo, de una validación de entrada inadecuada, errores de alto nivel en el manejo de funciones y el manejo inconsistente (o inexistente) de excepciones. Como afirma OWASP, "Cada vez que una aplicación no está segura de su siguiente instrucción, una condición excepcional ha sido mal manejada".
Esas circunstancias excepcionales pueden hacer que los sistemas caigan en un estado impredecible, provocando caídas del sistema, comportamientos inesperados y vulnerabilidades de seguridad duraderas. La clave para prevenir este tipo de interrupciones es, esencialmente, esperar lo peor y planificar estar preparado para cuando ocurra lo inesperado.
Circunstancias excepcionales y evolución del Top Ten
La composición de la lista cuatrienal de los diez riesgos más graves para la seguridad de las aplicaciones web se ha mantenido bastante estable a lo largo de los años, con algunas categorías que se desplazan por la lista y quizá una o dos incorporaciones cada cuatro años. La iteración de 2025 cuenta con dos nuevas entradas, entre las que se encuentra la Gestión incorrecta de condiciones excepcionales, en el número 10. La otra, Fallos en la cadena de suministro de software, se encuentra en el número 11. La otra, Fallos en la cadena de suministro de software, que ocupa el nº 3, es una ampliación de una categoría anterior, Componentes vulnerables y obsoletos (nº 6 en 2021), que ahora incluye una amplia gama de problemas de software. (Para los que lleven la cuenta, el control de acceso defectuoso sigue siendo el riesgo número 1).
Las condiciones excepcionales que constituyen la categoría más reciente pueden crear toda una serie de vulnerabilidades, desde fallos lógicos hasta desbordamientos, pasando por transacciones fraudulentas y problemas de memoria, temporización, autenticación, autorización y otros factores. Estos tipos de vulnerabilidades pueden afectar a la confidencialidad, disponibilidad e integridad de un sistema o de sus datos. Permiten a un atacante manipular la gestión defectuosa de errores de una aplicación, por ejemplo, para explotar la vulnerabilidad, dijo OWASP.
Un ejemplo de fallo en la gestión de condiciones inesperadas es cuando una aplicación identifica excepciones mientras se cargan archivos durante un ataque de denegación de servicio, pero luego no libera los recursos. Cuando esto ocurre, los recursos permanecen bloqueados o no disponibles, lo que provoca el agotamiento de los recursos. Si un atacante se inmiscuye en una transacción financiera de varios pasos, un sistema que no revierta la transacción una vez detectado un error podría permitir al atacante vaciar la cuenta del usuario. Si se detecta un error en mitad de una transacción, es muy importante "cerrar en caso de error", es decir, revertir toda la transacción y empezar de nuevo. Intentar recuperar una transacción a mitad de camino puede crear errores irrecuperables.
Fallo cerrado frente a fallo abierto
Entonces, ¿cuál es la diferencia entre estas dos acciones? Aclaremos:
Falla abierto: Si un sistema "falla abierto", sigue funcionando o permanece "abierto" cuando algo va mal. Esto es útil cuando mantener las cosas en funcionamiento es muy importante, pero puede ser arriesgado para la seguridad.
Fallo cerrado: Si un sistema "falla cerrado", se apaga automáticamente o se vuelve seguro cuando hay un problema. Esto es más seguro desde el punto de vista de la seguridad porque ayuda a evitar accesos no autorizados.
Errores imprevistos
La prevención de este tipo de riesgos empieza por planificar lo desconocido. Y eso implica ser capaz de detectar cualquier posible error del sistema cuando se produzca y tomar medidas para resolver el problema. Tienes que ser capaz de informar adecuadamente al usuario (sin revelar información crítica al atacante), registrar el evento y, si es necesario, emitir una alerta.
He aquí un ejemplo de la revelación de un error de consulta SQL, junto con la ruta de instalación del sitio, que puede utilizarse para identificar un punto de inyección:
Advertencia: odbc_fetch_array() espera que el parámetro /1 sea un recurso, dado booleano en D:\app\index_new.php en la línea 188
Lo ideal sería que un sistema dispusiera de un gestor de excepciones global para detectar errores que se pasan por alto, junto con funciones como herramientas de supervisión u observabilidad, o una función que detecte errores repetidos o patrones que podrían indicar un ataque en curso. Esto puede ayudar a defenderse contra los ataques que pretenden aprovecharse de cualquier debilidad que la empresa pueda tener en el manejo de errores.
Para una aplicación web Java estándar, por ejemplo, se puede configurar un gestor de errores global a nivel del descriptor de despliegue web.xml -en este caso, una configuración utilizada a partir de la especificación Servlet versión 2.5 y superiores-.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Este pequeño bloque de código indica a una aplicación web Java qué hacer cuando algo va mal entre bastidores. En lugar de mostrar a los usuarios un mensaje de error confuso o una pantalla en blanco, detecta silenciosamente el problema y los envía a una página de error personalizada. En este caso, esa página sería error.jsp.
Debido a que está configurado para manejar los tipos generales de java.lang.Exception, actúa como un manejador de errores maestro para toda la aplicación. Eso significa que no importa dónde se produzca un error, los usuarios serán redirigidos a la misma página de error amigable y consistente en lugar de ver detalles técnicos en bruto.
Prevenir lo inesperado
Lo ideal sería que las organizaciones trabajaran para evitar, en la medida de lo posible, que se produzcan situaciones excepcionales. Implantar límites de velocidad, cuotas de recursos, estrangulamiento y otros límites puede ayudar contra los ataques de denegación de servicio y de fuerza bruta, por ejemplo. Es posible que desee identificar errores repetidos idénticos e incluirlos sólo como estadísticas, para que no interfieran con el registro y la supervisión automatizados. Un sistema también debería incluir:
Validación estricta de la entrada de datos, para garantizar que sólo se introducen en el flujo de trabajo datos correctamente formados y depurados. Debe realizarse al principio del flujo de datos, idealmente en cuanto se reciben los datos.
Mejores prácticas de gestión de errores, para detectar los errores justo donde se producen. Deben tratarse con eficacia: Diga claramente a los usuarios que deben mantener un registro y enviar alertas si es necesario. Un gestor de errores global también es ideal para detectar cualquier error que se haya pasado por alto.
La seguridad general de las transacciones también es imprescindible. Siempre "a prueba de fallos": si algo va mal, deshaga toda la transacción. Y no intentes arreglar una transacción a medias: puede causar problemas mayores.
Registro, supervisión y alerta centralizados, junto con un gestor de excepciones global, que permite una investigación rápida de las incidencias y un proceso uniforme de gestión de los eventos, al tiempo que facilita el cumplimiento de los requisitos de conformidad.
Modelado de amenazas y/o revisión del diseño seguro, realizado en la fase de diseño de los proyectos.
Revisión del código o análisis estático, así como pruebas de estrés, rendimiento y penetración realizadas en el sistema final.
La gestión incorrecta de condiciones excepcionales puede ser una nueva categoría, pero implica algunos principios básicos de ciberseguridad y pone de relieve por qué las empresas deben estar preparadas para lo que no necesariamente están anticipando. Puede que no sepas qué forma tomarán las condiciones excepcionales, pero sabes que ocurrirán. La clave está en estar preparado para manejarlas todas de la misma manera, lo que facilitará la detección y respuesta a esas condiciones cuando surja lo inevitable.
Nota para los usuarios deSCW Trust Score™ :
A medida que actualizamos el contenido de nuestra Learning Platform para alinearlo con el estándar OWASP Top 10 2025, es posible que observe pequeños ajustes en la puntuación de confianza de sus desarrolladores Full Stack. Póngase en contacto con su representante de Customer Success si tiene alguna pregunta o necesita ayuda.
.png)
OWASP Top 10 2025 añade la gestión incorrecta de condiciones excepcionales en el número 10. Mitigue los riesgos mediante una lógica "fail closed", gestores de errores globales y una estricta validación de entradas.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Con la publicación por parte de OWASP de su Top Ten 2025, las empresas tienen un par de nuevas categorías de riesgo a las que prestar especial atención, incluida una categoría completamente nueva que demuestra, de una vez por todas, que lo que no sabes puede hacerte daño.
La nueva categoría, Mishandling of Exceptional Conditions, describe lo que puede salir mal cuando las organizaciones no están preparadas para prevenir, detectar y responder a situaciones inusuales o impredecibles. Según OWASP, esta vulnerabilidad puede desencadenarse cuando una aplicación no evita que ocurra algo inusual, no identifica un problema cuando surge y/o responde mal o no responde en absoluto cuando se produce una situación inesperada.
La idea de que las empresas deben estar preparadas para lo que no vieron venir refleja la realidad de los sistemas actuales, altamente distribuidos e interconectados. Y no es que OWASP esté hablando de problemas desconocidos: el manejo incorrecto de circunstancias excepcionales contiene 24 enumeraciones de debilidades comunes (CWE). Es sólo que esas CWEs, que implican un manejo inadecuado de errores, fallos en la apertura de eventos, errores lógicos y otros escenarios, pueden ocurrir bajo condiciones anormales. Esto puede resultar, por ejemplo, de una validación de entrada inadecuada, errores de alto nivel en el manejo de funciones y el manejo inconsistente (o inexistente) de excepciones. Como afirma OWASP, "Cada vez que una aplicación no está segura de su siguiente instrucción, una condición excepcional ha sido mal manejada".
Esas circunstancias excepcionales pueden hacer que los sistemas caigan en un estado impredecible, provocando caídas del sistema, comportamientos inesperados y vulnerabilidades de seguridad duraderas. La clave para prevenir este tipo de interrupciones es, esencialmente, esperar lo peor y planificar estar preparado para cuando ocurra lo inesperado.
Circunstancias excepcionales y evolución del Top Ten
La composición de la lista cuatrienal de los diez riesgos más graves para la seguridad de las aplicaciones web se ha mantenido bastante estable a lo largo de los años, con algunas categorías que se desplazan por la lista y quizá una o dos incorporaciones cada cuatro años. La iteración de 2025 cuenta con dos nuevas entradas, entre las que se encuentra la Gestión incorrecta de condiciones excepcionales, en el número 10. La otra, Fallos en la cadena de suministro de software, se encuentra en el número 11. La otra, Fallos en la cadena de suministro de software, que ocupa el nº 3, es una ampliación de una categoría anterior, Componentes vulnerables y obsoletos (nº 6 en 2021), que ahora incluye una amplia gama de problemas de software. (Para los que lleven la cuenta, el control de acceso defectuoso sigue siendo el riesgo número 1).
Las condiciones excepcionales que constituyen la categoría más reciente pueden crear toda una serie de vulnerabilidades, desde fallos lógicos hasta desbordamientos, pasando por transacciones fraudulentas y problemas de memoria, temporización, autenticación, autorización y otros factores. Estos tipos de vulnerabilidades pueden afectar a la confidencialidad, disponibilidad e integridad de un sistema o de sus datos. Permiten a un atacante manipular la gestión defectuosa de errores de una aplicación, por ejemplo, para explotar la vulnerabilidad, dijo OWASP.
Un ejemplo de fallo en la gestión de condiciones inesperadas es cuando una aplicación identifica excepciones mientras se cargan archivos durante un ataque de denegación de servicio, pero luego no libera los recursos. Cuando esto ocurre, los recursos permanecen bloqueados o no disponibles, lo que provoca el agotamiento de los recursos. Si un atacante se inmiscuye en una transacción financiera de varios pasos, un sistema que no revierta la transacción una vez detectado un error podría permitir al atacante vaciar la cuenta del usuario. Si se detecta un error en mitad de una transacción, es muy importante "cerrar en caso de error", es decir, revertir toda la transacción y empezar de nuevo. Intentar recuperar una transacción a mitad de camino puede crear errores irrecuperables.
Fallo cerrado frente a fallo abierto
Entonces, ¿cuál es la diferencia entre estas dos acciones? Aclaremos:
Falla abierto: Si un sistema "falla abierto", sigue funcionando o permanece "abierto" cuando algo va mal. Esto es útil cuando mantener las cosas en funcionamiento es muy importante, pero puede ser arriesgado para la seguridad.
Fallo cerrado: Si un sistema "falla cerrado", se apaga automáticamente o se vuelve seguro cuando hay un problema. Esto es más seguro desde el punto de vista de la seguridad porque ayuda a evitar accesos no autorizados.
Errores imprevistos
La prevención de este tipo de riesgos empieza por planificar lo desconocido. Y eso implica ser capaz de detectar cualquier posible error del sistema cuando se produzca y tomar medidas para resolver el problema. Tienes que ser capaz de informar adecuadamente al usuario (sin revelar información crítica al atacante), registrar el evento y, si es necesario, emitir una alerta.
He aquí un ejemplo de la revelación de un error de consulta SQL, junto con la ruta de instalación del sitio, que puede utilizarse para identificar un punto de inyección:
Advertencia: odbc_fetch_array() espera que el parámetro /1 sea un recurso, dado booleano en D:\app\index_new.php en la línea 188
Lo ideal sería que un sistema dispusiera de un gestor de excepciones global para detectar errores que se pasan por alto, junto con funciones como herramientas de supervisión u observabilidad, o una función que detecte errores repetidos o patrones que podrían indicar un ataque en curso. Esto puede ayudar a defenderse contra los ataques que pretenden aprovecharse de cualquier debilidad que la empresa pueda tener en el manejo de errores.
Para una aplicación web Java estándar, por ejemplo, se puede configurar un gestor de errores global a nivel del descriptor de despliegue web.xml -en este caso, una configuración utilizada a partir de la especificación Servlet versión 2.5 y superiores-.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Este pequeño bloque de código indica a una aplicación web Java qué hacer cuando algo va mal entre bastidores. En lugar de mostrar a los usuarios un mensaje de error confuso o una pantalla en blanco, detecta silenciosamente el problema y los envía a una página de error personalizada. En este caso, esa página sería error.jsp.
Debido a que está configurado para manejar los tipos generales de java.lang.Exception, actúa como un manejador de errores maestro para toda la aplicación. Eso significa que no importa dónde se produzca un error, los usuarios serán redirigidos a la misma página de error amigable y consistente en lugar de ver detalles técnicos en bruto.
Prevenir lo inesperado
Lo ideal sería que las organizaciones trabajaran para evitar, en la medida de lo posible, que se produzcan situaciones excepcionales. Implantar límites de velocidad, cuotas de recursos, estrangulamiento y otros límites puede ayudar contra los ataques de denegación de servicio y de fuerza bruta, por ejemplo. Es posible que desee identificar errores repetidos idénticos e incluirlos sólo como estadísticas, para que no interfieran con el registro y la supervisión automatizados. Un sistema también debería incluir:
Validación estricta de la entrada de datos, para garantizar que sólo se introducen en el flujo de trabajo datos correctamente formados y depurados. Debe realizarse al principio del flujo de datos, idealmente en cuanto se reciben los datos.
Mejores prácticas de gestión de errores, para detectar los errores justo donde se producen. Deben tratarse con eficacia: Diga claramente a los usuarios que deben mantener un registro y enviar alertas si es necesario. Un gestor de errores global también es ideal para detectar cualquier error que se haya pasado por alto.
La seguridad general de las transacciones también es imprescindible. Siempre "a prueba de fallos": si algo va mal, deshaga toda la transacción. Y no intentes arreglar una transacción a medias: puede causar problemas mayores.
Registro, supervisión y alerta centralizados, junto con un gestor de excepciones global, que permite una investigación rápida de las incidencias y un proceso uniforme de gestión de los eventos, al tiempo que facilita el cumplimiento de los requisitos de conformidad.
Modelado de amenazas y/o revisión del diseño seguro, realizado en la fase de diseño de los proyectos.
Revisión del código o análisis estático, así como pruebas de estrés, rendimiento y penetración realizadas en el sistema final.
La gestión incorrecta de condiciones excepcionales puede ser una nueva categoría, pero implica algunos principios básicos de ciberseguridad y pone de relieve por qué las empresas deben estar preparadas para lo que no necesariamente están anticipando. Puede que no sepas qué forma tomarán las condiciones excepcionales, pero sabes que ocurrirán. La clave está en estar preparado para manejarlas todas de la misma manera, lo que facilitará la detección y respuesta a esas condiciones cuando surja lo inevitable.
Nota para los usuarios deSCW Trust Score™ :
A medida que actualizamos el contenido de nuestra Learning Platform para alinearlo con el estándar OWASP Top 10 2025, es posible que observe pequeños ajustes en la puntuación de confianza de sus desarrolladores Full Stack. Póngase en contacto con su representante de Customer Success si tiene alguna pregunta o necesita ayuda.
Con la publicación por parte de OWASP de su Top Ten 2025, las empresas tienen un par de nuevas categorías de riesgo a las que prestar especial atención, incluida una categoría completamente nueva que demuestra, de una vez por todas, que lo que no sabes puede hacerte daño.
La nueva categoría, Mishandling of Exceptional Conditions, describe lo que puede salir mal cuando las organizaciones no están preparadas para prevenir, detectar y responder a situaciones inusuales o impredecibles. Según OWASP, esta vulnerabilidad puede desencadenarse cuando una aplicación no evita que ocurra algo inusual, no identifica un problema cuando surge y/o responde mal o no responde en absoluto cuando se produce una situación inesperada.
La idea de que las empresas deben estar preparadas para lo que no vieron venir refleja la realidad de los sistemas actuales, altamente distribuidos e interconectados. Y no es que OWASP esté hablando de problemas desconocidos: el manejo incorrecto de circunstancias excepcionales contiene 24 enumeraciones de debilidades comunes (CWE). Es sólo que esas CWEs, que implican un manejo inadecuado de errores, fallos en la apertura de eventos, errores lógicos y otros escenarios, pueden ocurrir bajo condiciones anormales. Esto puede resultar, por ejemplo, de una validación de entrada inadecuada, errores de alto nivel en el manejo de funciones y el manejo inconsistente (o inexistente) de excepciones. Como afirma OWASP, "Cada vez que una aplicación no está segura de su siguiente instrucción, una condición excepcional ha sido mal manejada".
Esas circunstancias excepcionales pueden hacer que los sistemas caigan en un estado impredecible, provocando caídas del sistema, comportamientos inesperados y vulnerabilidades de seguridad duraderas. La clave para prevenir este tipo de interrupciones es, esencialmente, esperar lo peor y planificar estar preparado para cuando ocurra lo inesperado.
Circunstancias excepcionales y evolución del Top Ten
La composición de la lista cuatrienal de los diez riesgos más graves para la seguridad de las aplicaciones web se ha mantenido bastante estable a lo largo de los años, con algunas categorías que se desplazan por la lista y quizá una o dos incorporaciones cada cuatro años. La iteración de 2025 cuenta con dos nuevas entradas, entre las que se encuentra la Gestión incorrecta de condiciones excepcionales, en el número 10. La otra, Fallos en la cadena de suministro de software, se encuentra en el número 11. La otra, Fallos en la cadena de suministro de software, que ocupa el nº 3, es una ampliación de una categoría anterior, Componentes vulnerables y obsoletos (nº 6 en 2021), que ahora incluye una amplia gama de problemas de software. (Para los que lleven la cuenta, el control de acceso defectuoso sigue siendo el riesgo número 1).
Las condiciones excepcionales que constituyen la categoría más reciente pueden crear toda una serie de vulnerabilidades, desde fallos lógicos hasta desbordamientos, pasando por transacciones fraudulentas y problemas de memoria, temporización, autenticación, autorización y otros factores. Estos tipos de vulnerabilidades pueden afectar a la confidencialidad, disponibilidad e integridad de un sistema o de sus datos. Permiten a un atacante manipular la gestión defectuosa de errores de una aplicación, por ejemplo, para explotar la vulnerabilidad, dijo OWASP.
Un ejemplo de fallo en la gestión de condiciones inesperadas es cuando una aplicación identifica excepciones mientras se cargan archivos durante un ataque de denegación de servicio, pero luego no libera los recursos. Cuando esto ocurre, los recursos permanecen bloqueados o no disponibles, lo que provoca el agotamiento de los recursos. Si un atacante se inmiscuye en una transacción financiera de varios pasos, un sistema que no revierta la transacción una vez detectado un error podría permitir al atacante vaciar la cuenta del usuario. Si se detecta un error en mitad de una transacción, es muy importante "cerrar en caso de error", es decir, revertir toda la transacción y empezar de nuevo. Intentar recuperar una transacción a mitad de camino puede crear errores irrecuperables.
Fallo cerrado frente a fallo abierto
Entonces, ¿cuál es la diferencia entre estas dos acciones? Aclaremos:
Falla abierto: Si un sistema "falla abierto", sigue funcionando o permanece "abierto" cuando algo va mal. Esto es útil cuando mantener las cosas en funcionamiento es muy importante, pero puede ser arriesgado para la seguridad.
Fallo cerrado: Si un sistema "falla cerrado", se apaga automáticamente o se vuelve seguro cuando hay un problema. Esto es más seguro desde el punto de vista de la seguridad porque ayuda a evitar accesos no autorizados.
Errores imprevistos
La prevención de este tipo de riesgos empieza por planificar lo desconocido. Y eso implica ser capaz de detectar cualquier posible error del sistema cuando se produzca y tomar medidas para resolver el problema. Tienes que ser capaz de informar adecuadamente al usuario (sin revelar información crítica al atacante), registrar el evento y, si es necesario, emitir una alerta.
He aquí un ejemplo de la revelación de un error de consulta SQL, junto con la ruta de instalación del sitio, que puede utilizarse para identificar un punto de inyección:
Advertencia: odbc_fetch_array() espera que el parámetro /1 sea un recurso, dado booleano en D:\app\index_new.php en la línea 188
Lo ideal sería que un sistema dispusiera de un gestor de excepciones global para detectar errores que se pasan por alto, junto con funciones como herramientas de supervisión u observabilidad, o una función que detecte errores repetidos o patrones que podrían indicar un ataque en curso. Esto puede ayudar a defenderse contra los ataques que pretenden aprovecharse de cualquier debilidad que la empresa pueda tener en el manejo de errores.
Para una aplicación web Java estándar, por ejemplo, se puede configurar un gestor de errores global a nivel del descriptor de despliegue web.xml -en este caso, una configuración utilizada a partir de la especificación Servlet versión 2.5 y superiores-.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Este pequeño bloque de código indica a una aplicación web Java qué hacer cuando algo va mal entre bastidores. En lugar de mostrar a los usuarios un mensaje de error confuso o una pantalla en blanco, detecta silenciosamente el problema y los envía a una página de error personalizada. En este caso, esa página sería error.jsp.
Debido a que está configurado para manejar los tipos generales de java.lang.Exception, actúa como un manejador de errores maestro para toda la aplicación. Eso significa que no importa dónde se produzca un error, los usuarios serán redirigidos a la misma página de error amigable y consistente en lugar de ver detalles técnicos en bruto.
Prevenir lo inesperado
Lo ideal sería que las organizaciones trabajaran para evitar, en la medida de lo posible, que se produzcan situaciones excepcionales. Implantar límites de velocidad, cuotas de recursos, estrangulamiento y otros límites puede ayudar contra los ataques de denegación de servicio y de fuerza bruta, por ejemplo. Es posible que desee identificar errores repetidos idénticos e incluirlos sólo como estadísticas, para que no interfieran con el registro y la supervisión automatizados. Un sistema también debería incluir:
Validación estricta de la entrada de datos, para garantizar que sólo se introducen en el flujo de trabajo datos correctamente formados y depurados. Debe realizarse al principio del flujo de datos, idealmente en cuanto se reciben los datos.
Mejores prácticas de gestión de errores, para detectar los errores justo donde se producen. Deben tratarse con eficacia: Diga claramente a los usuarios que deben mantener un registro y enviar alertas si es necesario. Un gestor de errores global también es ideal para detectar cualquier error que se haya pasado por alto.
La seguridad general de las transacciones también es imprescindible. Siempre "a prueba de fallos": si algo va mal, deshaga toda la transacción. Y no intentes arreglar una transacción a medias: puede causar problemas mayores.
Registro, supervisión y alerta centralizados, junto con un gestor de excepciones global, que permite una investigación rápida de las incidencias y un proceso uniforme de gestión de los eventos, al tiempo que facilita el cumplimiento de los requisitos de conformidad.
Modelado de amenazas y/o revisión del diseño seguro, realizado en la fase de diseño de los proyectos.
Revisión del código o análisis estático, así como pruebas de estrés, rendimiento y penetración realizadas en el sistema final.
La gestión incorrecta de condiciones excepcionales puede ser una nueva categoría, pero implica algunos principios básicos de ciberseguridad y pone de relieve por qué las empresas deben estar preparadas para lo que no necesariamente están anticipando. Puede que no sepas qué forma tomarán las condiciones excepcionales, pero sabes que ocurrirán. La clave está en estar preparado para manejarlas todas de la misma manera, lo que facilitará la detección y respuesta a esas condiciones cuando surja lo inevitable.
Nota para los usuarios deSCW Trust Score™ :
A medida que actualizamos el contenido de nuestra Learning Platform para alinearlo con el estándar OWASP Top 10 2025, es posible que observe pequeños ajustes en la puntuación de confianza de sus desarrolladores Full Stack. Póngase en contacto con su representante de Customer Success si tiene alguna pregunta o necesita ayuda.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Con la publicación por parte de OWASP de su Top Ten 2025, las empresas tienen un par de nuevas categorías de riesgo a las que prestar especial atención, incluida una categoría completamente nueva que demuestra, de una vez por todas, que lo que no sabes puede hacerte daño.
La nueva categoría, Mishandling of Exceptional Conditions, describe lo que puede salir mal cuando las organizaciones no están preparadas para prevenir, detectar y responder a situaciones inusuales o impredecibles. Según OWASP, esta vulnerabilidad puede desencadenarse cuando una aplicación no evita que ocurra algo inusual, no identifica un problema cuando surge y/o responde mal o no responde en absoluto cuando se produce una situación inesperada.
La idea de que las empresas deben estar preparadas para lo que no vieron venir refleja la realidad de los sistemas actuales, altamente distribuidos e interconectados. Y no es que OWASP esté hablando de problemas desconocidos: el manejo incorrecto de circunstancias excepcionales contiene 24 enumeraciones de debilidades comunes (CWE). Es sólo que esas CWEs, que implican un manejo inadecuado de errores, fallos en la apertura de eventos, errores lógicos y otros escenarios, pueden ocurrir bajo condiciones anormales. Esto puede resultar, por ejemplo, de una validación de entrada inadecuada, errores de alto nivel en el manejo de funciones y el manejo inconsistente (o inexistente) de excepciones. Como afirma OWASP, "Cada vez que una aplicación no está segura de su siguiente instrucción, una condición excepcional ha sido mal manejada".
Esas circunstancias excepcionales pueden hacer que los sistemas caigan en un estado impredecible, provocando caídas del sistema, comportamientos inesperados y vulnerabilidades de seguridad duraderas. La clave para prevenir este tipo de interrupciones es, esencialmente, esperar lo peor y planificar estar preparado para cuando ocurra lo inesperado.
Circunstancias excepcionales y evolución del Top Ten
La composición de la lista cuatrienal de los diez riesgos más graves para la seguridad de las aplicaciones web se ha mantenido bastante estable a lo largo de los años, con algunas categorías que se desplazan por la lista y quizá una o dos incorporaciones cada cuatro años. La iteración de 2025 cuenta con dos nuevas entradas, entre las que se encuentra la Gestión incorrecta de condiciones excepcionales, en el número 10. La otra, Fallos en la cadena de suministro de software, se encuentra en el número 11. La otra, Fallos en la cadena de suministro de software, que ocupa el nº 3, es una ampliación de una categoría anterior, Componentes vulnerables y obsoletos (nº 6 en 2021), que ahora incluye una amplia gama de problemas de software. (Para los que lleven la cuenta, el control de acceso defectuoso sigue siendo el riesgo número 1).
Las condiciones excepcionales que constituyen la categoría más reciente pueden crear toda una serie de vulnerabilidades, desde fallos lógicos hasta desbordamientos, pasando por transacciones fraudulentas y problemas de memoria, temporización, autenticación, autorización y otros factores. Estos tipos de vulnerabilidades pueden afectar a la confidencialidad, disponibilidad e integridad de un sistema o de sus datos. Permiten a un atacante manipular la gestión defectuosa de errores de una aplicación, por ejemplo, para explotar la vulnerabilidad, dijo OWASP.
Un ejemplo de fallo en la gestión de condiciones inesperadas es cuando una aplicación identifica excepciones mientras se cargan archivos durante un ataque de denegación de servicio, pero luego no libera los recursos. Cuando esto ocurre, los recursos permanecen bloqueados o no disponibles, lo que provoca el agotamiento de los recursos. Si un atacante se inmiscuye en una transacción financiera de varios pasos, un sistema que no revierta la transacción una vez detectado un error podría permitir al atacante vaciar la cuenta del usuario. Si se detecta un error en mitad de una transacción, es muy importante "cerrar en caso de error", es decir, revertir toda la transacción y empezar de nuevo. Intentar recuperar una transacción a mitad de camino puede crear errores irrecuperables.
Fallo cerrado frente a fallo abierto
Entonces, ¿cuál es la diferencia entre estas dos acciones? Aclaremos:
Falla abierto: Si un sistema "falla abierto", sigue funcionando o permanece "abierto" cuando algo va mal. Esto es útil cuando mantener las cosas en funcionamiento es muy importante, pero puede ser arriesgado para la seguridad.
Fallo cerrado: Si un sistema "falla cerrado", se apaga automáticamente o se vuelve seguro cuando hay un problema. Esto es más seguro desde el punto de vista de la seguridad porque ayuda a evitar accesos no autorizados.
Errores imprevistos
La prevención de este tipo de riesgos empieza por planificar lo desconocido. Y eso implica ser capaz de detectar cualquier posible error del sistema cuando se produzca y tomar medidas para resolver el problema. Tienes que ser capaz de informar adecuadamente al usuario (sin revelar información crítica al atacante), registrar el evento y, si es necesario, emitir una alerta.
He aquí un ejemplo de la revelación de un error de consulta SQL, junto con la ruta de instalación del sitio, que puede utilizarse para identificar un punto de inyección:
Advertencia: odbc_fetch_array() espera que el parámetro /1 sea un recurso, dado booleano en D:\app\index_new.php en la línea 188
Lo ideal sería que un sistema dispusiera de un gestor de excepciones global para detectar errores que se pasan por alto, junto con funciones como herramientas de supervisión u observabilidad, o una función que detecte errores repetidos o patrones que podrían indicar un ataque en curso. Esto puede ayudar a defenderse contra los ataques que pretenden aprovecharse de cualquier debilidad que la empresa pueda tener en el manejo de errores.
Para una aplicación web Java estándar, por ejemplo, se puede configurar un gestor de errores global a nivel del descriptor de despliegue web.xml -en este caso, una configuración utilizada a partir de la especificación Servlet versión 2.5 y superiores-.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Este pequeño bloque de código indica a una aplicación web Java qué hacer cuando algo va mal entre bastidores. En lugar de mostrar a los usuarios un mensaje de error confuso o una pantalla en blanco, detecta silenciosamente el problema y los envía a una página de error personalizada. En este caso, esa página sería error.jsp.
Debido a que está configurado para manejar los tipos generales de java.lang.Exception, actúa como un manejador de errores maestro para toda la aplicación. Eso significa que no importa dónde se produzca un error, los usuarios serán redirigidos a la misma página de error amigable y consistente en lugar de ver detalles técnicos en bruto.
Prevenir lo inesperado
Lo ideal sería que las organizaciones trabajaran para evitar, en la medida de lo posible, que se produzcan situaciones excepcionales. Implantar límites de velocidad, cuotas de recursos, estrangulamiento y otros límites puede ayudar contra los ataques de denegación de servicio y de fuerza bruta, por ejemplo. Es posible que desee identificar errores repetidos idénticos e incluirlos sólo como estadísticas, para que no interfieran con el registro y la supervisión automatizados. Un sistema también debería incluir:
Validación estricta de la entrada de datos, para garantizar que sólo se introducen en el flujo de trabajo datos correctamente formados y depurados. Debe realizarse al principio del flujo de datos, idealmente en cuanto se reciben los datos.
Mejores prácticas de gestión de errores, para detectar los errores justo donde se producen. Deben tratarse con eficacia: Diga claramente a los usuarios que deben mantener un registro y enviar alertas si es necesario. Un gestor de errores global también es ideal para detectar cualquier error que se haya pasado por alto.
La seguridad general de las transacciones también es imprescindible. Siempre "a prueba de fallos": si algo va mal, deshaga toda la transacción. Y no intentes arreglar una transacción a medias: puede causar problemas mayores.
Registro, supervisión y alerta centralizados, junto con un gestor de excepciones global, que permite una investigación rápida de las incidencias y un proceso uniforme de gestión de los eventos, al tiempo que facilita el cumplimiento de los requisitos de conformidad.
Modelado de amenazas y/o revisión del diseño seguro, realizado en la fase de diseño de los proyectos.
Revisión del código o análisis estático, así como pruebas de estrés, rendimiento y penetración realizadas en el sistema final.
La gestión incorrecta de condiciones excepcionales puede ser una nueva categoría, pero implica algunos principios básicos de ciberseguridad y pone de relieve por qué las empresas deben estar preparadas para lo que no necesariamente están anticipando. Puede que no sepas qué forma tomarán las condiciones excepcionales, pero sabes que ocurrirán. La clave está en estar preparado para manejarlas todas de la misma manera, lo que facilitará la detección y respuesta a esas condiciones cuando surja lo inevitable.
Nota para los usuarios deSCW Trust Score™ :
A medida que actualizamos el contenido de nuestra Learning Platform para alinearlo con el estándar OWASP Top 10 2025, es posible que observe pequeños ajustes en la puntuación de confianza de sus desarrolladores Full Stack. Póngase en contacto con su representante de Customer Success si tiene alguna pregunta o necesita ayuda.
Índice
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
.png)
.png)
El poder de la marca en AppSec DevSec DevSecOps (¿Qué hay en un acrónimo?)
En AppSec, el impacto duradero de un programa exige algo más que tecnología: necesita una marca fuerte. Una identidad poderosa garantiza que sus iniciativas resuenen e impulsen un compromiso sostenido dentro de su comunidad de desarrolladores.
Recursos para empezar
OWASP Top 10 2025: Fallos en la cadena de suministro de software
OWASP Top 10 2025 sitúa los fallos de la cadena de suministro de software en el puesto número 3. Mitigue este riesgo de alto impacto mediante SBOM estrictos, seguimiento de dependencias y refuerzo de la canalización CI/CD.
¡Adopte RÁPIDAMENTE la IA Agéntica en el Desarrollo de Software! (Spoiler: Probablemente no deberías.)
¿Va el mundo de la ciberseguridad demasiado rápido con la IA agéntica? El futuro de la seguridad de la IA ya está aquí, y es hora de que los expertos pasen de la reflexión a la realidad.
Resolver la crisis de visibilidad: cómo Trust Agent salva la distancia entre aprendizaje y código
Trust Agent de Secure Code Warrior resuelve la crisis de la codificación segura, validando la competencia de los desarrolladores en cada commit. Descubre a todos los colaboradores y automatiza la gobernanza en su flujo de trabajo de desarrollo.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
