A Proxy Auto-Config file should be controlled, because it can redirect client web traffic through attacker-chosen proxies if it is altered. Reduce risk by limiting who can change it, serving it over trusted infrastructure, checking for unauthorised edits, and validating proxy destinations. Also review systems that automatically trust PAC delivery from remote locations.
What makes a PAC file worth controlling?
A PAC file is not just a browser convenience file, it is part of the traffic decision path. If an attacker can alter it, they can steer web requests to a proxy they control, intercepting credentials, sessions, and sensitive browsing data. The practical question is therefore not whether a PAC file exists, but whether its source, delivery path, and change process are trustworthy.
That means PAC risk is highest when the file is treated as a low-friction configuration artefact instead of a security-relevant control point. A browser or endpoint that automatically trusts remote PAC delivery, or a network that lets many people edit the file, creates a small change surface with a large blast radius.
Which controls reduce PAC file abuse?
The strongest mitigations are the ones that constrain both PAC file handling within web filtering and gateway design and the actual destinations a PAC file is allowed to choose. Limit who can change the file, store and serve it from trusted infrastructure, and require integrity checks or monitoring so unauthorised edits are visible quickly.
Validate proxy destinations before use, especially where a PAC script can point to arbitrary hosts or fallback routes. If the environment uses centrally managed web egress, align the PAC file with the intended proxy architecture instead of allowing local edits or ad hoc overrides that bypass inspection.
Where organisations are moving toward SASE and SSE patterns, PAC governance should be part of the traffic-steering design, not a separate afterthought. That avoids a common failure mode where the secure access model is strong on paper, but a loosely governed PAC file becomes the easiest way around it.
What should you check when patching or policy changes are not enough?
When a PAC file has been exposed to unauthorised change, the main concern is not only fixing the file, but also whether traffic was already diverted. Review endpoints and proxy logs for unexpected proxy hops, unusual PAC retrieval sources, and authentication activity that does not match normal browsing patterns.
If remote PAC delivery is allowed, confirm that only approved locations can host or influence that file. Some systems automatically trust PAC delivery from remote locations, which is convenient operationally but risky if the hosting source or transport path is not strongly controlled.
For higher assurance environments, treat PAC changes as security events, not routine config drift. That gives you a cleaner decision point for rollback, investigation, and if needed, broader session review for users who may have traversed the malicious proxy path.
Risk and Threat Considerations
A compromised PAC file can silently redirect browser traffic through an attacker-controlled proxy, which makes it useful for credential theft, session interception, selective censorship, or traffic observation. The risk is amplified because the user experience may remain normal while the routing decision has changed underneath it.
Failure mechanism: The attacker abuses trust in the PAC source or delivery path, then modifies the proxy selection logic so browsers send traffic to an unintended egress point. If the environment does not validate destinations or monitor PAC integrity, the redirect can persist unnoticed.
Impact: Sensitive web traffic can be exposed, manipulated, or captured before security controls at the intended proxy are applied. In the worst case, users authenticate to a malicious proxy and reuse sessions or credentials that were never meant to leave the trusted path.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | PAC files are security-relevant configuration items that need controlled modification. |
| SI-7 — Software, Firmware, and Information Integrity | PAC integrity checks help detect unauthorised edits and tampering. | |
| IA-5 — Authenticator Management | PAC abuse can expose sessions and credentials by redirecting browser traffic. | |
| Recommendation — Restrict PAC file changes to approved administrators and tightly review every change. Monitor PAC file integrity and alert on unexpected modifications. Rotate exposed credentials or sessions if PAC tampering may have intercepted them. | ||
| CIS Controls v8 | CIS-5 — Account Management | Controlling PAC publishing access depends on limiting who can make changes. |
| CIS-12 — Network Infrastructure Management | PAC files steer network egress and proxy selection, which is a network control function. | |
| Recommendation — Limit PAC administration to a small set of authorised accounts. Manage proxy routing centrally and validate approved egress destinations. | ||
Practitioner Guidance
What to verify: Confirm who can publish the PAC file, where it is hosted, and whether endpoints can be forced to consume it from a trusted source only. The control is weak if the file is protected in storage but not in delivery.
Decision rule: If the PAC file can influence production browsing, treat any unauthorised edit or unexpected hosting change as a security incident until you have confirmed the proxy destination list and inspected affected client activity.
Common mistake: Teams often focus on the file contents and forget the trust path. A well-written PAC file is still unsafe if browsers will accept it from an untrusted location or if proxy choices can be changed without review.
Practitioner takeaway: PAC risk is really trust-path risk, so the right mitigation is to control who can change it, where it is served from, and whether the chosen proxy endpoints are actually the ones you intended.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org