Security Restrictions for WebRTC getDisplayMedia

The WebRTC getDisplayMedia API enables web applications to initiate screen-sharing sessions directly from the browser. However, because sharing a screen can expose highly sensitive personal or corporate data, browsers enforce rigorous security mechanisms to protect users. This article explains the core security restrictions surrounding the getDisplayMedia API, detailing user activation requirements, permission protocols, context limitations, and security policies designed to prevent unauthorized surveillance.

Transient User Activation Required

An application cannot programmatically trigger screen sharing without direct user interaction. The getDisplayMedia() method must be called in response to a transient user gesture, such as a mouse click or a keypress. If a script attempts to call this API automatically upon page load or via a background timer, the browser will block the request and throw an Allowed by User Activation or NotAllowedError exception. This prevents malicious sites from silently launching screen-capture prompts.

Secure Contexts Only (HTTPS)

To prevent man-in-the-middle attacks where an attacker could intercept captured screen data, the getDisplayMedia API is restricted to secure contexts. This means the API is only available to web pages loaded over https:// or localhost. If a website is served over insecure http://, the navigator.mediaDevices.getDisplayMedia property will be undefined.

Browser-Controlled Permission and Selection UI

When getDisplayMedia is successfully invoked, the browser takes complete control of the user interface. * No Pre-Selection: The calling web application cannot pre-select or force the sharing of a specific window, tab, or screen. * User Choice: The user is presented with a native browser dialog where they must explicitly choose what to share: their entire screen, a specific application window, or a single browser tab. * No Bypass: There is no programmatic way for an application to bypass this dialog or auto-approve the permission request.

Permissions Policy Integration

Websites can control whether embedded third-party frames (iframes) are allowed to use screen capture. This is managed using the display-capture directive in the HTTP Permissions-Policy header or the allow attribute on an iframe.

<iframe src="https://example.com" allow="display-capture"></iframe>

If a parent document does not explicitly grant the display-capture permission to an iframe, any call to getDisplayMedia inside that iframe will fail instantly.

Persistent Visual Indicators

Once screen sharing begins, browsers are required to display persistent, prominent visual indicators to the user. This typically includes: * A notification bar at the bottom of the screen indicating that a site is sharing the screen, complete with a prominent “Stop Sharing” button. * A flashing or colored icon in the browser tab containing the active stream.

These indicators are controlled by the operating system or the browser chrome, meaning the web application cannot hide, alter, or obscure them.

Safeguards Against Self-Capture and Infinite Feedback

Capturing the tab that is currently displaying the capture stream can cause a confusing “infinite mirror” effect and accidentally leak private application data. Modern implementations of getDisplayMedia support configuration constraints to mitigate this: * selfBrowserSurface: Can be set to exclude to prevent the browser from offering the current tab as a sharing option. * preferCurrentTab: Allows applications to guide the user toward sharing the current tab, but only under strict user-controlled circumstances.