WebGPU gives web content access to GPU memory and compute units. The browser validates shader modules and isolates the API from platform graphics details, but the application still has to decide whether a page should be allowed to run an expensive or unfamiliar GPU workload in the first place.

The browser handles implementation safety

The WebGPU specification requires implementations to validate shader modules before translation or transformation. It describes memory safety work, driver coordination, and conformance testing as part of the browser and GPU vendor relationship. A page does not receive a raw pointer to GPU memory or direct access to the operating system's graphics driver.

That does not mean WebGPU is harmless. The specification notes that malicious sites can use general-purpose computation for purposes that do not benefit the user. It also acknowledges that the browser cannot reliably distinguish a valid compute workload from an abusive one. A site can consume GPU time, heat a device, drain a battery, or create a denial-of-service condition without exploiting a memory-safety bug.

The security model is therefore split. The browser is responsible for preventing memory corruption and enforcing the WebGPU API contract. The application is responsible for deciding which origins receive the feature, what data the GPU can process, and how resource use is bounded.

Treat GPU access as a delegated feature

Do not enable GPU-heavy content on trusted origin pages that also hold sensitive sessions. Use a separate origin for untrusted or user-generated GPU workloads. Keep authentication cookies host-scoped and avoid placing administrative APIs on the same origin as an experiment with third-party shaders.

The cross-origin isolation model is relevant when an application shares Agent Cluster state or uses APIs that require isolation. WebGPU itself is not a substitute for origin separation. A frame that cannot read another origin's DOM can still consume the same device's GPU resources.

If the application does not need WebGPU, disable it at the browser policy layer and avoid shipping a feature detector that grants it to every page. If a specific feature needs it, require a user action and explain why the page needs GPU acceleration. Do not treat the presence of the API as consent to run an arbitrary workload.

Bound the workload

Set a maximum input size before creating buffers and textures. Reject shaders that exceed the supported limits or request resources outside the application's plan. Use device-loss handlers and cancellation paths so a user can stop a computation. Avoid launching a compute job from a background tab without a visible state and a hard time limit.

Keep secrets out of GPU-visible buffers. If the workload processes sensitive data, the application still needs encryption, access control, and memory-lifetime rules. A shader that is correct for a public image may be inappropriate for a document containing account information.

Log the feature, device class, and failure state without recording full buffer contents. GPU diagnostics can be large and may contain user data. A support team needs to know whether allocation failed, the device was lost, or a shader validation error occurred. It does not need the raw data that caused the failure.

Handle driver diversity

The browser may use different GPU drivers across operating systems and device models. A workload that is stable on one machine can trigger a device loss or produce a different timing profile on another. Test the actual production hardware classes, not only the developer laptop.

Keep a fallback path that works without WebGPU. A fallback is useful for availability, but it must not silently downgrade a security property. If the fallback uses a server-side GPU service, the data leaves the browser and needs its own authorization and retention controls.

A reasonable deployment boundary

Use WebGPU for a known feature on a dedicated origin, with input limits, cancellation, device-loss handling, and a tested fallback. Keep sensitive application pages on origins that do not accept third-party shaders. Monitor resource use and errors, and review new shader packages as code rather than as opaque web assets.

The browser can prevent many implementation failures, but it cannot decide whether a GPU workload is appropriate for a user or a business. That decision remains with the application owner. The useful control is to make GPU access an explicit feature with a narrow origin and a bounded workload, not an invisible capability available to every page.

References