Reject sneaky dot segments in <iframe> URLs

What does this MR do and why?

Reject sneaky dot segments in <iframe> URLs.

These get normalised in the browser, allowing different paths to potentially sneak past allowlists and load unintended URLs from permitted provider domains.

The actual potential risk from this today is very low. Right now these two possibilities exist:

• ![](https://youtu.be/..)
  • We turn this into <iframe src="https://www.youtube.com/embed/..">
  • The browser turns that into <iframe src="https://www.youtube.com/">
  • YouTube sends a HTTP header that denies embedding any non-embed URL on its site: the <iframe> doesn't load at all.
• ![](https://embed.figma.com/board/..) (or any other Figma embed type we accept)
  • We turn this into <iframe src="https://embed.figma.com/board/..?embed-host=gitlab">
  • The browser turns that into <ifram src="https://embed.figma.com/?embed-host=gitlab">
  • Figma gives a 404 at that URL.

... but (a) there's also no legitimate reason to include a dot path segment in an <iframe> URL, and (b) maybe some instance admin will configure their own provider where this would open up some undesirable embeds. So reject them.

This is part of a wip FF; no current users. There's no existing cached HTML which needs to be reset or could potentially be storing problematic stuff, so no Markdown cache bump is warranted.

MR stack

MR 7/12 of Rework <iframe> embed configuration (#599713):

1. Add `<iframe>` provider model and parser (!254943 - merged)
2. Add `<iframe>` provider loader and base config (!254944 - merged)
3. Convert `<iframe>` allowlist setting to provide... (!254945 - merged)
4. Move to `<iframe>` providers (!254946 - merged)
5. Remove dead `<iframe>` transform code (!254947 - merged)
6. Allow additional CSP hosts in `<iframe>` embeds (!257463 - merged)
7. Reject sneaky dot segments in `<iframe>` URLs (!258894 - merged) ⬅️ you are here
8. Frontend `<iframe>` hardening (!254948 - merged)
9. Render `<iframe>` embeds in Vue (!259513 - merged)
10. Click-to-activate functionality for `<iframe>`s (!254949 - merged)
11. Admin UI for `<iframe>` providers (!254950 - merged)
12. Draft: Mark `<iframe>` config, loader and rende... (!255246)

Part of <iframe> embeds in Markdown content (#282443).

References

Part of Rework <iframe> embed configuration (#599713).

Screenshots or screen recordings

Using the following source:

![](https://embed.figma.com/board/..)

Before	After

In the Before side, the embed target resolved by the backend is https://embed.figma.com/board/..?embed-host=gitlab; the browser collapses the dot segments and makes https://embed.figma.com/?embed-host=gitlab the target. (That URL gives a 404.)

In the After side, we refuse to treat it as an <iframe> embed at all; it's treated like any other image embed.

How to set up and validate locally

1. Check out master.
2. Enable the allow_iframes_in_markdown FF.
3. Go to Admin → Settings → General → Embedded content.
4. Check "Enable embedded content", enter figma into the "Allowed domains" list, and click "Save changes":
   
   (This is odd but will be fixed as of Admin UI for `<iframe>` providers (!254950 - merged).)
5. For best chances of first-try success, consider restarting your GDK/Caproni edit mode. The FF/setting change may be cached.
6. Navigate to a work item, enter the above Markdown in a plain-text area (can be the work item description, or a new comment), and save. You should see the "Before" side.
7. Check out this branch, perhaps restarting GDK/Caproni edit mode again.
8. Go to the same work item, and edit its source. You need to change something in it for the backend to reprocess the content. (This is why the ok??!! is in my screenshots 😹)
9. After saving, you should see the "After" side.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.