监控特定JavaScript脚本发起的Web请求及外部脚本请求拦截代理方案咨询

Great question—this is a super common pain point when working with untrusted third-party scripts, and there are both partial workarounds and more robust solutions depending on your security needs. Let’s break this down:

Sort of, but it’s not a foolproof solution. You can overwrite global request APIs like fetch and XMLHttpRequest before loading the untrusted script to route their requests through your proxy. Here’s a quick example:

// Your preloaded script (runs BEFORE the untrusted script)
// Override fetch
const originalFetch = window.fetch;
window.fetch = async (...args) => {
  // Rewrite the request URL to point to your proxy
  const targetUrl = typeof args[0] === 'string' ? args[0] : args[0].url;
  const proxyUrl = `https://your-backend-proxy.com/proxy?target=${encodeURIComponent(targetUrl)}`;
  
  // Update the request with the proxy URL
  if (typeof args[0] === 'string') {
    args[0] = proxyUrl;
  } else {
    args[0] = new Request(proxyUrl, args[0]);
  }
  
  // Send the request through your proxy, optionally inspect the response
  const response = await originalFetch(...args);
  return response;
};

// Override XMLHttpRequest
const originalXHROpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(method, url) {
  const proxyUrl = `https://your-backend-proxy.com/proxy?target=${encodeURIComponent(url)}`;
  originalXHROpen.call(this, method, proxyUrl);
};

The big caveats here: #

• This only catches requests made via fetch and XMLHttpRequest. If the untrusted script uses other methods to exfiltrate data—like dynamically creating <img> tags (to send data via query params), navigator.sendBeacon, or loading resources via <script>/<link> tags—your intercept won’t catch those.
• Clever obfuscated scripts can bypass your overrides. For example, if a script grabs a reference to the original fetch before your script runs, or uses Object.getOwnPropertyDescriptor to access the unmodified API, your proxy won’t work.

If you want reliable interception and strong security, these approaches are far better:

Service Worker (Most Reliable for Request Interception) #

Service Workers act as a network proxy between the browser and the internet, and they can intercept all requests from your origin—no matter which script initiated them. They run in a separate thread, so they don’t block your main page or the untrusted script.

How to set it up: #

1. Register the Service Worker in your main page before loading any untrusted scripts:

// Main page script
if ('serviceWorker' in navigator) {
  window.addEventListener('load', async () => {
    await navigator.serviceWorker.register('/service-worker.js');
  });
}

2. In your service-worker.js, intercept and rewrite requests:

self.addEventListener('fetch', (event) => {
  const requestUrl = new URL(event.request.url);
  
  // Skip requests for your own domain if needed, or target only third-party requests
  if (requestUrl.host !== self.location.host) {
    const proxyUrl = new URL('https://your-backend-proxy.com/proxy');
    proxyUrl.searchParams.set('target', event.request.url);
    
    // Clone the request to modify it (requests are one-time use)
    const proxyRequest = new Request(proxyUrl, {
      method: event.request.method,
      headers: event.request.headers,
      body: event.request.body,
      mode: 'cors',
      credentials: 'omit'
    });
    
    // Forward the request to your proxy and return the response
    event.respondWith(fetch(proxyRequest));
  }
});

Pros & Cons: #

• ✅ Catches every type of request (fetch, XHR, image/script loads, sendBeacon, etc.)
• ✅ Works even if the untrusted script uses obfuscated or low-level APIs
• ❌ Requires HTTPS (except for localhost during development)
• ❌ Has scope limitations (can only intercept requests for files in its directory or subdirectories)

Sandboxed Iframes (Most Secure Isolation) #

Instead of letting the untrusted script run directly in your main page, load it inside an <iframe> with the sandbox attribute to lock down its capabilities. You’ll control all network requests by having the iframe send messages to your main page via postMessage, which then routes the request through your proxy.

Example setup: #

1. Main page:

<iframe id="script-sandbox" sandbox="allow-scripts allow-postMessage" src="/sandbox.html"></iframe>

<script>
  // Listen for request messages from the sandbox
  window.addEventListener('message', (event) => {
    // Verify the message comes from your sandbox
    if (event.source === document.getElementById('script-sandbox').contentWindow) {
      if (event.data.type === 'proxy-request') {
        // Forward to your backend proxy
        fetch(`https://your-backend-proxy.com/proxy?target=${encodeURIComponent(event.data.url)}`, {
          method: event.data.method,
          body: event.data.body
        })
        .then(res => res.text())
        .then(responseData => {
          // Send the response back to the sandbox
          event.source.postMessage({
            type: 'proxy-response',
            data: responseData
          }, '*');
        });
      }
    }
  });
</script>

2. Sandbox page (sandbox.html):

<script>
  // Override fetch/XHR in the sandbox to send messages instead of direct requests
  window.fetch = (url, options = {}) => {
    return new Promise((resolve) => {
      // Send request details to the main page
      window.parent.postMessage({
        type: 'proxy-request',
        url,
        method: options.method || 'GET',
        body: options.body
      }, '*');
      
      // Listen for the response from the main page
      const responseListener = (event) => {
        if (event.data.type === 'proxy-response') {
          resolve(new Response(event.data.data));
          window.removeEventListener('message', responseListener);
        }
      };
      window.addEventListener('message', responseListener);
    });
  };

  // Load the untrusted script
  const untrustedScript = document.createElement('script');
  untrustedScript.src = 'https://untrusted-script.com/script.js';
  document.body.appendChild(untrustedScript);
</script>

Pros & Cons: #

• ✅ Full isolation: the untrusted script can’t access your main page’s DOM, cookies, or local storage (unless you explicitly allow it)
• ✅ No way to bypass the proxy—all network access is blocked by the sandbox
• ✅ Works over HTTP and HTTPS
• ❌ Adds minor communication overhead between the iframe and main page
• ❌ Some scripts may break if they rely on access to the parent page’s context

Combination Approach #

For maximum security and reliability, use both a Service Worker and a sandboxed iframe. The sandbox prevents the script from accessing your site’s data directly, and the Service Worker acts as a fallback to catch any unintended requests that might slip through the sandbox.

内容的提问来源于stack exchange，提问作者Bambadigatta Giligiligitta