--- url: 'https://metadrop.net/en/articles/oembed-resources-custom-domain-drupal' title: 'oEmbed resources from a custom domain in Drupal' author: - 'Fran Rouco' - 'Luis Ruiz' date: '2024-09-13T16:24:30+00:00' updated: '2026-06-04T07:07:12+00:00' type: article summary: 'In 2018, Drupal added support for oEmbed in media and the ability to serve them from a subdomain to improve security against XSS attacks. Although the resources are displayed in iframes, doing so under the same domain can be insecure. It is recommended to configure a subdomain for the iframes and use rules in the `.htaccess` file to restrict access based on the `HTTP_REFERER`. Additionally, it is essential to configure the CSP module to control the allowed sources in iframes and prevent security issues.' image: 'https://metadrop.net/sites/default/files/styles/full/public/2024-10/drupal-oembed-domain.jpg.webp?itok=-6qVWb2Y' published: true og: determiner: Automatic site_name: Metadrop 'image:url': 'https://metadrop.net/sites/default/files/styles/full/public/2024-10/drupal-oembed-domain.jpg.webp?itok=-6qVWb2Y' 'image:type': image/jpeg 'image:width': '1075' 'image:height': '740' 'image:alt': 'oEmbed resources from a custom domain in Drupal' street_address: 'Calle Manuel Luna, 12, 3 Dcha' locality: Madrid region: Madrid postal_code: '28020' country_name: España email: hola@metadrop.net phone_number: '910053180' schema: '@context': 'https://schema.org' '@graph': - '@type': Article '@id': 'https://metadrop.net/en/articles/oembed-resources-custom-domain-drupal#article' name: 'oEmbed resources from a custom domain in Drupal' headline: 'oEmbed resources from a custom domain in Drupal' description: |- In 2018, Drupal added support for oEmbed in media and the ability to serve them from a subdomain to improve security against XSS attacks. Although the resources are displayed in iframes, doing so under the same domain can be insecure. It is recommended to configure a subdomain for the iframes and use rules in the `.htaccess` file to restrict access based on the `HTTP_REFERER`. Additionally, it is essential to configure the CSP module to control the allowed sources in iframes and prevent security issues. image: '@type': ImageObject url: 'https://metadrop.net/sites/default/files/styles/full/public/2024-10/drupal-oembed-domain.jpg.webp?itok=-6qVWb2Y' width: '1075' height: '740' datePublished: '2024-10-21T18:24:30+0200' dateModified: '2026-06-04T09:07:12+0200' author: '@type': Person name: - 'Fran Rouco' - 'Luis Ruiz' publisher: '@type': Organization '@id': 'https://metadrop.net/#organization' mainEntityOfPage: 'https://metadrop.net/en/articles/oembed-resources-custom-domain-drupal' - '@type': Organization '@id': 'https://metadrop.net/#organization' url: 'https://metadrop.net/' name: Metadrop sameAs: - 'https://www.drupal.org/metadrop' - 'https://twitter.com/metadrop' - 'https://asociaciondrupal.es/partner/metadrop' - 'https://www.linkedin.com/company/metadrop' logo: '@type': ImageObject url: 'https://metadrop.net/themes/custom/mdrop_radix/logo-metadrop-500-500.jpg' width: '500' height: '500' - '@type': ItemPage '@id': 'https://metadrop.net/en/articles/oembed-resources-custom-domain-drupal' breadcrumb: '@type': BreadcrumbList itemListElement: - '@type': ListItem position: 1 name: Home item: 'https://metadrop.net/en' - '@type': ListItem position: 2 name: 'Expert Drupal & Tech Articles' item: 'https://metadrop.net/en/articles' publisher: '@type': Organization '@id': 'https://metadrop.net/#organization' --- 1. [Articles](https://metadrop.net/en/articles) # oEmbed resources from a custom domain in Drupal Monday, October 21, 2024 In 2018, Drupal added support for oEmbed in media and the ability to serve them from a subdomain to improve security against XSS attacks. Although the resources are displayed in iframes, doing so under the same domain can be insecure. It is recommended to configure a subdomain for the iframes and use rules in the `.htaccess` file to restrict access based on the `HTTP\_REFERER`. Additionally, it is essential to configure the CSP module to control the allowed sources in iframes and prevent security issues. In 2018, Drupal implemented [support for oEmbed in media](https://www.drupal.org/node/2966029) and the ability to serve them from a different domain than the main one in order to add an extra layer of **security against XSS** (Cross-Site Scripting) attacks. By default, these third-party resources are already displayed inside an iframe but under the same domain, which makes it possible for the oEmbed resource to access cookies from the main domain. This poses a security risk that the provider of the resource can exploit. Configuring a custom domain for the oEmbed iframes is very simple. You just need to go to /admin/config/media/media-settings and set up a specific subdomain. This way, Drupal will start serving the oEmbed content from that subdomain, isolating it from the main domain and adding an extra layer of security. However, this configuration does not only affect the oEmbed iframes but also makes the **entire website accessible from that subdomain,** which could cause SEO issues, as search engines might index duplicate content or confuse the authority of the main domain. Therefore, it's important to restrict traffic from the oEmbed domain and configure the correct CSP (Content Security Policy) rules. ## Requirements - Domain with its certificate pointing to the same server as the main website - Module to manage CSP (Content Security Policy) rules - - ## How to restrict traffic for the oEmbed domain To restrict traffic on the oEmbed domain, we'll use a rule in the .htaccess file to limit the queries that can access that URL. We'll use **{HTTP\_REFERER}** to filter requests, establishing that if {HTTP\_REFERER} is from the main domain, it's a valid request and the resource is shown. ```apache RewriteEngine on # Only request to oembed subdomains from allowed domains are allowed, # otherwise a 403 is displayed. Header set x-Drupal-Oembed "TRUE" RewriteRule .* - [F,L] ``` In the first rule, it checks that: 1. The request host is to the **oEmbed domain,** in this case, "oembed.my-domain.com" 2. The referrer **is not empty** and matches one of the website’s domains: 1. https://www.my-domain.com -> production 2. https://my-domain.com -> production 3. https://dev.my-domain.com -> development environment 4. http://my-domain.ddev.site -> local environment No further action is required if the above conditions are met; in the example, a header is set for debugging purposes. In the second condition, a **403 error is returned, halting the execution of the .htaccess file.** Instead of returning a 403, you could set up a redirect to the main domain, but you would need to consider the external cache layers (e.g., Varnish), as they could cache the redirects, causing unwanted effects. ## CSP configuration The CSP (Content Security Policy) module improves the **security** of a website by defining which content sources can be loaded and displayed. For our implementation to be secure and function correctly, it is essential to properly configure this module. **URLs to consider** - The **site URL** (https://www.my-domain) and its variants for each environment (https://www.dev.my-domain). - The **"oembed"** URL (https://oembed.my-domain) and its variants for each environment (https://dev.oembed.my-domain). - Lastly, the **URL of the resource** we want to embed, for example, YouTube (https://www.youtube.com). We'll use the \* wildcard in CSP to simplify the configuration of the URLs: - https://\*.my-domain: refers to both the main URL and the various environments and oembed URLs. - https://\*.youtube.com: we apply the same pattern, though in this case, it's not strictly necessary. **Directives** There are three key CSP directives to focus on: - **frame-src:** Specifies trusted sources for <iframe> and <frame> elements. - **frame-ancestors:** Defines the trusted hosts allowed to embed site resources via <iframe>, <frame>, <object>, <embed>, and <applet>. - **child-src:** Specifies trusted sources for <iframe> and <frame> elements, as well as for loading Workers. **Directive configuration** The directives should be configured as follows: - **frame-src:** 'self' https://.my-domain.com https://.youtube.com - **frame-ancestors:** 'self' https://\*.my-domain - **child-src:** 'self' https://\*.youtube.com ### Potential issues #### Cache of redirects As mentioned in the example, if you choose to set up a redirect, it's important to consider the **external cache layer** configuration. If someone tries to directly access the resource (e.g., https://oembed.my-domain.com/media/oembed?...) and doesn’t have the correct referrer, a 403 is returned along with cache headers. This response will be cached in the external cache layer, and in future requests, **the external cache will return the 403 without reaching Drupal.** #### Iframe allow features The "allow" tag in the iframe indicates the [**browser APIs**](https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md) the iframe content can access. It's mandatory to fill this out because by default, iframes serving content from a different origin don’t have API access. A subdomain is considered a different origin. Another point to note is that even if API access is allowed, the domain must be a valid origin. By default, all (\*) origins are allowed, but they may be restricted with the **"**[**Permissions-Policy**](https://developer.chrome.com/docs/privacy-security/permissions-policy)**"** header. - Fran Rouco Drupal developer - Luis Ruiz Senior Drupal Developer [Module development and third-party integrations with Drupal](https://metadrop.net/en/services/drupal/integrations " See Module development and third-party integrations with Drupal") Metadrop connects Drupal to your CRM, ERP, payment, and marketing stack — Salesforce, Microsoft Dynamics, BBVA virtual POS, Workday, and Keepeek — with custom modules and secure, GDPR-compliant APIs. See more