A Proxy Auto-Config file tells a browser or other client how to choose a proxy for a given destination. It is evaluated as script logic, so a malicious or altered file can redirect traffic through an attacker-controlled proxy or bypass inspection. Protect it with access control, integrity checks, and change monitoring.
How a PAC file decides where traffic goes
A Proxy Auto-Config file is a small JavaScript-based decision file that returns a proxy choice for each request. The browser or client calls a function such as FindProxyForURL, passes in the destination, and uses the returned instruction to decide whether to send traffic direct or through one or more proxies. That makes the file a policy control, not just a static setting.
Because the PAC logic runs on every relevant request, it can express routing rules that are more precise than a single proxy setting. Teams often use it to split internal and external traffic, send some destinations through a secure web gateway, or bypass the proxy for trusted local resources. The same flexibility is also why PAC files need careful review: a small logic change can alter large amounts of client traffic.
When the PAC file is managed through a web gateway or filtering policy, the surrounding control plane matters as much as the script itself. NHIMG’s Secure Web Gateway and Web Filtering Guide covers PAC files, proxy paths, bypass risks, and logging in the context of web filtering and cloud SWG.
What can go wrong when the file is altered or misused
A PAC file is security-sensitive because it directly influences trust boundaries. If an attacker changes it, or if a client accepts an untrusted copy, the attacker can steer traffic through a proxy they control, bypass inspection for selected destinations, or shape how the browser reaches sensitive services. That can expose credentials, session traffic, and destination metadata.
This risk is strongest where PAC delivery is centralized or automatic, because every client that consumes the file may inherit the same bad routing decision. A malformed rule can also create service disruption by sending traffic to an unreachable proxy or by producing inconsistent routing across users, devices, or networks.
As a control baseline, a PAC file should be treated like other configuration that affects request handling and trust. NIST SP 800-53 Rev 5 Security and Privacy Controls provides the relevant control families for access control, integrity, auditability, and configuration management, which map directly to PAC file handling.
How to protect PAC files in practice
Protect the file with the same discipline you would apply to any script that can redirect enterprise traffic. Store it in a controlled location, restrict who can edit it, and verify that clients fetch it only from trusted sources. If delivery is automated, make sure the transport path and the hosting location are both protected from tampering.
Use integrity checks and change monitoring so a PAC update is visible before it quietly changes routing behaviour at scale. The key operational question is not just whether the file works, but whether the current file is the file you intended clients to use. If you cannot answer that quickly, the control is too weak.
Defensive web routing also benefits from secure-by-default configuration principles. CISA Secure by Design is useful here because it reinforces the expectation that exposure paths should be predictable, restricted, and resistant to silent abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | PAC files are configuration items that alter client routing and require controlled change management. |
| CM-6 — Configuration Settings | PAC logic is an enforceable configuration setting that can redirect or bypass traffic controls. | |
| SI-7 — Software, Firmware, and Information Integrity | A modified PAC file can change traffic handling, so integrity assurance is central to trust. | |
| Recommendation — Control PAC file changes through approved baselines and review any routing logic updates before release. Lock down PAC settings so only authorized routing rules can be deployed. Verify PAC file integrity and alert on unauthorized modification. | ||
Practitioner Guidance
What to verify: Confirm which clients consume PAC files, where the file is hosted, and whether updates are authenticated, logged, and reviewable. A PAC file that is easy to change but hard to observe is a routing control with an audit gap.
Common mistake: Treating PAC logic as a convenience feature instead of a security-relevant policy file. The usual failure mode is not a broken browser setting, but an unnoticed routing change that shifts traffic outside inspection or into the wrong proxy path.
Practitioner takeaway: A PAC file is only as safe as the trust and integrity of the file delivery path, so monitor it like policy code and not like a harmless client preference.