Guide

PAC file security

PAC files are a high-value attack target. Understand the risks before deploying.

A compromised or spoofed PAC file can silently redirect all browser traffic — including authenticated sessions — through an attacker-controlled proxy. Take PAC file security seriously.
  • 🔒
    Serve PAC files over HTTPS. The original PAC spec used plain HTTP. A man-in-the-middle attacker on the same network can intercept an HTTP PAC request and inject a malicious PAC file, silently redirecting all your traffic. Always serve PAC files from an HTTPS URL.
  • 🔒
    WPAD auto-discovery is inherently risky. WPAD uses DHCP and DNS to locate your PAC file automatically. A rogue DHCP server or DNS poisoning attack can serve any machine on the network a malicious PAC URL. Disable WPAD auto-discovery in environments where you don't control the network, and configure the PAC URL explicitly.
  • 🔒
    Never embed credentials in PAC files. PAC files are served as plain text and cached in the browser. Never include proxy usernames, passwords, API keys, or any other secrets in your PAC file.
  • 🔒
    Restrict PAC file access. Your PAC file server should only be accessible from internal networks. A publicly accessible PAC file reveals your internal network topology, proxy addresses, and IP ranges to anyone who fetches it.
  • 🔒
    HTTPS path stripping is a known limitation. For HTTPS URLs, the browser only passes the scheme, host, and port to FindProxyForURL — the path and query are stripped before PAC evaluation. Do not rely on URL path matching for security-critical routing decisions involving HTTPS traffic.
  • 🔒
    PAC files can be weaponised via DNS rebinding. A malicious PAC file could call dnsResolve() on attacker-controlled domains to map your internal IP space, or use isInNet() to probe your network topology. Keep PAC evaluation sandboxed and never serve third-party PAC files.