Skip to content

Security: MassingCloud/MassingViewer

SECURITY.md

Security Policy

Reporting a vulnerability

Please use GitHub private vulnerability reporting rather than opening a public issue.

We aim to acknowledge within 3 business days and to ship a fix or a documented mitigation within 90 days, coordinating disclosure with you.

Scope — what we consider a vulnerability

MassingViewer processes files that arrive from outside the organisation using it: IFC models from consultants, PDFs from subcontractors, DXF underlays, and drawing SVG. Handling of untrusted input is explicitly in scope, not treated as user error.

In scope:

  • Untrusted IFC causing memory corruption, unbounded allocation, worker escape, or code execution during parse or geometry generation.
  • Untrusted SVG reaching the DOM without sanitisation. This is the sharpest edge in the product: when the local kernel generates a drawing client-side, there is no server-side escaping in front of it, so sanitizeSvg is the primary control rather than defence-in-depth. Any path from drawing bytes to DOM that bypasses it is a vulnerability, and there is an import-graph assertion in CI intended to make that impossible.
  • Untrusted PDF causing the same classes of failure via the PDF pipeline.
  • Content Security Policy bypasses, including anything that turns wasm-unsafe-eval into general script execution.
  • Plugin sandbox escapes — a plugin reaching capabilities it did not declare, or reading data outside its granted scope.
  • Authentication or capability-gating bypass in kernel-remote: performing an operation the server should have refused, or a client-side gate being the only thing preventing it.
  • Leaking model content, file paths, GlobalIds or project names through telemetry or crash reports. Telemetry is opt-in and must never carry model data; a violation is a vulnerability, not a bug.
  • Dependency vulnerabilities reachable from a supported configuration.

Out of scope:

  • Findings that require the user to run a plugin they were warned about and explicitly granted permissions to. Sandbox escapes remain in scope; a plugin doing what the user authorised is not.
  • Denial of service from a legitimately enormous model. There are documented size limits and a "too large for this device" path; a slow load is not a vulnerability.
  • Missing hardening headers on a third party's self-hosted deployment. We ship a reference a reference nginx config and a CSP; how someone else deploys is theirs. Report defects in what we ship.
  • Anything requiring physical access to an unlocked machine, or a compromised browser or OS.
  • Social engineering, and reports consisting solely of automated scanner output with no demonstrated impact.

Supported versions

Pre-1.0.0: only the latest 0.x release. After 1.0.0, the current major and the previous minor.

What we do on our side

  • gitleaks on every push, as a hard gate with an empty ignore list.
  • CodeQL (security-extended), npm audit at high, and dependency review on PRs.
  • A CycloneDX SBOM attached to every release and signed with keyless cosign.
  • A transitive license gate that refuses copyleft and source-available dependencies.
  • No third-party runtime origins: all WASM, fonts and tiles are served from origin, asserted in CI.
  • No telemetry by default, and no crash reporting egress by default. With LocalKernel, the model never leaves the browser.

There aren't any published security advisories