ホワイトリストに登録されたリソース（スクリプト、ピクセルなど）のみをサンドボックス化されたiframe内で実行できるようにする方法は？

これに対する答えは残念ながら複雑です。iframeサンドボックスの出現により、質問は十分に単純に思えますが、探している仕様は非常に進行中です。したがって、適切なブラウザのサポートが必要な場合、問題はiframeのコンテンツを変更する方法に関係します。これには通常、何らかのプロキシが含まれます。

コンテンツセキュリティポリシー

本当に必要な仕様はCSPです。最も簡単には、iframe属性を使用して特定のスクリプトを許可しますcsp="..."。

<iframe ...
        src=""
        csp="script-src https://app.thirdparty.com/"
        ...></iframe>

指定されていないドメインからのスクリプト（つまり、質問のようにトラッキングスクリプト）は、応答で許可されません。スクリプトを特定のソースからのものに制限することは、サードパーティのアプリのサーバーとの連携に依存していることに注意してください。サーバーがユーザーエージェントにCSPの制限に準拠することを通知しない場合、応答はブロックされます。

CSPはまだ草案であり、将来変更される可能性があります。コメントに記載されているように、Chrome 61とOpera 48 は CSP仕様を実装していますが、現時点では、Firefox、Edge、またはSafariからも実装される兆候はありません。ユーザーが仕様をサポートするブラウザのみを使用することを保証できない場合を除き、追跡スクリプトは非常に大きな割合のユーザーに存在します。

残りの提案はすべて、問題のスクリプトを削除するためにiframeのコンテンツを変更することを含みます。

リバースプロキシ

iframe内のいくつかの追跡スクリプトをブロックするリバースプロキシを作成することは、過剰攻撃が行われる限り、核弾頭を使用してキャンプファイヤーを点火することと同じです。しかし、サーバーをこの程度に構成できる場合、これは私が見つけたiframeコンテンツの挿入/変更/ブロッキングのための最も信頼性が高くシームレスな方法です。

Wikipediaのページの状態：

リバースプロキシは、1つ以上のサーバーからクライアントに代わってリソースを取得する一種のプロキシサーバーです。これらのリソースはクライアントに返され、プロキシサーバー自体から発信されたように見えます。

リバースプロキシはサードパーティアプリとサイトの間の仲介者であるため、応答を透過的に変更して不要なスクリプトを削除できます。この例ではApacheを使用しますが、実際の実装は、既に使用しているサーバーによって異なります。

サーバーのIPを指すプロキシ用のサブドメインが必要proxywebapp.yourdomain.comです。サーバー上で、Apache mod_proxyモジュールを使用するhttpd.confに仮想ホストを作成します。仮想ホスト構成内で、AnalyticsJavaScript.comおよびTrackingPixel.comへのスクリプト呼び出しを空白で置き換えます。サードパーティアプリが HTTPSを使用する必要がある場合、プロキシのFQDNにSSL仮想ホストとSSL証明書が必要になるため、リバースプロキシはより複雑になります。

<VirtualHost *:*>
    ServerName        proxywebapp.yourdomain.com
    ProxyPreserveHost On
    ProxyPass         "/" "http://app.thirdparty.com/"
    ProxyPassReverse  "/" "http://app.thirdparty.com"

    # in case any URLs have the original domain hard coded
    Substitute        "s|app.thirdparty.com/|proxywebapp.yourdomain.com/|i"
    # replace the undesired scripts with blanks
    Substitute        "s|AnalyticsJavaScript/| /|i"
    Substitute        "s|TrackingPixel/| /|i"
</VirtualHost>

次に、iframeはをポイントしproxywebapp.yourdomain.comます。

<iframe ... src="proxywebapp.yourdomain.com" ...></iframe>

繰り返しますが、完全に過剰ですが、透過的に機能するはずです。

プロキシスクリプト

考慮すべき3番目のオプションは、iframeとサードパーティアプリ間のサーバーにプロキシスクリプトを実装することです。不要なスクリプトをiframeに到達する前に検索して削除する機能をプロキシスクリプトに追加します。さらに、プロキシはiframeのコンテンツが同じ生成元のポリシーを検証することを意味します。そのため、フロントエンドでJavaScriptを使用して不要なコンテンツを削除することもできますが、削除される前にスクリプトが実行されないことは保証されません。あらゆる種類のバックエンド（PHP、Node.jsなど、悪心）に対してオンラインで利用できる多くのプロキシスクリプトがあります。おそらく、スクリプトをインストールして、iframeのsrcとして追加し<iframe ... src="proxy.php?https://app.thirdparty.com/" ...>ます。

すべてのケースで適切に構成されていない場合、プロキシはサードパーティアプリとその親サーバーの間でデータを正しく転送しない可能性があります。テストが必要になります。

いくつかのスクリプトをiframeから削除する独自のサーバー側プロキシを作成することは、おそらく少し過剰です。

バックエンドにアクセスできない場合は、JavaScriptとCORSまたはJSONP Webアプリを使用してWebアプリのコンテンツをスクレイピングし、それを変更してスクリプトを削除することができます。基本的に、JavaScriptで独自のプロキシを作成します。このようなWebアプリ（Any Origin、All Originsなど）を使用すると、クロスドメインポリシーの制限を回避できますが、これらはサードパーティであるため、Webアプリのデータが非公開であると想定することはできません。アプリとその親サーバーの間のデータ転送を正しく通信する問題は引き続き存在します。

概要

広くサポートされている純粋なフロントエンドソリューションは、現時点では実現できません。しかし、クロスドメインの制限に関係なく、猫のスキンを作成する方法は多く、iframeのコンテンツを変更する方法はさらに多くあります。

コンテンツセキュリティポリシーは有望に見え、まさにあなたが求めているものですが、現在、広範囲にわたるサポートがないため、非常にニッチな状況でのみ使用できます。コンテンツを変更するリバースプロキシの設定には多くの時間がかかる可能性があり、この状況では、ホットホイールトラック上でフルサイズのセミトレーラーを運転するようなものですが、おそらくシームレスに動作します。フォワードプロキシからのコンテンツの変更は実装がいくらか簡単ですが、サードパーティアプリの親サーバーとの通信が切断される可能性があります。