北京
只在一台手机上运行的安全检查，理论上都可以在这台手机上被修补绕过。Codename One 推出的 App Shield 应用证明层，把最终判断权交还给服务器：受保护请求会附带一个短期有效、经服务器验证的证明令牌。
App Shield 的运作逻辑并不复杂。它先向 Apple App Attest 或 Google Play Integrity 索取硬件背书声明，再通过 Codename One 服务核验这份声明，最后向应用签发一个短期有效的 ES256 令牌。后端在执行业务操作前先验令牌，令牌不过关，请求就到不了敏感逻辑面前。
为什么要多此一举？
本地校验存在一个天然弱点：攻击者拿到的是一份他可以随意改动的客户端。被修改过的应用可以强制让 isDeviceCompromised() 返回 false，但这没有用——它无法铸造一枚由服务器信任的密钥签出的合法令牌。
这也是 App Shield 在架构上刻意做出的分工：客户端负责上报它看到的设备状态，Codename One 服务负责评估证明和政策，你的后端 API 决定是否放行一笔转账、返回一份个人数据、要求二次认证或者干脆拒绝调用。
令牌本身做了哪些限制？
nonce 机制可以防止截获的平台声明被当成永久凭证反复使用。令牌会标明预期的包名和平台，携带策略决策结果，还可以绑定到某一个具体请求体上。服务端还能在证明中附加来自 root、越狱、钩子框架、模拟器、调试器、重打包和不可信无障碍服务等渠道的信号。
触发开关
启用 App Shield 只需在 codenameone_settings.properties 中打开开关：
codename1.arg.shield.enabled=true
随后注册需要接收令牌的主机：
AppShield.init(new ShieldConfig() // 没有令牌的请求不允许离开设备。 .protect("api.mybank.example", HostPolicy.ENFORCED) // 其他子域名在可用时会加上令牌。 .protect("*.mybank.example", HostPolicy.PROTECTED));ENFORCED 策略意味着缺少令牌的请求根本无法出网；PROTECTED 策略则相对宽松，有令牌就带上。两种策略可以按域名粒度灵活组合。
银行客户早就按这个标准在用了
Codename One 目前已经服务多家银行客户。高标准的安全需求塑造了这个框架多年，Java 在这一环上尤为关键——安全团队能拿到成熟的分析工具、熟悉的类型系统，以及一份需要审阅的应用代码库，而不是 iOS 和 Android 各看一遍。
需要强调的是，Java 本身不构成安全边界。构建流水线确实会给攻击者增加一些阻力，但真正决定安全的仍是服务器端的验证闭环。
App Shield 的完整链路由三部分组成：平台证明提供商、Codename One 验证服务和你的后端。移动端的安全报告天然不可全信——但如果它背后有硬件背书，且决策点落在服务器上，情况就完全不同了。
顺带一提，作者目前正在泰国被迫休假。GitHub Actions 的宕机让本周开发进度慢了不少，多个 PR 仍在进行中，团队没有选择仓促合并。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
