Shopify 应用权限审计：授权范围、数据访问与撤权流程

一个只做评论展示的应用，授权页面上写着要读取订单和客户信息，这不是它贪心，而是平台的权限按资源类别成组给出：你批准的是那一组，不是「只给评论用」。理解这一点之后，审计应用权限就变成了一个可以按步骤做完的动作，而不是靠感觉判断哪个应用「看起来不老实」。

授权范围批准的到底是什么

应用要读写店铺数据，得先拿到访问凭证。凭证一方面标明是哪个应用在调用，一方面决定它能碰到什么——官方文档把这两件事写得很清楚：请求返回什么取决于该凭证的访问范围允许什么，范围不够就直接报错（Shopify 应用认证与访问范围说明）。

这套机制对商家的含义是：你在授权页能决定的只有「批准这一组」或「不批准」，不能只批准其中一小块。所以要看的不是应用名字，而是它申请的整组范围里有没有明显超出功能的部分。一个只展示评价的应用要了订单写入权限，这种组合值得当场问清楚，而不是装完再想。

凭证还有有效期上的区别：跟着员工会话走的在线凭证，以及跨会话长期有效的离线凭证（同一份文档里有说明）。撤权前先分清你处理的是哪一种——在线凭证会随会话结束失效，离线凭证不会自己消失，最终还是靠撤销授权或卸载来结束。

还有一类应用值得单独翻出来看：早期在后台直接创建的定制应用。官方文档提到，这类应用由平台在商家安装时预先生成访问凭证，现在已经不能新建，但如果你手上还维护着这样的应用，它的凭证往往没人记得是谁在用（同一份认证文档里有一段专门说明）。这类应用不在应用商店里，属于检查时要单独确认的一项。

审计流程：一张表跑完全部应用

先做清单，再做判断，顺序不要跳。清单不全的话，后面每一步的结论都是残缺的。

1. 拉出清单。后台的应用列表和计费页面两处对齐，特别留意还在扣费但已经没人使用的应用，这类最容易逃过检查。
2. 每个应用标注三件事：解决什么问题、现在还有谁在用、有没有替代办法。替代办法包括平台原生能力和主题自带功能，不要默认「没有应用就做不了」。
3. 打开店铺前台，确认它到底在哪里出现：是主题里的一个区块，还是注入到每个页面的脚本，还是只存在于后台。
4. 把申请的范围和实际观察到的功能对照，标出对不上的项目。
5. 分成四类：必需保留、保留但要收窄、可以降级到原生功能、直接卸载。
6. 每次只处理一到两个应用，处理完走一遍下单流程再继续下一个。

表里那一列的问题，只有一个能通过后台回答，其余都要问应用方。问不到明确答复的应用，按「保留但要收窄」处理，别停在原地等。

做这轮审计的时机也有讲究。装新应用之前先看一眼现有应用里有没有做同一件事的，这是最省事的一次检查；季度核查走一遍清单，处理积压；大促之前只做确认，不做删减——那几天不是验证脚本改动的好时候，业务流量会掩盖问题，出问题的影响也更大。

撤权之前必须确认的三件事

撤权的动作很轻，代价通常出现在别的地方。动手前确认这三件。

1. 结账与订单流程不依赖它。付款方式、运费、税费、折扣规则、订单自动化（自动打标签、自动发通知）里有没有它的影子，都要逐个看。测试方法是在副本环境或测试订单里走一遍完整下单。
2. 需要留下的数据先导出。客户备注、评价内容、订阅记录、埋点历史，撤销授权之后还能不能拿到，取决于应用方，不要等到要用的时候才去问。
3. 页面上它的位置有人接手。卸载之后主题里对应的位置会变成空白或报错，先在副本主题里把区块换成替代内容，再卸载。

第三件事经常被低估。应用在前台的表现不只是数据，还有版式：一个推荐位消失，可能连带影响下面的排版和加购按钮位置。改动前先看一眼这个区块在移动端的位置。顺手记一笔台账——撤掉了哪个应用、什么时候撤的、谁批准的，下次有人问起就不用靠回忆。

卸载之后还留着什么

卸载结束的是后台的授权关系，不会自动清掉已经写进主题的东西。常见的残留有三类：主题文件里的代码片段（初始化脚本、用来做样式的应用专属类名）、模板里保留的区块设置（区块还在，只是渲染不出来）、以及页面上仍在请求外部域名的脚本标签。

排查方法是在主题代码里搜索应用域名、应用名和它特有的类名前缀，逐个确认引用位置，再在副本主题上删除并回归页面。这整套流程和备份要求写在清理那篇里（卸载后的代码与数据清理顺序）。

残留脚本的典型症状不是页面空白，而是主题交互出问题——集合页筛选项被清掉、排序结果不对、弹窗关不掉。这类现象看起来像主题的毛病，实际是脚本在抢同一批状态，排查思路完全不同（主题交互与脚本冲突的状态排查）。另外，统计、客服这类外部脚本要不要一起处理，判断标准是业务是否需要它，和为了分数删脚本不是一回事（第三方脚本的归属与取舍）。

撤权不等于数据被删

这里要划一条清楚的线。撤销授权结束的是「这个应用还能不能通过接口继续取数据」，不等于应用方已经销毁此前拿到的数据。历史数据在应用方那边怎么留存、怎么删除，取决于它的隐私政策和数据处理说明，这件事需要商家自己去核对，平台不会替你确认，也没有哪个开关能一键保证。

所以撤权之前该做的两件事是：把你要留的数据导出，把你要它删的数据以书面方式提出。相关的一整条线——隐私政策怎么写、Cookie 与跟踪脚本要不要先取得同意、客户提出访问或删除请求时怎么响应——在客户数据那篇里展开（客户数据与同意管理的落地做法）。

还有一件不能假定的事：只要脚本还在页面上运行，它仍然可能向外部发请求。撤权那一步做完了，清理那一步不能省。

撤掉的三种做法与各自的风险

• 整个卸载。最彻底，代价是它承载的功能一起消失，包括可能有人已经习惯的自动化和历史数据的入口。适合已经没人用的应用。
• 只移除它在主题里的部分。适合功能后台还在用、但前台展示不需要的应用。风险是后台一直跑着，过几个月没人记得它还在，交接时最容易被漏掉。
• 只关掉部分设置。营销类应用里停用某几个不再使用的渠道时常用这个做法，风险最小，但也最容易留下「看着关掉了、其实还在跑」的错觉。关掉之后要到前台确认脚本还在不在。

三种做法都要求动手前后各看一眼前台：动手前确认没有别人正在依赖它，动手后确认页面上没有报错、下单流程正常。

应用权限和员工权限是两套体系

审计应用的时候容易顺手把员工权限一起管，但两者的控制点不一样：员工账号控制的是「谁能进后台、在后台能做什么」，应用的访问范围控制的是「这个程序能通过接口读写什么」。一个员工离职需要停用账号，一个应用没人用了需要卸载并清理代码，动作不通用。员工权限的分配和离职处理在账号安全那篇里（后台账号与权限的核查清单）。

最后一点关于数量：不要用应用个数判断安全或性能，一个必需应用好过五个低频应用。每多装一个应用，就多一组你批准过的访问范围，也多一份要定期检查的东西。判断一个应用该不该留，标准是它解决的问题有没有更稳的替代方式。

如果这轮审计之后发现真正要处理的是结账链路、脚本冲突或数据合规这类跨环节的问题，而不是某个应用本身，可以把范围放大一起看（咨询与排查协助）。