docs/security/handling-messages-from-web-content.md

# The browser process should not handle messages from web content

Sometimes features are proposed in which the Chrome user interface (in the
browser process) handles messages directly from web content (JavaScript, HTML
etc.). For example, this could be done using the `postMessage` APIs which have
been put in place for Android WebView apps. This is not allowed, because:

* Overall system security relies on simple and predictable security properties.
  Adding extra message channels causes complexity, non-discoverability and
  non-predictability.
* Chrome's security strategy relies on isolating web content using sandboxed
  renderer processes and site isolation. Any communication outside of that
  renderer process presents a risk of a sandbox escape. All such communication
  has to be via Mojo such that the `mojom` interface definition files go through
  our [IPC security review process](mojo.md) (and will benefit from other future
  Mojo security improvements).
* Websites are untrustworthy. TLS can’t guarantee the identity of a website —
  even pinning has limits — and so you must assume any messages from websites
  are malicious. Processing such messages in the browser process in C++ is
  likely a violation of the [Rule of Two](rule-of-2.md) and is extremely
  dangerous.
* Even if you can comply with the Rule of Two (for example by using a safe
  language) it's simply difficult to produce robust APIs that are safe against
  malicious data: the open web platform API review process is designed to flush
  out any concerns. Any APIs or functionality accessible to web content
  therefore needs to go via that process to give the best chance of spotting
  danger.
* There are non-security concerns: It does not comply with the spirit of an open
  web platform which should be equally available on all user agents.

Historically, there have been some instances where this rule has been violated
and complexity has resulted. For example, the U2F short-cut caused long-term
pain for the entire industry in moving to the open standard WebAuthn
replacement.

In order to support WebView, WebLayer, and CCT, APIs exist in Chrome to
establish web message channels between the embedding application and web page.
These exist only to support these "embedding the web" scenarios, which are often
used to build site- or purpose-specific browsers. General browser features
should not use them because of the reasons stated above.