OWASP 十大新风险类别：期待意外
随着 OWASP 发布2025 年十大风险，企业需要特别关注几个新的风险类别，其中包括一个全新的类别，它一劳永逸地证明，你不知道的东西确实会伤害你。
新类别 "异常情况处理不当"概述了当企业没有做好预防、检测和应对异常或不可预测情况的准备时可能出现的问题。根据 OWASP 的说法，当应用程序无法防止异常情况发生、无法在问题出现时识别问题和/或在意外情况出现时反应迟钝或根本没有反应时，就会触发该漏洞。
企业需要为他们没有预见到的事情做好准备，这一观点反映了当今高度分布式、互联系统的现实。OWASP 并不是在谈论闻所未闻的问题--异常情况处理不当包含 24 个常见弱点枚举（CWE）。这些 CWE 涉及错误处理不当、无法打开事件、逻辑错误和其他情况，可能会在异常情况下发生。例如，输入验证不充分、处理函数中的高级错误以及异常处理不一致（或不存在）都可能导致这种情况。正如 OWASP 所说："任何时候，只要应用程序不确定其下一条指令，就是异常情况处理不当"。
这些特殊情况可能导致系统陷入不可预测的状态，造成系统崩溃、意外行为和长期安全漏洞。防止此类中断的关键在于，从根本上说，要做好最坏的打算，并制定计划，为意外情况的发生做好准备。
特殊情况与十佳评选的演变
四年一度的 "网络应用程序最严重安全风险十佳榜单 "多年来一直比较稳定，一些类别在榜单上有所变动，每四年可能会增加一两个类别。2025 年的榜单新增了两个类别，其中 "异常情况处理不当 "排在第 10 位。另一个是软件供应链故障，排在第 3 位，这是对早先的一个类别 "易受攻击和过时的组件"（2021 年排在第 6 位）的扩充，现在包括了广泛的软件危害。(对于那些记分的人来说，"访问控制失灵 "仍然是排名第一的风险）。
构成最新类别的特殊条件可产生大量漏洞，从逻辑错误到溢出，从欺诈交易到内存、定时、验证、授权和其他因素的问题。这些类型的漏洞会影响系统或其数据的保密性、可用性和完整性。OWASP 说，这些漏洞允许攻击者利用应用程序错误处理等缺陷来利用漏洞。
无法处理意外情况的一个例子是，当应用程序在拒绝服务攻击期间上传文件时发现异常，但随后却无法释放资源。当发生这种情况时，资源仍然被锁定或不可用，从而导致资源耗尽。如果攻击者入侵多步骤金融交易，一旦检测到错误而不回滚交易，系统就会允许攻击者耗尽用户的账户。如果在交易的中途检测到错误，"失败关闭 "是非常重要的，即回滚整个交易并重新开始。试图在中途恢复交易可能会造成无法恢复的错误。
故障关闭与故障打开
那么，这两种行为有什么区别呢？让我们来澄清一下：
故障开放：如果系统 "故障开放"，它就会继续运行，或在出错时保持 "开放"。当保持运行非常重要时，这很有用，但对安全而言可能有风险。
故障关闭：如果系统 "故障关闭"，当出现问题时，系统会自动关闭或变得安全。从安全角度看，这样更安全，因为它有助于防止未经授权的访问。
处理意外错误
要预防此类风险，首先要为未知情况做好计划。这就需要能够在发生任何可能的系统错误时进行检测，并采取措施解决问题。您需要能够适当地通知用户（不向攻击者透露关键信息）、记录事件，并在必要时发出警报。
下面是一个披露 SQL 查询错误以及网站安装路径的示例，可用于识别注入点：
Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:app\index_new.php on line 188
理想情况下，系统应具备全局异常处理程序，以捕捉被忽视的错误，同时具备监控或可观察性工具等功能，或者具备检测重复错误或可能标志着持续攻击的模式的功能。这有助于抵御旨在利用企业在处理错误方面可能存在的弱点的攻击。
例如，对于标准的 Java 网络应用程序，可以在 web.xml 部署描述符级别配置全局错误处理程序--本例中使用的是 Servlet 规范 2.5 及以上版本中的配置。
<?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>
当 Java 网络应用程序在幕后出错时，这一小块代码会告诉它该怎么做。它不会向用户显示混乱的错误信息或空白屏幕，而是静静地捕捉问题，并将用户发送到自定义错误页面。在本例中，该页面就是 error.jsp。
由于它被设置为处理一般的 java.lang.Exception 类型，因此它充当了整个应用程序的主错误处理程序。这意味着无论错误发生在哪里，用户都会被重定向到同一个友好、一致的错误页面，而不是看到原始的技术细节。
预防意外
在理想情况下，企业应尽可能防止特殊情况的发生。例如，实施速率限制、资源配额、节流和其他限制措施，有助于抵御拒绝服务和暴力攻击。您可能需要识别重复出现的相同错误，并将其作为统计数据，这样就不会干扰自动日志记录和监控。系统还应包括
严格的输入验证， 确保只有格式正确、经过消毒的数据才能进入工作流。它应在数据流的早期进行，最好是在收到任何数据后立即进行。
错误处理最佳实践，及时发现错误。应高效处理这些错误：明确告诉用户必须保留日志，并在必要时发送警报。全局错误处理程序也是捕捉任何遗漏的理想工具。
一般事务安全也是必须的。一定要 "失败关闭"：如果出了问题，回滚整个事务。不要试图中途修复事务，这会导致更大的问题。
集中式日志记录、监控和警报，以及全局异常处理程序，可快速调查事件并统一事件处理流程，同时还能更轻松地满足合规要求。
在项目设计阶段进行威胁建模和/或安全设计审查。
对最终系统进行代码审查或静态分析，以及压力、性能和渗透测试。
特殊情况处理不当可能是一个新的类别，但它涉及网络安全的一些基本原则，并强调了为什么企业需要为他们不一定能预料到的情况做好准备。你可能不知道特殊情况会以什么形式出现，但你知道它们会发生。关键是要做好准备，以同样的方式处理所有这些情况，这样才能在不可避免的情况出现时更容易发现和应对这些情况。
SCW Trust Score™ 用户须知 ：
随着我们更新Learning Platform 内容，使其与 OWASP Top 10 2025 标准保持一致，您可能会发现全栈开发人员的信任分数会有细微调整。如果您有任何疑问或需要支持，请联系您的客户成功代表。
.png)
随着 OWASP 发布2025 年十大风险，企业需要特别关注几个新的风险类别，其中包括一个全新的类别，它一劳永逸地证明，你不知道的东西确实会伤害你。
新类别 "异常情况处理不当"概述了当企业没有做好预防、检测和应对异常或不可预测情况的准备时可能出现的问题。根据 OWASP 的说法，当应用程序无法防止异常情况发生、无法在问题出现时识别问题和/或在意外情况出现时反应迟钝或根本没有反应时，就会触发该漏洞。
企业需要为他们没有预见到的事情做好准备，这一观点反映了当今高度分布式、互联系统的现实。OWASP 并不是在谈论闻所未闻的问题--异常情况处理不当包含 24 个常见弱点枚举（CWE）。这些 CWE 涉及错误处理不当、无法打开事件、逻辑错误和其他情况，可能会在异常情况下发生。例如，输入验证不充分、处理函数中的高级错误以及异常处理不一致（或不存在）都可能导致这种情况。正如 OWASP 所说："任何时候，只要应用程序不确定其下一条指令，就是异常情况处理不当"。
这些特殊情况可能导致系统陷入不可预测的状态，造成系统崩溃、意外行为和长期安全漏洞。防止此类中断的关键在于，从根本上说，要做好最坏的打算，并制定计划，为意外情况的发生做好准备。
特殊情况与十佳评选的演变
四年一度的 "网络应用程序最严重安全风险十佳榜单 "多年来一直比较稳定，一些类别在榜单上有所变动，每四年可能会增加一两个类别。2025 年的榜单新增了两个类别，其中 "异常情况处理不当 "排在第 10 位。另一个是软件供应链故障，排在第 3 位，这是对早先的一个类别 "易受攻击和过时的组件"（2021 年排在第 6 位）的扩充，现在包括了广泛的软件危害。(对于那些记分的人来说，"访问控制失灵 "仍然是排名第一的风险）。
构成最新类别的特殊条件可产生大量漏洞，从逻辑错误到溢出，从欺诈交易到内存、定时、验证、授权和其他因素的问题。这些类型的漏洞会影响系统或其数据的保密性、可用性和完整性。OWASP 说，这些漏洞允许攻击者利用应用程序错误处理等缺陷来利用漏洞。
无法处理意外情况的一个例子是，当应用程序在拒绝服务攻击期间上传文件时发现异常，但随后却无法释放资源。当发生这种情况时，资源仍然被锁定或不可用，从而导致资源耗尽。如果攻击者入侵多步骤金融交易，一旦检测到错误而不回滚交易，系统就会允许攻击者耗尽用户的账户。如果在交易的中途检测到错误，"失败关闭 "是非常重要的，即回滚整个交易并重新开始。试图在中途恢复交易可能会造成无法恢复的错误。
故障关闭与故障打开
那么，这两种行为有什么区别呢？让我们来澄清一下：
故障开放：如果系统 "故障开放"，它就会继续运行，或在出错时保持 "开放"。当保持运行非常重要时，这很有用，但对安全而言可能有风险。
故障关闭：如果系统 "故障关闭"，当出现问题时，系统会自动关闭或变得安全。从安全角度看，这样更安全，因为它有助于防止未经授权的访问。
处理意外错误
要预防此类风险，首先要为未知情况做好计划。这就需要能够在发生任何可能的系统错误时进行检测，并采取措施解决问题。您需要能够适当地通知用户（不向攻击者透露关键信息）、记录事件，并在必要时发出警报。
下面是一个披露 SQL 查询错误以及网站安装路径的示例，可用于识别注入点：
Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:app\index_new.php on line 188
理想情况下，系统应具备全局异常处理程序，以捕捉被忽视的错误，同时具备监控或可观察性工具等功能，或者具备检测重复错误或可能标志着持续攻击的模式的功能。这有助于抵御旨在利用企业在处理错误方面可能存在的弱点的攻击。
例如，对于标准的 Java 网络应用程序，可以在 web.xml 部署描述符级别配置全局错误处理程序--本例中使用的是 Servlet 规范 2.5 及以上版本中的配置。
<?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>
当 Java 网络应用程序在幕后出错时，这一小块代码会告诉它该怎么做。它不会向用户显示混乱的错误信息或空白屏幕，而是静静地捕捉问题，并将用户发送到自定义错误页面。在本例中，该页面就是 error.jsp。
由于它被设置为处理一般的 java.lang.Exception 类型，因此它充当了整个应用程序的主错误处理程序。这意味着无论错误发生在哪里，用户都会被重定向到同一个友好、一致的错误页面，而不是看到原始的技术细节。
预防意外
在理想情况下，企业应尽可能防止特殊情况的发生。例如，实施速率限制、资源配额、节流和其他限制措施，有助于抵御拒绝服务和暴力攻击。您可能需要识别重复出现的相同错误，并将其作为统计数据，这样就不会干扰自动日志记录和监控。系统还应包括
严格的输入验证， 确保只有格式正确、经过消毒的数据才能进入工作流。它应在数据流的早期进行，最好是在收到任何数据后立即进行。
错误处理最佳实践，及时发现错误。应高效处理这些错误：明确告诉用户必须保留日志，并在必要时发送警报。全局错误处理程序也是捕捉任何遗漏的理想工具。
一般事务安全也是必须的。一定要 "失败关闭"：如果出了问题，回滚整个事务。不要试图中途修复事务，这会导致更大的问题。
集中式日志记录、监控和警报，以及全局异常处理程序，可快速调查事件并统一事件处理流程，同时还能更轻松地满足合规要求。
在项目设计阶段进行威胁建模和/或安全设计审查。
对最终系统进行代码审查或静态分析，以及压力、性能和渗透测试。
特殊情况处理不当可能是一个新的类别，但它涉及网络安全的一些基本原则，并强调了为什么企业需要为他们不一定能预料到的情况做好准备。你可能不知道特殊情况会以什么形式出现，但你知道它们会发生。关键是要做好准备，以同样的方式处理所有这些情况，这样才能在不可避免的情况出现时更容易发现和应对这些情况。
SCW Trust Score™ 用户须知 ：
随着我们更新Learning Platform 内容，使其与 OWASP Top 10 2025 标准保持一致，您可能会发现全栈开发人员的信任分数会有细微调整。如果您有任何疑问或需要支持，请联系您的客户成功代表。
随着 OWASP 发布2025 年十大风险，企业需要特别关注几个新的风险类别，其中包括一个全新的类别，它一劳永逸地证明，你不知道的东西确实会伤害你。
新类别 "异常情况处理不当"概述了当企业没有做好预防、检测和应对异常或不可预测情况的准备时可能出现的问题。根据 OWASP 的说法，当应用程序无法防止异常情况发生、无法在问题出现时识别问题和/或在意外情况出现时反应迟钝或根本没有反应时，就会触发该漏洞。
企业需要为他们没有预见到的事情做好准备，这一观点反映了当今高度分布式、互联系统的现实。OWASP 并不是在谈论闻所未闻的问题--异常情况处理不当包含 24 个常见弱点枚举（CWE）。这些 CWE 涉及错误处理不当、无法打开事件、逻辑错误和其他情况，可能会在异常情况下发生。例如，输入验证不充分、处理函数中的高级错误以及异常处理不一致（或不存在）都可能导致这种情况。正如 OWASP 所说："任何时候，只要应用程序不确定其下一条指令，就是异常情况处理不当"。
这些特殊情况可能导致系统陷入不可预测的状态，造成系统崩溃、意外行为和长期安全漏洞。防止此类中断的关键在于，从根本上说，要做好最坏的打算，并制定计划，为意外情况的发生做好准备。
特殊情况与十佳评选的演变
四年一度的 "网络应用程序最严重安全风险十佳榜单 "多年来一直比较稳定，一些类别在榜单上有所变动，每四年可能会增加一两个类别。2025 年的榜单新增了两个类别，其中 "异常情况处理不当 "排在第 10 位。另一个是软件供应链故障，排在第 3 位，这是对早先的一个类别 "易受攻击和过时的组件"（2021 年排在第 6 位）的扩充，现在包括了广泛的软件危害。(对于那些记分的人来说，"访问控制失灵 "仍然是排名第一的风险）。
构成最新类别的特殊条件可产生大量漏洞，从逻辑错误到溢出，从欺诈交易到内存、定时、验证、授权和其他因素的问题。这些类型的漏洞会影响系统或其数据的保密性、可用性和完整性。OWASP 说，这些漏洞允许攻击者利用应用程序错误处理等缺陷来利用漏洞。
无法处理意外情况的一个例子是，当应用程序在拒绝服务攻击期间上传文件时发现异常，但随后却无法释放资源。当发生这种情况时，资源仍然被锁定或不可用，从而导致资源耗尽。如果攻击者入侵多步骤金融交易，一旦检测到错误而不回滚交易，系统就会允许攻击者耗尽用户的账户。如果在交易的中途检测到错误，"失败关闭 "是非常重要的，即回滚整个交易并重新开始。试图在中途恢复交易可能会造成无法恢复的错误。
故障关闭与故障打开
那么，这两种行为有什么区别呢？让我们来澄清一下：
故障开放：如果系统 "故障开放"，它就会继续运行，或在出错时保持 "开放"。当保持运行非常重要时，这很有用，但对安全而言可能有风险。
故障关闭：如果系统 "故障关闭"，当出现问题时，系统会自动关闭或变得安全。从安全角度看，这样更安全，因为它有助于防止未经授权的访问。
处理意外错误
要预防此类风险，首先要为未知情况做好计划。这就需要能够在发生任何可能的系统错误时进行检测，并采取措施解决问题。您需要能够适当地通知用户（不向攻击者透露关键信息）、记录事件，并在必要时发出警报。
下面是一个披露 SQL 查询错误以及网站安装路径的示例，可用于识别注入点：
Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:app\index_new.php on line 188
理想情况下，系统应具备全局异常处理程序，以捕捉被忽视的错误，同时具备监控或可观察性工具等功能，或者具备检测重复错误或可能标志着持续攻击的模式的功能。这有助于抵御旨在利用企业在处理错误方面可能存在的弱点的攻击。
例如，对于标准的 Java 网络应用程序，可以在 web.xml 部署描述符级别配置全局错误处理程序--本例中使用的是 Servlet 规范 2.5 及以上版本中的配置。
<?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>
当 Java 网络应用程序在幕后出错时，这一小块代码会告诉它该怎么做。它不会向用户显示混乱的错误信息或空白屏幕，而是静静地捕捉问题，并将用户发送到自定义错误页面。在本例中，该页面就是 error.jsp。
由于它被设置为处理一般的 java.lang.Exception 类型，因此它充当了整个应用程序的主错误处理程序。这意味着无论错误发生在哪里，用户都会被重定向到同一个友好、一致的错误页面，而不是看到原始的技术细节。
预防意外
在理想情况下，企业应尽可能防止特殊情况的发生。例如，实施速率限制、资源配额、节流和其他限制措施，有助于抵御拒绝服务和暴力攻击。您可能需要识别重复出现的相同错误，并将其作为统计数据，这样就不会干扰自动日志记录和监控。系统还应包括
严格的输入验证， 确保只有格式正确、经过消毒的数据才能进入工作流。它应在数据流的早期进行，最好是在收到任何数据后立即进行。
错误处理最佳实践，及时发现错误。应高效处理这些错误：明确告诉用户必须保留日志，并在必要时发送警报。全局错误处理程序也是捕捉任何遗漏的理想工具。
一般事务安全也是必须的。一定要 "失败关闭"：如果出了问题，回滚整个事务。不要试图中途修复事务，这会导致更大的问题。
集中式日志记录、监控和警报，以及全局异常处理程序，可快速调查事件并统一事件处理流程，同时还能更轻松地满足合规要求。
在项目设计阶段进行威胁建模和/或安全设计审查。
对最终系统进行代码审查或静态分析，以及压力、性能和渗透测试。
特殊情况处理不当可能是一个新的类别，但它涉及网络安全的一些基本原则，并强调了为什么企业需要为他们不一定能预料到的情况做好准备。你可能不知道特殊情况会以什么形式出现，但你知道它们会发生。关键是要做好准备，以同样的方式处理所有这些情况，这样才能在不可避免的情况出现时更容易发现和应对这些情况。
SCW Trust Score™ 用户须知 ：
随着我们更新Learning Platform 内容，使其与 OWASP Top 10 2025 标准保持一致，您可能会发现全栈开发人员的信任分数会有细微调整。如果您有任何疑问或需要支持，请联系您的客户成功代表。
随着 OWASP 发布2025 年十大风险，企业需要特别关注几个新的风险类别，其中包括一个全新的类别，它一劳永逸地证明，你不知道的东西确实会伤害你。
新类别 "异常情况处理不当"概述了当企业没有做好预防、检测和应对异常或不可预测情况的准备时可能出现的问题。根据 OWASP 的说法，当应用程序无法防止异常情况发生、无法在问题出现时识别问题和/或在意外情况出现时反应迟钝或根本没有反应时，就会触发该漏洞。
企业需要为他们没有预见到的事情做好准备，这一观点反映了当今高度分布式、互联系统的现实。OWASP 并不是在谈论闻所未闻的问题--异常情况处理不当包含 24 个常见弱点枚举（CWE）。这些 CWE 涉及错误处理不当、无法打开事件、逻辑错误和其他情况，可能会在异常情况下发生。例如，输入验证不充分、处理函数中的高级错误以及异常处理不一致（或不存在）都可能导致这种情况。正如 OWASP 所说："任何时候，只要应用程序不确定其下一条指令，就是异常情况处理不当"。
这些特殊情况可能导致系统陷入不可预测的状态，造成系统崩溃、意外行为和长期安全漏洞。防止此类中断的关键在于，从根本上说，要做好最坏的打算，并制定计划，为意外情况的发生做好准备。
特殊情况与十佳评选的演变
四年一度的 "网络应用程序最严重安全风险十佳榜单 "多年来一直比较稳定，一些类别在榜单上有所变动，每四年可能会增加一两个类别。2025 年的榜单新增了两个类别，其中 "异常情况处理不当 "排在第 10 位。另一个是软件供应链故障，排在第 3 位，这是对早先的一个类别 "易受攻击和过时的组件"（2021 年排在第 6 位）的扩充，现在包括了广泛的软件危害。(对于那些记分的人来说，"访问控制失灵 "仍然是排名第一的风险）。
构成最新类别的特殊条件可产生大量漏洞，从逻辑错误到溢出，从欺诈交易到内存、定时、验证、授权和其他因素的问题。这些类型的漏洞会影响系统或其数据的保密性、可用性和完整性。OWASP 说，这些漏洞允许攻击者利用应用程序错误处理等缺陷来利用漏洞。
无法处理意外情况的一个例子是，当应用程序在拒绝服务攻击期间上传文件时发现异常，但随后却无法释放资源。当发生这种情况时，资源仍然被锁定或不可用，从而导致资源耗尽。如果攻击者入侵多步骤金融交易，一旦检测到错误而不回滚交易，系统就会允许攻击者耗尽用户的账户。如果在交易的中途检测到错误，"失败关闭 "是非常重要的，即回滚整个交易并重新开始。试图在中途恢复交易可能会造成无法恢复的错误。
故障关闭与故障打开
那么，这两种行为有什么区别呢？让我们来澄清一下：
故障开放：如果系统 "故障开放"，它就会继续运行，或在出错时保持 "开放"。当保持运行非常重要时，这很有用，但对安全而言可能有风险。
故障关闭：如果系统 "故障关闭"，当出现问题时，系统会自动关闭或变得安全。从安全角度看，这样更安全，因为它有助于防止未经授权的访问。
处理意外错误
要预防此类风险，首先要为未知情况做好计划。这就需要能够在发生任何可能的系统错误时进行检测，并采取措施解决问题。您需要能够适当地通知用户（不向攻击者透露关键信息）、记录事件，并在必要时发出警报。
下面是一个披露 SQL 查询错误以及网站安装路径的示例，可用于识别注入点：
Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:app\index_new.php on line 188
理想情况下，系统应具备全局异常处理程序，以捕捉被忽视的错误，同时具备监控或可观察性工具等功能，或者具备检测重复错误或可能标志着持续攻击的模式的功能。这有助于抵御旨在利用企业在处理错误方面可能存在的弱点的攻击。
例如，对于标准的 Java 网络应用程序，可以在 web.xml 部署描述符级别配置全局错误处理程序--本例中使用的是 Servlet 规范 2.5 及以上版本中的配置。
<?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>
当 Java 网络应用程序在幕后出错时，这一小块代码会告诉它该怎么做。它不会向用户显示混乱的错误信息或空白屏幕，而是静静地捕捉问题，并将用户发送到自定义错误页面。在本例中，该页面就是 error.jsp。
由于它被设置为处理一般的 java.lang.Exception 类型，因此它充当了整个应用程序的主错误处理程序。这意味着无论错误发生在哪里，用户都会被重定向到同一个友好、一致的错误页面，而不是看到原始的技术细节。
预防意外
在理想情况下，企业应尽可能防止特殊情况的发生。例如，实施速率限制、资源配额、节流和其他限制措施，有助于抵御拒绝服务和暴力攻击。您可能需要识别重复出现的相同错误，并将其作为统计数据，这样就不会干扰自动日志记录和监控。系统还应包括
严格的输入验证， 确保只有格式正确、经过消毒的数据才能进入工作流。它应在数据流的早期进行，最好是在收到任何数据后立即进行。
错误处理最佳实践，及时发现错误。应高效处理这些错误：明确告诉用户必须保留日志，并在必要时发送警报。全局错误处理程序也是捕捉任何遗漏的理想工具。
一般事务安全也是必须的。一定要 "失败关闭"：如果出了问题，回滚整个事务。不要试图中途修复事务，这会导致更大的问题。
集中式日志记录、监控和警报，以及全局异常处理程序，可快速调查事件并统一事件处理流程，同时还能更轻松地满足合规要求。
在项目设计阶段进行威胁建模和/或安全设计审查。
对最终系统进行代码审查或静态分析，以及压力、性能和渗透测试。
特殊情况处理不当可能是一个新的类别，但它涉及网络安全的一些基本原则，并强调了为什么企业需要为他们不一定能预料到的情况做好准备。你可能不知道特殊情况会以什么形式出现，但你知道它们会发生。关键是要做好准备，以同样的方式处理所有这些情况，这样才能在不可避免的情况出现时更容易发现和应对这些情况。
SCW Trust Score™ 用户须知 ：
随着我们更新Learning Platform 内容，使其与 OWASP Top 10 2025 标准保持一致，您可能会发现全栈开发人员的信任分数会有细微调整。如果您有任何疑问或需要支持，请联系您的客户成功代表。
.png)
.png)
