許可リストの URL
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
許可リストを使用すると、スクリプトやアドオンによるアクセスが事前に承認されている特定の URL を指定できます。許可リストはユーザーデータの保護に役立ちます。許可リストを定義すると、スクリプト プロジェクトは許可リストに追加されていない URL にアクセスできなくなります。
このフィールドは、テスト デプロイをインストールする場合は省略可能ですが、バージョン付きデプロイを作成する場合は必須です。
スクリプトやアドオンで次のアクションを実行する場合は、許可リストを使用します。
- Apps Script の
UrlFetch
サービスを使用して、外部の場所(HTTPS エンドポイントなど)から情報を取得またはフェッチします。フェッチ用の URL を許可リストに登録するには、マニフェスト ファイルに urlFetchWhitelist
フィールドを含めます。
- ユーザー操作に応じて URL を開くか表示します(Google 外部の URL を開くか表示する Google Workspace アドオンで必須)。開く URL を許可リストに登録するには、マニフェスト ファイルに
addOns.common.openLinkUrlPrefixes
フィールドを含めます。
許可リストに接頭辞を追加する
マニフェスト ファイルで許可リストを指定する場合(addOns.common.openLinkUrlPrefixes
フィールドまたは urlFetchWhitelist
フィールドのいずれかを含める場合)、URL プレフィックスのリストを含める必要があります。マニフェストに追加する接頭辞は、次の要件を満たしている必要があります。
- 各プレフィックスは有効な URL である必要があります。
- 各接頭辞では
http://
ではなく https://
を使用する必要があります。
- 各接頭辞には完全なドメインが必要です。
- 各接頭辞には、空でないパスが必要です。たとえば、
https://www.google.com/
は有効ですが、https://www.google.com
は無効です。
- ワイルドカードを使用して、URL サブドメインの接頭辞を照合できます。
addOns.common.openLinkUrlPrefixes
フィールドで 1 つの *
ワイルドカードを使用してすべてのリンクを照合できますが、ユーザーのデータがリスクにさらされ、アドオンの審査プロセスが長引く可能性があるため、おすすめしません。ワイルドカードは、アドオンの機能で必要な場合にのみ使用してください。
URL が許可リストのプレフィックスと一致するかどうかを判断する際は、次のルールが適用されます。
- パスのマッチングでは大文字と小文字が区別されます。
- プレフィックスが URL と同一の場合は一致します。
- URL がプレフィックスと同じか、プレフィックスの子である場合は一致します。
たとえば、接頭辞 https://example.com/foo
は次の URL と一致します。
https://example.com/foo
https://example.com/foo/
https://example.com/foo/bar
https://example.com/foo?bar
https://example.com/foo#bar
ワイルドカードの使用
単一のワイルドカード文字(*
)を使用して、urlFetchWhitelist
フィールドと addOns.common.openLinkUrlPrefixes
フィールドの両方のサブドメインを照合できます。複数のサブドメインを照合するために複数のワイルドカードを使用することはできません。また、ワイルドカードは URL の先頭の接頭辞を表す必要があります。
たとえば、接頭辞 https://*.example.com/foo
は次の URL と一致します。
https://subdomain.example.com/foo
https://any.number.of.subdomains.example.com/foo
接頭辞 https://*.example.com/foo
は次の URL と一致しません。
https://subdomain.example.com/bar
(接尾辞の不一致)
https://example.com/foo
(少なくとも 1 つのサブドメインが存在する必要があります)
接頭辞ルールの一部は、マニフェストを保存しようとすると適用されます。たとえば、次の接頭辞がマニフェストに存在する場合、保存しようとするとエラーが発生します。
https://*.*.example.com/foo
(複数のワイルドカードは禁止されています)
https://subdomain.*.example.com/foo
(ワイルドカードは先頭の接頭辞として使用する必要があります)
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-31 UTC。
[null,null,["最終更新日 2025-08-31 UTC。"],[[["\u003cp\u003eAllowlists specify approved URLs for your script or add-on to access, enhancing user data protection by restricting access to unlisted URLs.\u003c/p\u003e\n"],["\u003cp\u003eAllowlists are necessary for scripts that fetch external data or open external links, especially for versioned deployments and Google Workspace Add-ons.\u003c/p\u003e\n"],["\u003cp\u003eWhen defining allowlists, use HTTPS prefixes with full domains, non-empty paths, and optional wildcards for subdomains, ensuring adherence to specific formatting rules.\u003c/p\u003e\n"],["\u003cp\u003eAllowlist prefixes are matched against URLs based on case-sensitive path comparisons, allowing access to identical URLs or child paths of the prefix.\u003c/p\u003e\n"],["\u003cp\u003eWildcards can represent subdomains in allowlist prefixes but must be used as the leading prefix and cannot be used to match multiple subdomains simultaneously.\u003c/p\u003e\n"]]],[],null,["# Allowlist URLs\n\nYou use allowlists to designate specific URLs that are pre-approved for access\nby your script or add-on. Allowlists help protect user\ndata; when you define an allowlist, script projects can't access URLs that have\nnot been added to the allowlist.\n\nThis field is optional when you install a test deployment, but is required when\nyou create a versioned deployment.\n\nYou use allowlists when your script or add-on performs\nthe following actions:\n\n- Retrieves or fetches information from an external location (such as HTTPS endpoints) using the Apps Script [`UrlFetch`](/apps-script/reference/url-fetch) service. To allowlist URLs for fetching, include the [`urlFetchWhitelist`](/apps-script/manifest#Manifest.FIELDS.urlFetchWhitelist) field in your manifest file.\n- Opens or displays a URL in response to a user action (Required for Google Workspace add-ons that open or display URLs that are external to Google). To allowlist URLs for opening, include the [`addOns.common.openLinkUrlPrefixes`](/apps-script/manifest/addons#Common.FIELDS.openLinkUrlPrefixes) field in your manifest file.\n\n| **Note:** *Whitelist* , as used in [`urlFetchWhitelist`](/apps-script/manifest#Manifest.FIELDS.urlFetchWhitelist), is a deprecated term that is synonymous with and replaced by *allowlist* . For more information, see [Writing inclusive documentation](https://developers.google.com/style/inclusive-documentation).\n\n### Adding prefixes to your allowlist\n\nWhen you specify allowlists in your manifest file (by including either the\n`addOns.common.openLinkUrlPrefixes` or `urlFetchWhitelist` field), you must\ninclude a list of URL prefixes. The prefixes you add to the manifest must\nsatisfy the following requirements:\n\n- Each prefix must be a valid URL.\n- Each prefix must use `https://`, not `http://`.\n- Each prefix must have a full domain.\n- Each prefix must have a non-empty path. For example, `https://www.google.com/` is valid but `https://www.google.com` is not.\n- You can use [wildcards](#using_wildcards) to match URL subdomain prefixes.\n- A single `*` wildcard can be used in the [`addOns.common.openLinkUrlPrefixes`](/apps-script/manifest/addons#Common.FIELDS.openLinkUrlPrefixes) field to match all links, but this is not recommended as it can expose a user's data to risk and can prolong the [add-on review](/workspace/add-ons/concepts/gsuite-addon-review) process. Only use a wildcard if your add-on functionality requires it.\n\nWhen determining if a URL matches a prefix in the allowlist, the following rules\napply:\n\n- Path matching is case-sensitive.\n- If the prefix is identical to the URL, it is a match.\n- If the URL is the same or a child of the prefix, it is a match.\n\nFor example, the prefix `https://example.com/foo` matches the following URLs:\n\n- `https://example.com/foo`\n- `https://example.com/foo/`\n- `https://example.com/foo/bar`\n- `https://example.com/foo?bar`\n- `https://example.com/foo#bar`\n\n### Using wildcards\n\nYou can use a single wildcard character (`*`) to match a subdomain for both the\n[`urlFetchWhitelist`](/apps-script/manifest#Manifest.FIELDS.urlFetchWhitelist)\nand [`addOns.common.openLinkUrlPrefixes`](/apps-script/manifest/addons#Common.FIELDS.openLinkUrlPrefixes)\nfields. You can't use more than one wildcard to match multiple subdomains, and\nthe wildcard must represent the leading prefix of the URL.\n\nFor example, the prefix `https://*.example.com/foo` matches the following\nURLs:\n\n- `https://subdomain.example.com/foo`\n- `https://any.number.of.subdomains.example.com/foo`\n\nThe prefix `https://*.example.com/foo` *doesn't* match the following\nURLs:\n\n- `https://subdomain.example.com/bar` (suffix mismatch)\n- `https://example.com/foo` (at least one subdomain must be present)\n\nSome of the prefix rules are enforced when you try to save your manifest. For\nexample, the following prefixes cause an error if they are present in your\nmanifest when you attempt to save:\n\n- `https://*.*.example.com/foo` (multiple wildcards are forbidden)\n- `https://subdomain.*.example.com/foo` (wildcards must be used as a leading prefix)"]]