Admin CSP img-src doesn't extend from plugin allowedHosts (blocks Unsplash thumbnails in Featured Image Studio)

[devondragon]

Summary

The strict Content-Security-Policy applied to /_emdash routes hardcodes img-src to 'self' data: blob: (plus the marketplace origin) and does not extend it based on plugin allowedHosts. This breaks any plugin that renders remote thumbnails in the admin UI — notably @devondragon/emdash-plugin-featured-image-studio, whose Unsplash picker tab shows empty tiles because https://images.unsplash.com is blocked.

Related: #205 (same pattern, but for connect-src + S3). This is the img-src variant of the same underlying issue.

Repro

1. Install @devondragon/emdash-plugin-featured-image-studio in an EmDash site.
2. Open Plugins → Featured Image Studio → Stock (Unsplash) tab.
3. Search for anything (e.g. "llama").
4. Tiles render with titles/attribution/dimensions but the image areas are blank. DevTools console shows CSP violations for https://images.unsplash.com/... against img-src 'self' data: blob: <marketplace>.

Source

node_modules/emdash/dist/astro/middleware/auth.mjs — buildEmDashCsp():

function buildEmDashCsp(marketplaceUrl) {
    const imgSources = ["'self'", "data:", "blob:"];
    if (marketplaceUrl) try { imgSources.push(new URL(marketplaceUrl).origin); } catch {}
    return [
        "default-src 'self'",
        "script-src 'self' 'unsafe-inline'",
        "style-src 'self' 'unsafe-inline'",
        "connect-src 'self'",
        ...
        `img-src ${imgSources.join(" ")}`,
        ...
    ].join("; ");
}

The plugin declares network:fetch with allowedHosts: ["api.unsplash.com", "images.unsplash.com"], but buildEmDashCsp never consults plugin metadata — so the allowlist is effectively ignored for anything the browser fetches directly (images, fonts, etc.).

Expected

Plugin-declared allowedHosts should be merged into the admin CSP for at least img-src and connect-src (likely gated on the network:fetch capability). That way a plugin declaring allowedHosts: ["images.unsplash.com"] "just works" end-to-end without consumers having to patch CSP in their own middleware.

Workaround

In a consuming site's Astro middleware, patch the CSP on /_emdash responses:

if (pathname.startsWith("/_emdash")) {
  const csp = response.headers.get("Content-Security-Policy");
  if (csp && !csp.includes("images.unsplash.com")) {
    response.headers.set(
      "Content-Security-Policy",
      csp
        .replace(/img-src ([^;]*)/, "img-src $1 https://images.unsplash.com")
        .replace(/connect-src ([^;]*)/, "connect-src $1 https://api.unsplash.com")
    );
  }
}

This shouldn't be necessary — the plugin already told EmDash which hosts it needs.

Environment

• emdash ^0.1.0
• @devondragon/emdash-plugin-featured-image-studio ^0.2.0
• Cloudflare Workers + D1 adapter

[devondragon]

Correction to the workaround in the original post — patching CSP from Astro user middleware (src/middleware.ts) does not work, because EmDash's auth middleware runs outside user middleware in the chain and sets the CSP header after user middleware returns. Any mutation from user middleware gets overwritten.

The working fix is to wrap the Cloudflare Workers handler at the entrypoint (src/worker.ts) so the rewrite happens on the outbound response after all Astro middleware has run:

```ts
// src/worker.ts
import handler from "@astrojs/cloudflare/entrypoints/server";
export { PluginBridge } from "@emdash-cms/cloudflare/sandbox";

const wrapped: ExportedHandler = {
async fetch(request, env, ctx) {
const response = await (handler as any).fetch(request, env, ctx);
const url = new URL(request.url);
if (!url.pathname.startsWith("/_emdash")) return response;

const csp = response.headers.get("Content-Security-Policy");
if (!csp || csp.includes("images.unsplash.com")) return response;

const patched = csp
  .replace(/img-src ([^;]*)/, "img-src \$1 https://images.unsplash.com")
  .replace(/connect-src ([^;]*)/, "connect-src \$1 https://api.unsplash.com");

const newHeaders = new Headers(response.headers);
newHeaders.set("Content-Security-Policy", patched);
return new Response(response.body, {
  status: response.status,
  statusText: response.statusText,
  headers: newHeaders,
});

},
};

export default wrapped;
```

Verified against a deployed Workers site — the admin response CSP now contains both https://images.unsplash.com in img-src and https://api.unsplash.com in connect-src, and the Featured Image Studio Unsplash picker renders thumbnails correctly.

This reinforces the case for fixing it upstream: requiring every consumer to wrap their worker entrypoint just to honor a plugin's declared allowedHosts is a lot of boilerplate for what should be automatic.