AgentiaPT Vela browser/sanitizer testing
The principle for Vela security work: a defense is only proven once a payload is fed through the real code and observed to be neutralized. Reading source is not proof. This skill gives you the two layers needed to do that here.
Environment facts (this remote-execution container)
- Prebuilt Chromium exists under
/opt/pw-browsers/chromium-*/chrome-linux/chrome(and aheadless_shell). It is part of the image, so it survives across sessions. - Playwright's browser-download CDN is blocked —
npx playwright installfails. Do NOT try to download a browser. Launch the existing one viaexecutablePathand ignore Playwright's version pin:
(const { chromium } = require("./node_modules/playwright"); // or playwright-core const b = await chromium.launch({ executablePath: "/opt/pw-browsers/chromium-XXXX/chrome-linux/chrome", args: ["--no-sandbox"] });scripts/browser-probe.cjsauto-discovers the path — don't hardcode the build number.) registry.npmjs.orgis reachable (200); general web is blocked (403). Sonpm install jsdom playwrightworks, but the React/Babel/cdnjs CDNs thatapp/local.htmlpulls are blocked → the full Vela app will not boot from CDN in the browser. Test the rendered sinks (the markup Vela emits) directly, or vendor react/react-dom/@babel-standalone intonode_modulesand rewrite the<script src>tags to local paths if you truly need the whole app.node_modulesis gitignored and ephemeral. On a fresh container, restore deps:(cd "$REPO" && npm install --no-audit --no-fund --ignore-scripts jsdom playwright)- For outbound-request / exfil tests there is no need to reach the internet: point
payloads at a local collector (a throwaway
http.createServeron127.0.0.1) and check its hit log. Both scripts below do this for you.
Layer 1 — real sanitizers (static): scripts/sanitizer-harness.cjs
Loads the actual validateAndSanitizeDeck / sanitizeSvgMarkup / sanitizeStyle /
scrubColorFields / sanitizeUrl from app/parts/part-imports.jsx into jsdom.
node .claude/skills/vela-browser-test/scripts/sanitizer-harness.cjs # self-test
const H = require("<repo>/.claude/skills/vela-browser-test/scripts/sanitizer-harness.cjs");
const out = H.validateAndSanitizeDeck(rawDeck); // full local-mode load path (fail-closed)
H.findLeaks(out); // [] = nothing dangerous survived as a string
H.svgNetworkRefs(H.sanitizeSvgMarkup(markup)); // re-parsed exactly like dangerouslySetInnerHTML
Caveat: findLeaks/svgNetworkRefs are deliberately over-eager string matchers.
They flag url()/schemes even in attributes the browser never fetches from
(e.g. SVG filter in/in2/result/values) and are blind inside base64
data: URIs. A "leak" here means go confirm it in Layer 2, not "confirmed bug".
Layer 2 — real browser (dynamic): scripts/browser-probe.cjs
Renders HTML in the real Chromium and reports which vectors actually executed or
fetched (via a live collector). This is what distinguishes a true bug from a
false positive — most notably the browser's secure static mode: SVG/HTML
loaded via <img> or CSS background-image runs with scripting disabled and
external loads blocked, so data:image/svg+xml,<svg> and
data:text/html,<script>…> in those sinks are inert.
node .claude/skills/vela-browser-test/scripts/browser-probe.cjs --self-test
# Custom page (use the literal token __COLLECTOR__ for the attacker origin):
node .claude/skills/vela-browser-test/scripts/browser-probe.cjs /tmp/page.html
--self-test is also a regression gate for the core invariant: it asserts the
Vela sinks (<img src>, CSS background-image, branding logo) stay inert while
three controls (inline <svg onload>, direct external <img>,
<object type=image/svg+xml>) DO fire — proving the probe isn't blind.
Established results (June 2026 audit, real Chromium): all image.src / slide.bgImage
/ branding.logo data: payloads are inert; the only active SVG contexts are
inline (dangerouslySetInnerHTML → both routed through sanitizeSvgMarkup) and
<object>/<embed>/<iframe> (Vela never uses these for deck content). The
invariant to protect on future changes: never render deck-controlled SVG in an
active context. Re-run --self-test after any change to image/bg/logo/SVG
rendering or the sanitizers.
Full end-to-end against the live server (optional)
To test the actual serve.py → STARTUP_PATCH pipeline, boot a server on a temp decks folder and point the probe at a vendored-deps build (CDN is blocked):
python3 tools/vela-dev/scripts/serve.py /tmp/decks --port 3031 --no-open --no-auth --channel-port 0 &
Without vendored react/babel the page won't hydrate, so for sink-level questions
prefer Layer 2 with the exact emitted markup; use the live server mainly for the
server-side surface (path traversal, auth, origin/CSRF, script-context escaping)
which is testable with plain curl.