Allow remote content in local CEF browsers with approved domains

[FileEX]

Is your feature request related to a problem? Please describe.

Currently, MTA does not allow local browser instances to access remote content. This is fine for preventing local browsers from loading arbitrary remote pages, but the restriction also prevents them from loading remote assets such as images, even when the domain is explicitly allowed through requestBrowserDomains.

For example, when building a UI with React, I need to execute my own JavaScript through executeBrowserJavascript. A vehicle or object browser is a simple example: it may contain several thousand images that can be displayed almost instantly by a regular browser, but fetching all of them through fetchRemote would take a significant amount of time. Bundling thousands of images with the resource is also impractical.

Describe the solution you'd like

I propose slightly relaxing this restriction so that local browsers can load remote resources, such as images, when the corresponding domain has been explicitly allowed through requestBrowserDomains.

This would still prevent local browsers from navigating to arbitrary remote pages while allowing them to use approved remote assets. It should not introduce a meaningful security risk, since loading an image or other static resource does not provide the page with capabilities beyond what could already be done through the browser's developer console.

Describe alternatives you've considered

No response

Additional context

No response

Security Policy

• I have read and understood the Security Policy and this issue is not about a cheat or security vulnerability.

[guibzo]

I recently came across a very similar problem.

I integrated an R2 bucket into my server, only to find out that local CEF browsers can't load assets directly from it, even with the domain explicitly allowed. I ended up having to download them through Lua, cache them locally and then serve them to the frontend, which is an awkward and inefficient workaround.

What I don't fully understand is where the intended security boundary is here. To what extent does blocking remote access from local CEF actually reduce the attack surface, rather than mostly moving that boundary to Lua?

You can still do:
CEF -> Lua -> external service -> CEF
So the external interaction is still possible, just through an extra layer.

I understand that local CEF is privileged because it can communicate with Lua, but wouldn't it make more sense to treat remote network access and access to the MTA bridge as separate capabilities? This is closer to how systems like FiveM approach NUI: the browser can use normal web APIs and remote resources, while interaction with the game happens through an explicit bridge/callback layer that should be treated as untrusted and validated accordingly.

That would also cover a wide range of very common use cases such as buckets/CDNs, pagination, filtering, dashboards and external APIs without requiring Lua to act as a proxy for everything, which is much more verbose and inneficient.

Regular browsers also don't require user permission just to execute JavaScript or access the network; security is instead enforced through boundaries such as origins, CORS, CSP, sandboxing and explicit permissions for sensitive capabilities.

This feels even more relevant now that modern MTA CEF is much better optimized and many servers keep a single browser instance alive and reuse it for large parts of their gamemode UI, making it more viable to largely adopt its usage in big servers.