审计Shopify应用权限,要看它为何需要某类数据、实际获准什么范围,以及退出后怎样处理功能和历史数据。一个评论应用读取订单可能用于验证购买,但功能名称不能自动证明权限合理,也不能据此认定它不应该读取任何订单。
必需权限与可选权限不能混为一谈
应用认证与授权文档区分身份认证和访问权限;当前access scopes管理文档进一步区分安装时的必需范围与安装后动态请求的可选范围。商家可以拒绝可选范围,也可以撤销已经授予的可选范围;实际操作入口取决于应用实现。
| 机制 | 实际含义 | 容易误判的地方 |
|---|---|---|
| 必需范围scopes | 安装时需要批准的范围;开发者可调整声明并按流程部署 | 不等于商家能任意删掉某个必需项并保证应用继续工作 |
| optional_scopes | 应用按需要请求,商家可授予、拒绝或撤销已授予范围 | 未请求或未获准不等于已经取得访问 |
| 读取与写入 | 具体API调用要求相应范围;示例write_products包含read_products | 只删读取声明未必收窄实际权限 |
| 当前已授权范围 | 应核安装实例真正获准的集合 | 开发配置、界面功能开关与现有授权不是同一件事 |
开发者将某范围从必需改为可选时,已有安装曾授予的范围可能继续保留为获准的可选范围,不能假设发布配置就自动撤回。受保护客户数据还涉及相应要求与批准,不能由scope名称推断所有个人字段都能取得。

一份能执行的应用清单
- 对齐已安装应用、销售渠道、自定义集成与计费记录,记录用途、负责人和实际使用位置。
- 保存当前权限说明及已授权范围,区分读、写和数据类型;需要开发者配合时索取针对本安装的解释,不只看营销页面。
- 逐项问清目的:为何需要订单或客户资料,是否导出到外部,谁能访问,保存多久,停用怎样删除。
- 核实际依赖:订单、库存、价格、订阅、通知、前台内容和像素事件;后台型应用不能因前台搜不到脚本就判为未使用。
- 给出保留、请求收窄、替代、暂停评估或卸载的决定,并记负责人和验证方法。没有收窄能力时应明确记录,不能写成已经撤权。
Shopify选择应用帮助列出了应用可能访问的店主、员工和客户等个人信息。商家在批准前应了解用途,安装后也要核更新的权限。数量不是风险分数:一个应用是否合适取决于功能、权限和治理,不是“低于几个就安全”。
关功能、移除区块与卸载分别做了什么
关闭应用内某功能可能只停止一项行为;移除主题区块可能只改变前台展示;二者都不自动证明API授权、后台任务、计费或历史数据已经结束。卸载处理应用安装关系,但手工主题代码、外部订阅与数据保留仍有各自流程。
不要对所有集成宣称“卸载只撤权、所有代码都留着”。平台管理的主题应用扩展和某些资源有自动清理机制,手工写入代码则可能需要另查;按具体集成方式的卸载检查处理,并用真实页面和请求确认。
先保留依赖,再执行退出
Shopify卸载帮助要求考虑重要数据、工作流及库存位置等影响。导出需要保留且有依据保留的数据,核替代方案与恢复方式;重新安装不保证恢复原设置和历史数据。主题副本不能把应用卸载隔离为仅影响副本。
涉及计费时区分Shopify内应用费和外部收费,核取消状态及既有账单,参见应用费用与订阅周期。执行后复测受影响的选购、订单、内容和事件,不能以“前台没有报错”判断全部成功。
卸载48小时后,平台向开发者发送删除请求
Shopify应用数据访问说明明确:卸载应用48小时后,平台会向开发者发送请求,要求删除应用安装期间收集的客户个人信息。要确认实际已经删除,仍需直接联系开发者;48小时是发送请求的时间,不是全部数据已删除的证明。
这与某位客户提出的个人数据删除请求不同。后者可按客户数据请求流程从客户资料发起,并核其他接收方;不能用卸载应用或删前台脚本代替处理客户请求。员工离职也应走账号访问回收,不会由应用审计自动完成。