企业里的一个 SAP Gateway 服务真正危险的地方，往往不是某一行特别复杂的 ABAP 代码，而是开发团队不经意间接受了一个错误前提，认为来自 SAP Fiori、SAPUI5、移动端或者另一个 SAP 系统的数据已经在前面检查过，因此到了 OData 服务这一层可以直接使用。这类想法在内部系统里尤其常见。一个销售订单创建服务收到SalesOrganization、OrderType、Material、Quantity、Currency等字段，前端页面已经做了必填校验，下拉框也限制了销售组织和订单类型，看起来似乎没有必要在后端再次检查。可一旦请求不再来自正常的 SAPUI5 页面，而是来自 Postman、自定义程序、被篡改的 HTTP 请求，甚至未来来自一个能够调用业务 API 的 MCP Server，这些所谓的前端约束瞬间就不存在了。SAP Gateway 本身就把应用请求的检查和校验视为服务安全的一部分，它允许应用对技术上下文和业务上下文进行验证，而 SAP 的安全编程文档也把输入校验列为安全架构中的基础环节。缺少这层保护后，问题可能从普通的业务数据错误一路升级到文件路径穿越、SQL Injection、完整性破坏甚至系统可用性问题。因此，在 SAP ABAP 世界里讨论输入校验，不能只理解成几条IF语句。更合理的思路，是让平台类型系统、ABAP Dictionary、业务语义以及应用级安全检查共同工作，把不可信输入逐层压缩到一个足够小、足够明确的合法空间里。强类型其实就是第一道输入防火墙