我完全懂你的痛点——处理用户上传的不可信PDF时，哪怕一丝JS执行漏洞都可能引发XSS风险，这绝对容不得半点马虎。你提到设置enableScripting: false后，PDF里八进制编码的JS被拦住了，但直接写的alert('XSS Exploit!')还能跑，这大概率是漏了几个关键配置项，或者配置的姿势不对。

核心配置的正确设置 #

首先，enableScripting确实是pdf.js控制PDF内JS执行的核心开关，但要确保它是在全局配置里设置的，而非局部。另外还有个容易被忽略的enableScriptingPDF选项，它专门管控PDF文档内部的JavaScript执行，必须和enableScripting一起设为false才能切断核心执行路径。

举个初始化Viewer的配置示例：

const viewer = new PDFViewer({
  container: document.getElementById('pdf-container'),
  enableScripting: false, // 主线程禁用JS执行
  enableScriptingPDF: false, // 明确禁用PDF内的所有JS
  disablePreferences: true, // 禁用偏好设置相关的JS触发入口
});

禁用所有可能触发JS的附加功能 #

PDF里的JS不一定只藏在直接的脚本块里，交互元素比如表单字段、注释、动作按钮都可能绑定恶意脚本，所以这些相关功能也得一并禁用：

• 把enableInteractiveForms设为false：彻底关掉表单功能，避免表单字段绑定的JS执行
• 把enableAnnotationEditor设为false：禁用注释编辑及相关的脚本触发
• 若你的场景不需要3D渲染或复杂图形，可把enableWebGL设为false：减少潜在的脚本利用面

确保Worker线程的配置同步 #

pdf.js的渲染分主线程和Worker线程，Worker负责解析PDF的核心逻辑，所以必须确保Worker端的配置也同步禁用JS：

// 配置Worker的全局参数
PDFJS.GlobalWorkerOptions.workerSrc = 'pdf.worker.min.js';
PDFJS.GlobalWorkerOptions.enableScripting = false; // Worker端也禁用JS
PDFJS.GlobalWorkerOptions.disableFontFace = true; // 额外安全项：防止恶意字体带来的风险

验证配置生效的小技巧 #

你可以自己做个测试PDF，直接嵌入alert('XSS Test')的脚本，用你的配置渲染后如果没有弹窗，说明配置生效。如果还是能触发，那就要检查配置是否被正确传递到了pdf.js的所有执行上下文里。

激进兜底方案：纯静态渲染 #

如果对安全性要求极高，甚至可以走纯静态渲染的路子——在解析PDF时，主动过滤掉所有包含JS的动作、注释、表单元素，只保留文本、图片等静态视觉内容。这个方案会牺牲所有交互性，但能把风险降到最低。

总的来说，只要把上述几个关键配置都拉满禁用，就能确保pdf.js在渲染用户上传的PDF时，完全不会执行任何嵌入的JavaScript，同时保留所有静态内容的正常显示，彻底防范XSS威胁。

内容来源于stack exchange