用途：该技能面向扩展 Spree 6 的开发者，用于加固应用、审查 PR 或排查安全问题。Spree 继承 Rails 安全模型，并额外暴露支付流程、客户 PII、员工凭据和出站 Webhook 等电商攻击面。角色与权限细节另见 spree-auth-permissions。
主要能力：
- 密钥管理：密钥应放在 Rails 加密凭据或环境变量中，禁止入库；VITE_* 变量会编译进前端包，绝不能放密钥。泄漏后先在服务商处轮换，再更新凭据并部署，最后用 git filter-repo 清理历史。secret_key_base 必须按环境保持稳定，轮换会使所有 sk_ 密钥失效；建议用 SPREE_JWT_SECRET_KEY 单独设置 JWT 密钥。Active Record 加密需配置 ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY、DETERMINISTIC_KEY、KEY_DERIVATION_SALT 三个变量，否则相关列以明文存储。
- API Key：pk_* 可公开，仅用于 Store API；sk_* 仅限服务端。应遵循最小作用域，如 spree api-key create --type secret --scopes read_orders,write_fulfillments。作用域与渠道绑定不可变，轮换需新建密钥、部署后再吊销旧密钥。
- 后台会话：React 仪表盘不保存 API Key，JWT 仅存内存（默认 5 分钟），刷新令牌为 HttpOnly 签名 Cookie。同源无需 CORS；跨源需 HTTPS 并在 Allowed Origins 表中登记来源。UI 隐藏按钮不等于授权，API 网关才真正校验权限。
- Store API 防 IDOR：购物车与订单凭 JWT 或 X-Spree-Token 读取，前缀 ID 并非秘密，必须逐次授权。自定义控制器应通过 storefront_access_policy.scope 或 current_user 关联读取，禁止 Model.find(params[:id])。开发与测试环境可用 Spree::StoreScopeGuard 检测未按店铺作用域过滤的查询。
- 注入与 XSS：SQL 使用参数化查询；Ransack 仅按白名单过滤。富文本经 Spree::RichTextSanitizer 保存时净化，跳过回调的写入需手动调用 sanitize。CSV 导出需中和以 =、+、-、@ 开头的单元格。
- Webhook：出站投递带 X-Spree-Webhook-Signature（对 timestamp.raw_body 做 HMAC-SHA256），接收方须在 JSON 解析前用原始字节做常量时间比较，拒绝约 5 分钟前的旧时间戳，并保持幂等。非 2xx 会由 WebhookDeliveryJob 退避重试共 5 次。生产环境经 SsrfFilter 拦截内网目标。入站 Webhook 仅凭签名认证。
- GDPR：客户可通过 POST /api/v3/store/customers/me/data_requests 提交访问或删除请求；员工使用导出与匿名化接口。匿名化会清除账户、地址、已存卡、身份与会话，但保留财务记录。新增含个人数据的表须同步扩展匿名化逻辑。
使用方式：作为技能加载后，在加固 Spree 6 应用、审查 PR 或排查上述安全问题时调用。
限制：具体安装与调用命令资料未提供；部分配置项与钩子需结合 Spree 版本与项目实际验证。