This mechanism exists mainly as a way for font creators to control which websites can access their possibly copyrighted and licensed products.
As MDN puts it:
... Web Fonts (for cross-domain font usage in @font-face within CSS), so
that servers can deploy TrueType fonts that can only be cross-site
loaded and used by web sites that are permitted to ...
Referer is a really old HTTP request header which is much much older than the idea of a Referrer Policy. In fear of breaking things the default behavior is the traditional one, i.e. nearly always on. Keeping the old default even if it is considered bad is a theme which can be seen with many security and privacy improvements in web development, for example ...
I can see two options here.
The first is to just delegate the crypto part to a server, and communicate with it via a HTTP API. This wouldn't involve the JS web crypto API, and perhaps it would violate some of your design criteria.
Second option for communicating across origins is Window.postMessage(). It let's you send messages and receive responses ...
The same origin policy allows:
Cross-origin writes are typically allowed. Examples are links, redirects, and form submissions. Some HTTP requests require preflight.
Cross-origin embedding is typically allowed. (Examples are listed below.)
Cross-origin reads are typically disallowed, but read access is often leaked by embedding. For example, you can ...
DNS spoofing doesn't change which domain a victim reaches, but rather which IP it thinks the domain points to. As an example, if I try to fetch the DNS A record for http://example.com, and an attacker performs DNS spoofing, they can falsify the DNS A record contents in the response and point me to an attacker-controlled IP address. My browser still shows ...
It sounds like what you're saying is that an app development framework supports injecting arbitrary scripts into webviews displaying arbitrary origins. This is nothing new; they all do this. While a malicious app written using such a framework could potentially steal sensitive information, there are several things you need to consider:
By default, the app ...
You have a few options, in random order:
1. Different authentication schemes
Web browsers frequently authenticate by session identifiers in cookies. Many native apps attach auth tokens directly in the request header (in an Authorization header or some other custom header key). CSRF is generally only a concern when authentication comes up with cookies. ...
The Content-Security-Policy connect-src directive is what you are after. This directive restricts what hosts the fetch method can send requests to.
Here is a minimal proof of concept:
<meta http-equiv="Content-Security-Policy" content="connect-src 'self'">