別ドメインへのスクリプト注入：UserScriptで実現可能な境界線

はじめに (対象読者・この記事でわかること)

この記事は、JavaScriptの基本的な知識があり、Webページのカスタマイズや自動化に興味がある開発者を対象としています。特に、UserScriptを用いて別ドメインのページにスクリプトを注入する可能性と限界について知りたい方に向けています。この記事を読むことで、UserScriptの基本的な仕組み、同一オリジンポリシーの制約、そして可能な代替手段について理解できます。また、実際に簡単なUserScriptを作成してテストする方法も学べます。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。 - JavaScriptの基本的な知識 - HTML/CSSの基本的な知識 - ブラウザの開発者ツールの基本的な使用方法

UserScriptの基本とクロスドメインの課題

UserScriptとは、TampermonkeyやGreasemonkeyなどのブラウザ拡張機能を利用して、特定のWebサイトにスクリプトを注入し、ページの表示や動作をカスタマイズする技術です。多くのWebサイトでは、セキュリティ上の理由から同一オリジンポリシー（Same-Origin Policy）が適用されており、別ドメインのページに対して直接JavaScriptを実行することは制限されています。

しかし、UserScriptを適切に設定することで、特定の条件下では別ドメインのページに対してもスクリプトを実行できる場合があります。このセクションでは、その可能性と限界について詳しく解説します。

まず、UserScriptの基本構造を見てみましょう。基本的なUserScriptは以下のような構成になっています。

Javascript

// ==UserScript==
// @name         My User Script
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  try to take over the world!
// @author       You
// @match        https://www.example.com/*
// @grant        none
// ==/UserScript==

この中で重要なのは@matchディレクティブで、スクリプトが適用されるURLのパターンを指定します。例えば、https://www.example.com/*と指定すると、example.comのすべてのページにスクリプトが適用されます。

同一オリジンポリシーは、スクリプトが異なるオリジン（プロトコル、ドメイン、ポートの組み合わせ）のリソースにアクセスすることを制限するセキュリティメカニズムです。これにより、悪意のあるスクリプトが他のWebサイトのデータを不正に取得したり操作したりするのを防ぎます。

別ドメインへのスクリプト注入の具体的な方法

UserScriptを用いて別ドメインのページにスクリプトを実行するには、いくつかの方法があります。それぞれの方法とその限界について詳しく見ていきましょう。

方法1: @includeと@matchの組み合わせ

特定のドメインのページにスクリプトを注入するには、@includeまたは@matchディレクティブを使用して対象のURLを指定します。

Javascript

// ==UserScript==
// @name         Cross Domain Script
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  Script for cross domain
// @author       You
// @match        https://www.example.com/*
// @match        https://www.otherdomain.com/*
// @grant        none
// ==/UserScript==

このスクリプトは、example.comとotherdomain.comの両方のページに適用されます。ただし、この方法では各ページのコンテキストでスクリプトが実行されますが、ページ間での直接なデータ共有はできません。

方法2: GM_xmlhttpRequestを使用したクロスドメインリクエスト

UserScriptでは、GM_xmlhttpRequest関数を使用してクロスドメインリクエストを行うことができます。ただし、これはリモートサーバーへのリクエストであり、ページのDOM操作とは異なります。

Javascript

// ==UserScript==
// @name         Cross Domain Request
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  Request to other domain
// @author       You
// @match        https://www.example.com/*
// @grant        GM_xmlhttpRequest
// ==/UserScript==

(function() {
    'use strict';

    GM_xmlhttpRequest({
        method: "GET",
        url: "https://www.otherdomain.com/api/data",
        onload: function(response) {
            console.log(response.responseText);
        }
    });
})();

この方法では、リモートサーバーがCORS（Cross-Origin Resource Sharing）を許可している必要があります。サーバーがCORSを許可していない場合、リクエストはブロックされます。

方法3: iframeを使用したコンテンツの埋め込み

別ドメインのコンテンツをiframeで埋め込み、その中のコンテンツにアクセスすることは可能ですが、同一オリジンポリシーの制限を受けます。

Javascript

// ==UserScript==
// @name         Iframe Content
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  Access iframe content
// @author       You
// @match        https://www.example.com/*
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    var iframe = document.createElement('iframe');
    iframe.src = "https://www.otherdomain.com/page";
    document.body.appendChild(iframe);

    // 同一オリジンポリシーにより、以下のコードはエラーになる
    // console.log(iframe.contentWindow.document);
})();

iframe内のコンテンツに直接アクセスすることはできませんが、postMessage APIを使用した通信は可能です。

方法4: プロキシサーバーを利用した間接的なアクセス

別ドメインのAPIに直接アクセスできない場合、プロキシサーバーを利用して間接的にアクセスする方法があります。

Javascript

// ==UserScript==
// @name         Proxy Request
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  Request via proxy
// @author       You
// @match        https://www.example.com/*
// @grant        GM_xmlhttpRequest
// ==/UserScript==

(function() {
    'use strict';

    GM_xmlhttpRequest({
        method: "GET",
        url: "https://your-proxy-server.com/api?url=https://www.otherdomain.com/data",
        onload: function(response) {
            console.log(response.responseText);
        }
    });
})();

この方法では、自分のサーバー（プロキシサーバー）を介してリクエストを送信するため、CORSの制限を回避できます。ただし、プロキシサーバーの設定と管理が必要です。

方法5: CORSを許可するサーバーとの連携

リモートサーバーがCORSを許可するように設定されている場合、通常のXMLHttpRequestやFetch APIを使用してデータを取得できます。

Javascript

// ==UserScript==
// @name         CORS Request
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  Request with CORS
// @author       You
// @match        https://www.example.com/*
// @grant        GM_xmlhttpRequest
// ==/UserScript==

(function() {
    'use strict';

    fetch('https://api.cors-enabled.com/data')
        .then(response => response.json())
        .then(data => console.log(data))
        .catch(error => console.error('Error:', error));
})();

この方法では、リモートサーバーがCORSを許可している必要があります。サーバー側で以下のようなヘッダーを設定する必要があります。

Access-Control-Allow-Origin: *

ハマった点やエラー解決

UserScriptを用いて別ドメインのページにスクリプトを実行しようとする際に、よく遭遇する問題とその解決方法を以下に示します。

エラー1: Access-Control-Allow-Originによるクロスドメイン制限

GM_xmlhttpRequestを使用して別ドメインのAPIにアクセスしようとする際に、以下のようなエラーが発生することがあります。

Access-Control-Allow-Origin: https://www.example.com is therefore not allowed access.

これは、リモートサーバーがCORSを許可していないためです。

解決策: 1. リモートサーバーがCORSを許可するように設定されているか確認する 2. プロキシサーバーを利用して、リクエストを自分のドメイン経由で送信する 3. JSONPを使用する（サーバーが対応している場合）

エラー2: 同一オリジンポリシーによるDOMアクセスの制限

iframe内のコンテンツにアクセスしようとする際に、以下のようなエラーが発生することがあります。

Uncaught DOMException: Failed to read a property 'contentDocument' from 'HTMLIFrameElement': Blocked a frame with origin "https://www.example.com" from accessing a cross-origin frame.

これは、同一オリジンポリシーによる制限です。

解決策: 1. iframeのsrcに同じオリジンのURLを指定する 2. リモートサーバーがpostMessage APIを使用して通信できるように設定する 3. iframeのコンテンツを自分のサーバーでプロキシし、同一オリジンで提供する

エラー3: GM_xmlhttpRequestの権限不足

GM_xmlhttpRequestを使用する際に、権限不足によるエラーが発生することがあります。

Uncaught Error: Greasemonkey access violation: You do not have permission to call GM_xmlhttpRequest.

これは、スクリプトのヘッダーに@grant GM_xmlhttpRequestが指定されていないためです。

解決策: スクリプトのヘッダーに@grant GM_xmlhttpRequestを追加します。

Javascript

// ==UserScript==
// @name         My Script
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  Description
// @author       You
// @match        https://www.example.com/*
// @grant        GM_xmlhttpRequest
// ==/UserScript==

実践的な例: 別ドメインのサイトにスクリプトを注入する

ここでは、実際に別ドメインのサイトにスクリプトを注入する例を示します。ただし、セキュリティと法的な問題を考慮し、テスト用のサイトや自分が所有するサイトでのみ実行してください。

Javascript

// ==UserScript==
// @name         Cross Domain Example
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  Example of cross domain script
// @author       You
// @match        https://www.example.com/*
// @grant        GM_xmlhttpRequest
// ==/UserScript==

(function() {
    'use strict';

    // 別ドメインのAPIからデータを取得
    GM_xmlhttpRequest({
        method: "GET",
        url: "https://jsonplaceholder.typicode.com/posts/1",
        onload: function(response) {
            var data = JSON.parse(response.responseText);

            // 取得したデータをページに表示
            var div = document.createElement('div');
            div.innerHTML = '<h2>' + data.title + '</h2><p>' + data.body + '</p>';
            document.body.appendChild(div);
        }
    });
})();

このスクリプトは、example.comのページにアクセスすると、jsonplaceholder.typicode.comからデータを取得し、その内容をページに表示します。jsonplaceholder.typicode.comはCORSを許可しているため、この例では問題なく動作します。

まとめ

本記事では、UserScriptを用いて別ドメインのページに対してスクリプトを実行する可能性と限界について解説しました。

UserScriptは、特定のWebサイトにスクリプトを注入するための強力なツールですが、同一オリジンポリシーの制限を受けます。
GM_xmlhttpRequestを使用することで、別ドメインのAPIにアクセスできますが、サーバー側のCORS設定が必要です。
iframeを使用して別ドメインのコンテンツを埋め込むことはできますが、そのコンテンツに直接アクセスすることはできません。
別ドメインのページにスクリプトを実行するには、プロキシサーバーやpostMessage APIなどの代替手段を検討する必要があります。

この記事を通して、UserScriptの基本的な仕組みとその限界について理解できたことと思います。今後は、より高度なUserScriptの作成方法や、セキュアなクロスドメイン通信の実現方法についても記事にする予定です。

別ドメインへのスクリプト注入：UserScriptで実現可能な境界線🔧