Within a docker container, mitmproxy can sit filtering network traffic by URLs, rather than IP and port. Ignore in this example only one URL is allowed.

In pyproject.toml,

[project.scripts]
webdriver_urls_filter = "mypackage.somefolder.mitmproxy_runner:main"

In mypackage.somefolder.mitmproxy_filters,

import re
from typing import TYPE_CHECKING

from mitmproxy import ctx

if TYPE_CHECKING:
    from mitmproxy import http


def request(flow: "http.HTTPFlow") -> None:
    """Run this proxy.

    :type flow: mitmproxy.http.HTTPFlow
    """
    url = flow.request.pretty_url

    # Rather than exact, interested in limiting the base URL
    ALLOWED_PATTERN = re.compile(r"^https://github/\.com/myorg/myrepo/releases/download/v1\.2\.3/.*$")
    
    # Check if URL matches the allowed release pattern
    
    try:
        if ALLOWED_PATTERN.match(url):
            ctx.log.info(f"Download allowed: {url}")
        else:
            ctx.log.error(f"Download blocked: {url}")
            flow.kill()
    except Exception as e:
        # FAIL SECURE: If inspection fails, kill the connection to prevent bypass
        ctx.log.error(f"Script error, blocking flow: {e}")
        flow.kill()

In mypackage.somefolder.mitmproxy_runner,

from mitmdump import DumpMaster
from mitmproxy import options

from . import mitmproxy_filters  # addon module

def main() -> None:
    """Rather than calling `mitmdump -s myscript.py`."""
    opts = options.Options(listen_port=8080)
    master = DumpMaster(opts)

    if hasattr(mitmproxy_filters, 'addons'):
        # explicit format which defines a class then appends an instance to
        # :code:`addons = []`
        master.addons.add(*mitmproxy_filters.addons)
    else:
        # Module itself acts as addon
        master.addons.add(mitmproxy_filters)
    
    master.run()

The docker container has one network proxy which has web access. Everything else has no web access instead traffic is directed thru the proxy. The proxy calls, webdriver_urls_filter.

Had to research how to go about running untrusted code safely.

In-process there are actions that can be taken to deter mock.patch, but it wouldn't defeat a determined adversary. A subprocess isn't a sufficient security layer although it would prevent mock.patch a module.

To deter a determined adversary, recommend to use Docker or Firecracker MicroVMs.

So glad we are having this conversation. Instead of jumping in with a fix that is not actually effective.