HTML preview allows `rpf.io` scripts but browser blocks them with CORS

[adrian-rpf]

Expected behaviour

• It should be possible to load external scripts that are loaded via the rpf.io domain.
• If external scripts are supported, they should load without an unexpected browser CORS failure.
• If external scripts are not supported, the runner should block them intentionally and report that clearly.

Actual behaviour

• The HTML preview allows https://rpf.io/ as an external source, but when a project includes <script src="https://rpf.io/piratetalk"></script>, the browser blocks it with a CORS error.
• This creates a mismatch between the app’s allowlist and actual runtime behavior.

Steps to reproduce

1. Open http://localhost:3011/web-component.html.
2. Load or paste an HTML project containing <script src="https://rpf.io/piratetalk"></script>. Example
3. Click RUN button
4. Check the browser console.
5. Observe: Access to script at 'https://rpf.io/piratetalk' from origin 'http://localhost:3011' has been blocked by CORS policy...

Additional context

• src/utils/externalLinkHelper.js includes https://rpf.io/ in allowedExternalLinks.
• src/components/Editor/Runners/HtmlRunner/HtmlRunner.jsx rewrites src attributes and unconditionally adds crossorigin, including on <script> tags.
• That causes the browser to enforce CORS on external classic scripts that may otherwise have loaded.

Suggested fixes:

• Potential: Only add crossorigin for media/assets that need it, not <script> tags but this may cause more CORS issue with Google hosted jQuery which is currently hidden.

Risks

• Removing crossorigin from <script> tags may make third-party scripts execute instead of fail.
• Would increase the security risk of running remote untrusted code.

Screenshots and Videos

Once a fix is in, include a video on how to test it below

We're exploring using videos to demonstrate how to test new features, to improve our testing process.

[cocomarine]

Findings

The dev server as well as prod set below headers:

cross-origin-embedder-policy: require-corp
cross-origin-opener-policy: same-origin

This means that responses from rpf.io must have CORP (Cross-Origin-Resource-Policy: cross-origin) and also Access-Control-Allow-Origin: * (due to the crossorigin included in <script> tag in HtmlRunner.jsx.

Upon inspection, the cross-origin headers were missing from the rpf.io while they were present in the final destination after redirect:

> curl -I -L https://rpf.io/piratetalk 
# rpf.io/piratetalk 
HTTP/2 301
date: Tue, 07 Apr 2026 14:35:04 GMT
content-type: text/html; charset=UTF-8
location: https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js
server: cloudflare
x-robots-tag: noindex
nel: {"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}
cf-cache-status: DYNAMIC
report-to: {"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=Ja9G1rhAxzc3yEa8o3Z5zlPWt2SKSryduFnz%2BoGgylfhjsIHBf%2BnHQL4Hp9iZTTMHjJUXvH4isUJut%2F9svSwac7etWvnEg98SXUv3LrwcSGXcaXsikQqha8%3D"}]}
cf-ray: 9e89c1bb0d24ba61-LHR
alt-svc: h3=":443"; ma=86400

# final destination after redirect
HTTP/2 200
accept-ranges: bytes
access-control-allow-origin: *
content-security-policy-report-only: require-trusted-types-for 'script'; report-uri https://csp.withgoogle.com/csp/hosted-libraries-pushers
cross-origin-resource-policy: cross-origin
cross-origin-opener-policy: same-origin; report-to="hosted-libraries-pushers"
...

Communicated this to wider team and @grega and @DanielBrierton helped me with it.
New headers tested with a dummy rpf.io link in Cloudflare and it gave no CORS errors.

Fix

These headers were applied to rpf.io using terraform: https://github.com/RaspberryPiFoundation/terraform/pull/1317

> curl -I https://rpf.io/piratetalk
HTTP/2 301
date: Wed, 08 Apr 2026 10:05:36 GMT
content-type: text/html; charset=UTF-8
location: https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js
server: cloudflare
x-robots-tag: noindex
cross-origin-resource-policy: cross-origin
...
access-control-allow-origin: *
...

Relevant slack thread: https://raspberrypifoundation.slack.com/archives/G01QT0AF1LK/p1775573601711179

[cocomarine]

Note that normal cache busting (eg. Ctrl + Shift + R) doesn't clear the 301 redirect. To see the effect of the new headers, you need to clear the HTTP cache either by disabling cache in the DevTool -> Network tab or clear the browser data in Chrome settings.

[mwtrew]

Looks good!