CodeEmbed/frame.tsx: p5.sound never loads in iframes + postMessage uses wildcard origin

[avinxshKD]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• p5.strands
• WebGL
• DevOps, Build process, Unit testing
• Internationalization (i18n)
• Friendly Errors
• Other (specify if possible)

p5.js version

N/A - website repo issue, not p5.js core

Web browser and version

All browsers

Operating system

all

Issue :
Every time searchTerm changes, SearchProvider:

1. fetches the entire search index JSON again
2. flattens it
3. creates a brand new Fuse instance
4. runs the search

Typing "createVector" = 13 requests to the same en.json. No debounce,
no abort, no caching. The Fuse index is expensive to build and should
be created once per locale, not per keystroke.

There's also a race condition, no AbortController means a slow response
for "col" can resolve after "color" and overwrite the results.

Should be:

• fetch + build Fuse once per locale change, store in a ref
• separate effect just for running fuse.search(searchTerm)
• debounce the search (~250ms)
• AbortController on the fetch with cleanup

Easy to reproduce: open /search/, DevTools Network tab, type anything
fast and watch duplicate requests pile up.

File: src/components/SearchProvider/index.tsx

[avinxshKD]

@davepagurek @ksen0 what do you think of this? Can i work on this if this makes sense

[ksen0]

Thanks for spotting this and the reminder @avinxshKD ! the title of the issue seems to not match the body? But the description is on the website. I will transfer it there.

Typing "createVector" = 13 requests to the same en.json.

Could you share a video please? I was not able to reproduce this on beta site, main site, or dev environment. I consistently observe the searchProvider / en.json call only on pressing Enter.

There's also a race condition, no AbortController means a slow response
for "col" can resolve after "color" and overwrite the results.

This would be good to fix though I'm not able to induce it without the excessive calls to searchProvider

I'm happy for you to work on this but before PR it would be great to document more what the problem is exactly.

[rushdarshan]

Hey, just to follow up on @ksen0's note about the title/body mismatch — the body describes a legitimate SearchProvider performance issue, but the title references a separate bug in CodeEmbed/frame.tsx that isn't documented anywhere in this thread.
I looked into the frame.tsx postMessage handler and the vulnerability is real. Around line 56:

typescriptwindow.addEventListener("message", event => {
  const scriptExists = !!document.getElementById("p5ScriptTagInIframe");
  if (!scriptExists && event.data?.sender === '${cdnLibraryUrl}') {
    const p5ScriptElement = document.createElement('script');
    p5ScriptElement.textContent = event.data.message;
    document.head.appendChild(p5ScriptElement);
  }
});

event.data.sender is caller-controlled and can be spoofed. Without an event.origin check, any origin can execute arbitrary code in embedded sketches (XSS vulnerability)
Fix:

typescriptconst allowedOrigin = new URL(cdnLibraryUrl).origin;

window.addEventListener("message", event => {
  const scriptExists = !!document.getElementById("p5ScriptTagInIframe");
  if (
    !scriptExists &&
    event.origin === allowedOrigin &&
    event.data?.sender === cdnLibraryUrl
  ) {
    const p5ScriptElement = document.createElement('script');
    p5ScriptElement.id = "p5ScriptTagInIframe";
    p5ScriptElement.textContent = event.data.message;
    document.head.appendChild(p5ScriptElement);
  }
});

Should this be tracked as a separate issue so both bugs get proper attention? Happy to open a PR for the frame.tsx fix.

[avinxshKD]

Hey @rushdarshan, thanks for checking this out! I’m already working on this issue
Thanks

[avinxshKD]

@ksen0 sorry was busy with exams

Yeah sure I'll document about the problem and update you soon

[avinxshKD]

@ksen0 rechecked this today, still partly valid.

search side is still doing too much work per keystroke (refetch + rebuild fuse, no debounce, no abort), so perf/race concerns are still real.

on embed side: postMessage("*") is still there and should be tightened, but the “p5.sound never loads” part looks outdated now since sound gets passed in when enabled.

opening a PR for the search fixes + origin