はじめに
- Shopifyから「今週中に対応を」という告知が出たが、何をすればいいのか分からない
shopify app security checkをどう回せばいいのか知りたい- 入れているアプリが安全かどうか、ストア側で確かめられることを知りたい
このような方のための記事です。
2026年10月20日、Shopifyは開発者向けの変更履歴で、すべてのアプリ開発者に今週中のセキュリティ対応を求めました。10月上旬にアプリ経由で買い物客が偽の決済画面に飛ばされる被害が出た直後で、Shopify側も店頭で動くアプリのコードや、APIキーの使い方に制限を入れると予告しています。
この記事では、Shopifyアプリのセキュリティについて求められた8つの対応を、アプリを作る側の手順に落として解説します。後半では、ストア運営者が入れているアプリで確かめることもまとめます。
Shopifyが出した告知の中身
告知は「対応が必要」の印が付いた開発者向けの変更履歴として出ています。AIで脆弱性を探す精度が上がり、アプリ全体を狙った攻撃が増えていることを理由に、セキュリティを「いま一番大事な仕事」と位置づけ、すべての開発者に今週中の対応を求めています。
告知そのものは個別の事件に触れていません。ただ、被害が出たアプリはどちらも、開発元のサーバーや管理の仕組みを入り口に、店頭へ不正なコードを流し込まれていました。経緯とストアでの確かめ方は偽の決済画面の記事にまとめています。
求められた8つの対応は、大きく3つに分けられます。
- コードを直す：security checkの実行、エンドポイントの保護、表示するデータのエスケープ、公式の指針の適用
- 鍵とアカウントを守る：期限付きのアクセストークン、関わるアカウントすべての2段階認証
- 見張って、すぐ動けるようにする：Dev Dashboardのログの確認、緊急連絡先の更新
1. shopify app security checkでアプリを検査する
10月15日にShopify CLIとAI Toolkitに入った検査です。アプリのコード、拡張の設定、依存パッケージを手元で調べ、見つけた問題を重さと直し方の例つきで出します。告知には、先行して試したパートナーの多くが、知らなかった問題を見つけたと書かれています。
検査には2段階あります。APIのバージョンが期限切れかどうかのように、コードを読めば答えが決まるものはコマンドがそのまま調べます。データベースの問い合わせが1つの店に絞られているかのように、コードの形だけでは決められないものは、コーディングエージェントに調べさせます。
推奨されているのは、Claude CodeなどのエージェントにShopify AI Toolkitを入れ、アプリのフォルダで次のように頼む方法です。
/shopify Check my app for security vulnerabilities
エージェントを使わない場合は、CLIのコマンドを直接実行してください。この場合に出るのは、コードの形で決まる検査の結果だけです。
shopify app security check
検査の項目は、重さが高いものだけで25あります。認証の無いルート、リクエストに書かれた店の名前をそのまま信じてデータを読む作り、署名を確かめないアプリプロキシ、テーマアプリ拡張のXSS、innerHTMLへの代入などです。結果は.shopify/app-security/に残り、リリースのたびに回すよう勧められています。
自社のアプリで回したときは、エスケープ済みの値を入れているinnerHTMLも指摘に出ました。出た指摘は1件ずつ中身を確かめる必要があり、何も出ないことが安全の保証にもなりません。
2. 期限付きのアクセストークンに切り替える
アクセストークンは、アプリが店のデータを読み書きするための鍵です。期限付きのトークンは1時間で切れるので、盗まれても長くは使えません。告知は「まもなく公開アプリで必須になる」としていますが、移行の手順のページにはすでに日付が出ています。期限の無いトークンは、既存の公開アプリでも2027年1月1日以降、GraphQL Admin APIで拒否されます。拒否されると、店主がアプリを開き直すまでアプリが動かなくなります。
React Routerのテンプレートで作ったアプリなら、設定でexpiringOfflineAccessTokensを有効にすれば切り替わります。自社のアプリ7本はすべて切り替え済みです。ただ、切り替えた直後に、アンインストールされた店への通知が500で失敗し続ける不具合に当たりました。テンプレートのライブラリ側の問題で、通知の受け口で署名を自前で確かめる回避策を入れて対応しました。切り替えたら、アンインストールの通知が200で返っているかまでDev Dashboardのログで確かめてください。
3. すべてのエンドポイントが守られているか確かめる
告知は脆弱性スキャナーを使って、アプリのすべての入口が守られているかを確かめるよう求めています。1のsecurity checkも、認証の確認が無いルートや、リクエストに書かれた店の名前でデータを選んでいる作りを拾います。
見落としやすいのは、管理画面の外から呼ばれる入口です。店頭からのアプリプロキシ、外部サービスからの受け口、自分で作った管理用のAPIは、管理画面のセッションで守られていません。それぞれ署名かトークンで確かめているかを、1本ずつ見てください。
4. 表示するデータはすべて信用しない
メタフィールドの値も、自分のサーバーから返した値も、画面に出すときはエスケープしてください。今回の告知で、自社のサーバーから来るデータまで「信用しない」と明記されたことには意味があります。サーバーを乗っ取られても、文字を文字として出していれば、店頭では何も動きません。
Liquidのescapeの付け方、javascript:で始まるリンク先や<style>に入れる色のように、エスケープだけでは塞げないものはアプリ開発者のセキュリティ対策の記事に具体例付きでまとめています。
5. Dev DashboardのログでAPIの呼び出し元を見る
Dev Dashboardのログは、GraphQLとRESTのリクエストを「クライアントIP」で絞り込めます。アプリのサーバーが出している呼び出しなら、IPはホスティング先のものに揃います。それ以外のIPから自分のアプリの鍵で呼び出しが来ていれば、鍵が漏れている疑いがあります。
ログは30日分残り、1回に見られる範囲は7日までです。自社のアプリでは毎朝、直近24時間のログを全件読み、Webhookの失敗と見覚えのない呼び出しが無いかを見ています。ログの行を開くとIPのほか、APIのバージョンや呼び出しの中身も出るので、見覚えのない呼び出しが何をしようとしていたかまで分かります。
6. アプリに関わるアカウントすべてで2段階認証を使う
対象は、Partnerのアカウント、ホスティング、CDN、コードのリポジトリ、メールです。Partnerのアカウントを取られると、不正な版を正規の更新として全ストアに配れてしまいます。メールを取られると、ほかのアカウントのパスワードを再設定されます。
あわせて、もう関わっていない人のアクセスを外してください。外注先、昔のメンバー、使っていないCLIのトークンやAPIキーも対象です。
7. 緊急連絡先のメールを、すぐ動ける人に届くようにする
Partner Dashboardには、Shopifyがアプリのセキュリティの問題を知らせるための緊急連絡先のメールがあります。退職した人や、誰も見ていない共有アドレスになっていないかを確かめてください。
自分で問題に気づいたときは、partner-security-reports@shopify.comにすぐ知らせるよう求められています。告知は、問題を直し、影響を受けた店に知らせるのは開発者の責任だと明記しています。どの店に、何を、どこから知らせるかも決めておくと、慌てずに済みます。
8. 公式のセキュリティの指針を見直す
Shopifyの開発者向けドキュメントには、アプリのセキュリティの指針がまとまっています。依存パッケージは公開から7日以上たった版を入れる、ロックファイルどおりに入れる、といった供給網の対策もここにあります。
Shopify側でこれから変わること
告知では、Shopify側の予定も3つ挙げています。
- 店頭で動くアプリのコードに、これまでより厳しい境界を設ける
- APIキーにIPアドレスの制限を足し、自分のサーバーからしか使えないようにする
- App Storeのセキュリティの要件を引き上げる
どれも、変更の前に詳細と日程を知らせるとしています。2つ目が入ると、5で見たような「漏れた鍵が別の場所から使われる」形は防ぎやすくなります。逆に、アプリのサーバーのIPが固定でないホスティングを使っている場合は、出口のIPを決められるかを今のうちに確かめておくと安心です。1つ目は、テーマアプリ拡張やアプリの埋め込みで店頭にスクリプトを出しているアプリに関わりそうです。古い仕組みのスクリプトタグが2027年3月1日に止まる話とあわせて、店頭のコードの出し方を見直す時期に来ています。
ストア運営者が、入れているアプリで確かめること
今回の告知は開発者向けですが、影響を受けるのは店です。ストア運営者の方は、次の4つを確かめてください。
- 使っていないアプリと、アプリの埋め込みを外す。外したアプリの分だけ、店頭に入ってくる道が減ります
- アプリの管理画面に、自由にJavaScriptを書ける欄が無いか見る。使っているなら、書いた中身に覚えがあるかを確かめてください
- 決済の前に、偽の画面に飛ばないかを確かめる。手順は偽の決済画面の記事にあります
- よく使うアプリの開発元が、今回の告知に対応しているかを問い合わせる。2段階認証やsecurity checkの実施を聞くだけでも、対応の早さが分かります
ストアのアカウントそのものを守る設定は、乗っ取り対策の記事にまとめています。
さいごに
Shopifyが求めた8つの対応は、コードを直す、鍵とアカウントを守る、見張る、の3つに分けられます。security checkと期限付きトークンは今日から手を付けられ、2027年1月1日という期限もすでに決まっています。Shopify側の制限は日程がまだ出ていないので、出たらこのブログで追いかけます。
自社アプリの点検やセキュリティの見直しは、お問い合わせからお気軽にご相談ください。