Security architecture

安全不是一句承诺，而是一条可以核验的链路

Arcveil 将前端挑战、一次性 token、服务端二次校验、风险日志与 SDK 完整性放在同一条安全边界中。这里说明平台当前提供的控制，也说明客户仍需承担的接入责任。

当前可公开核验

SDK manifestSHA256 / SRI固定版本下载公开证明接口

Core controls

四个基础控制面

产品安全建立在明确的职责边界上，不把前端“验证成功”误当成业务已经安全。

前端只获取一次性 token。登录、注册、下单或提交内容前，业务后端必须调用 second-verify 并根据结果决定是否放行。

验证链路处理交互轨迹、环境摘要、结果与排障信息；不应传入密码、证件号或业务表单正文。

稳定入口用于兼容更新；固定版本、SHA256、SRI、可读源码和自托管选项用于审计与变更控制。

Trace、验证结果、失败原因与风险等级用于定位配置错误、异常请求和正常用户误伤。

Request path

每一层只承担自己的职责，任何一层都不能单独替代业务后端的最终判断。

1业务前端按场景触发挑战，不保存 App Secret。

2Arcveil SDK完成挑战并返回短时、一次性 token。

3业务后端携带服务端凭据消费 token，校验应用和有效期。

4业务系统根据二验结果与自身权限规则决定放行。

Shared responsibility

控制项	Arcveil 负责	客户负责
验证挑战	生成挑战、校验交互并返回 token。	选择适合业务场景的验证方式与降级策略。
业务放行	提供服务端二次校验接口和结果。	在后端消费 token，并结合账号、权限和业务规则做最终决定。
凭据	区分公开 App ID 与服务端 App Secret。	妥善保管 Secret、限制访问权限，并在泄露后及时轮换。
浏览器安全	提供固定 SDK、哈希、SRI 和自托管说明。	配置 CSP、依赖版本与站点自身的 XSS/CSRF 防护。
数据合规	说明产品处理的数据类型与用途边界。	确定合法基础、完成必要告知，并配置符合自身业务的保留周期。

Disclosure

请通过已登录控制台的工单渠道提交可复现步骤、影响范围与必要日志。不要在工单中发送明文密码、私钥或无关个人信息。

边界说明