Browser Run now lets you enforce hostname restrictions on every request a session makes, and it adds a read‑only option for Live View streams. These controls give engineers a way to keep automated browsing tight to known origins and to share session playback without exposing interactive capabilities.
Guardrails: limiting hostnames
When launching a Browser Run session via Puppeteer, Playwright, or the REST API you can pass a guardrails object that contains an allowedDomains array. Only HTTP/HTTPS calls that match the listed hostnames or wildcard patterns are permitted; everything else is blocked.
import puppeteer from "@cloudflare/puppeteer";
export async function startGuardedSession(env) {
return puppeteer.launch(env.MYBROWSER, {
guardrails: {
allowedDomains: ["example.com", "*.example.com"],
},
});
}
Typical use cases include keeping a workflow confined to a single site and its subdomains, loading only vetted third‑party assets, or generating PDFs from supplied HTML while preventing external content from being fetched.
Read‑only Live View
Live View now supports a mode flag that produces a URL where viewers can watch the session in real time but cannot interact with it. Setting { mode: "readonly" } when the Live View URL is generated disables clicking, typing, navigation, and JavaScript execution for the viewer. The underlying session’s guardrails remain in effect, so the same hostname restrictions still apply.
Operational and security considerations
- Configuration hygiene: Teams must maintain an accurate list of allowed domains. Adding or removing entries requires a code change and redeployment of the worker that launches the session.
- Impact on third‑party resources: Scripts, fonts, or APIs not covered by the allowlist will be silently blocked, which can cause page‑load failures or broken functionality. Monitoring blocked requests is advisable.
- Reduced attack surface: By preventing arbitrary outbound calls, guardrails limit exposure to malicious content, data exfiltration, and supply‑chain attacks that could be introduced through uncontrolled resources.
- Collaboration safety: The read‑only Live View link lets stakeholders observe a run without the risk of accidental interaction, useful for audits, demos, or incident reviews.
- Testing and CI/CD: Guardrail settings should be exercised in test pipelines to verify that required external calls succeed and that unexpected domains are correctly rejected.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopt guardrails wherever Browser Run is used in production pipelines to enforce a known‑good network perimeter. Pair the allowlist with logging of blocked requests to catch missing dependencies early. When sharing session output, prefer the read‑only Live View mode to keep observers from influencing the run. Updating existing automation scripts to include the guardrails block is a small code change that yields measurable security and operational benefits.
