Skip to content

Security: scarp-lang/scarp-playground

Security

SECURITY.md

Security policy

Scarp Playground is experimental. Browser user programs run via the official interpreter compiled to WebAssembly, in a disposable Web Worker.

The worker is terminated on a 12-second deadline. Source bytes, virtual files, imports, interpreter work, calls, output size and allocation budgets are limited, but the browser does not enforce an independent strict memory cap.

Do not paste passwords, tokens, private code or sensitive information into untrusted sites. This project has no remote code execution service and should not add one without dedicated review.

Please open a non-sensitive security report through the repository's GitHub security advisory interface rather than a public issue.

Reporting, triage and release response

For potentially exploitable vulnerabilities, prefer the repository's private GitHub security advisory reporting workflow rather than a public issue. Include a minimal reproduction, affected browser/compiler revisions, expected vs observed behavior and impact; remove any secrets or personal data first. For non-sensitive correctness or accessibility bugs, a normal GitHub issue is appropriate. Avoid publishing a working exploit for an unpatched issue.

The maintainers should reproduce and scope the issue, mark affected Playground and pinned compiler revisions, evaluate exposure, prepare a fix with a bounded regression test, run all existing browser/Rust tests and coordinate public disclosure with the reporter. For urgent issues affecting the hosted preview, maintainers should consider disabling affected functionality or the deployment rather than relying on a future compiler release. Publish a security advisory and identify corrected tags or a fixed deployment once remediation is verified. No response-time SLA or hardened isolation guarantee is asserted.

Dependency and build-chain review

npm run verify:locks checks npm tarball integrity/provenance, manifest-lock consistency, Cargo registry checksums and the reviewed immutable Scarp v0.0.6-alpha.2 source commit. npm run test:locks verifies that registry substitution, removed integrity and compiler pin drift are rejected. CI also runs npm audit --audit-level=high against the complete locked npm build/development graph before packaging. See dependency integrity and advisory review.

These checks cannot prove that a checksummed package is safe, that an upstream compiler release is free of vulnerabilities, or that Rust crates have passed a RustSec advisory scan. The separately CI-gated RustSec locked graph scan checks known Rust advisories; independent source review, native tooling and all other issue #3 threat-model gates remain open.

Browser memory-pressure baseline

A real Chromium E2E regression now observes Linux process RSS (which may double-count shared pages), main-page JS heap (which excludes Worker/WASM heap) and exact compiler Worker lifecycle during bounded failures and recovery. The CI artifact is diagnostic, not a fixed heap ceiling or a promise that an OS-level out-of-memory condition cannot crash the page. See browser memory-pressure observations. The hostile-source, browser OOM/panic and independent review requirements in security issue #3 remain open.

Input and result protocol checks

The Rust bridge rejects raw JSON requests larger than 1 MiB before deserialization. The browser also validates a 128 KiB total source budget. The disposable Worker rejects compiler replies larger than 8 MiB of raw JSON text before parsing them. Worker and main-thread checks enforce a combined 1 MiB stdout/stderr UTF-8 limit and validate schema-1 diagnostic locations before rendering. Invalid worker messages and cloning failures produce controlled errors and worker termination.

Production browser Content Security Policy

The GitHub Pages production build enforces a restrictive Content-Security-Policy meta tag inserted before application scripts. It denies remote scripts, inline JavaScript, unrestricted eval, remote Worker origins and cross-origin network connections. Rust/WASM requires the narrowly scoped wasm-unsafe-eval exception, and Monaco requires inline styles; these are not blanket permissions for inline JavaScript or arbitrary dynamic code evaluation.

This is a static-hosting constraint, not a security boundary or full HTTP-header policy. In particular, CSP meta cannot enforce frame-ancestors, sandbox or HTTP report-only reporting. The Vite dev server intentionally does not use the production policy. See the CSP review for directives and tests.

Cross-operation compiler Worker capacity

The Run, Check and Go to Definition browser clients share a single active compiler Worker slot. Starting a different valid operation cancels the previous one and terminates that Worker before allocating another. Aborts, timeouts and failed starts release capacity; stale worker replies are ignored. This limits concurrent WASM resource pressure but does not bound the memory used by one Worker or guarantee survival of a browser OOM.

Reproducible compiler mutation regressions

The native bridge runs a fixed-seed mutation corpus through the real pinned Scarp compiler for Execute, Check and Go to Definition. It rejects panics, malformed JSON replies, output-budget violations and any partial stdout/stderr on a failed operation. The CI-gated Chromium regression additionally sends malformed source through real WASM and verifies successful subsequent execution. Read the reproduction instructions and its explicit limitations. This is not coverage-guided fuzzing or a physical browser-process memory limit.

Resource-pressure recovery and regression tests

The official Rust/WASM interpreter is tested against its configured output statement, buffered-output, call-depth and deterministic work ceilings, plus bounded text, vector and nested-module stress scenarios. Tests assert that failed evaluations produce no partial stdout/stderr and that a subsequent program can execute normally. A browser-worker constructor failure returns a controlled error, and fake-timer tests verify that the 12-second deadline terminates the previous worker. The real Chromium tests exercise the actual compiler, not synthetic responses. See resource-pressure methodology.

These are not a hardened sandbox. No independent process memory cap, out-of-memory recovery guarantee, or browser-engine isolation guarantee is provided. The 12-second timeout cannot stop arbitrary synchronous allocations. Issue #3 continues to track CSP, memory stress, dependency and independent security reviews.

There aren't any published security advisories