- Ya
- 6 Agosti 2026, 13:06 UTC
- Mwandishi
- kamo
- Ahadi ya
- a7352ef
External images stopped rendering when the page-level image policy shipped. The middleware sets `img-src 'self' data: blob: https://theme.<apex> https://*.<apex>`, and an email body renders in a `srcdoc` iframe with `allow-same-origin`, so it inherits that policy — every third-party URL in the message was refused by the browser. "Display external images" revealed URLs the page was not permitted to load, so clicking it did nothing. The rest of the app was moved onto `/api/images/proxy` in the same change, which is why `'self'` is sufficient everywhere else. Email bodies were the surface still emitting raw origins. They now go through the same proxy, for `<img src>` and for remote `url()` in CSS — `img-src` governs `background-image` too. Two details this turned up: - DOMPurify re-validates an attribute after a hook rewrites it, and an <img> left with no src is dropped outright rather than kept as a broken image. So ALLOWED_URI_REGEXP had to name the proxy path as well; without it the rewrite deleted the very images it was trying to restore. - `http:` images are dropped rather than proxied. The proxy only speaks https and an https page blocks mixed content regardless, so handing the browser a URL it is going to refuse helps nobody. Blocking is unchanged while the member has not allowed images: the transparent pixel and data-kamo-blocked-src still stand in, and no request fires. Inline cid: images were never affected — they already resolved to a same-origin path the policy allows.