Historically, we have learned that many security vulnerabilities and exploits have resulted from allowing document files to contain executable code, whether it be JavaScript, VBScript, another scripting language, or even macros.

As such, since the first days that JavaScript could be embedded into PDF files, I have disabled JavaScript support within every PDF reader and editor I have used. Many colleagues have done the same.

According to the pre-release notes for Firefox 88, which is being pushed to the public any hour now:

We [Mozilla] keep on working on improving our PDF forms support and now support JavaScript embedded in PDF files (some PDF forms use JavaScript for validation and other interactive features). If you find any bug with this feature, please file an issue on the PDF.js repository.

On the surface, this sounds quite concerning from a security standpoint. Although, hopefully, any code executed from a PDF file will have at least the same security in place as JavaScript run from a website, the source and control of PDF content being loaded is often very different than a website.

For example, let's take google.com (as Henny Youngman would add, "please"). Assuming a non-compromised connection, any JavaScript code running on that domain would be written by Google developers (for better or worse). But if you perform a search for PDF files on google.com, you'll be presented with literally billions of PDF files, each of which could be written by any random person. And each could contain JavaScript code written by literally anyone. With PDF JavaScript support enabled within the browser, any PDF file you click on to read could now run arbitrary code on your computer.

Is this a security concern? And if so, can it be disabled?

  • 3
    "Is it a security concern?" most likely, yes. Every additional feature can contain security-relevant bugs.
    – user163495
    Commented Apr 19, 2021 at 8:47
  • 4
    Yes, it's going to increase the attack surface. The easiest thing you could do is to set Firefox to always download documents instead of opening them. That way, you will be able to see PDFs with your default reader (where JS is off).
    – reed
    Commented Apr 19, 2021 at 9:52
  • No more of a security risk than running JavaScript in your browser. Chrome has the same feature with the same limited JS support, but people aren't clamoring to disable it. JS can be disabled, but doing so pushes people towards opening PDFs in other applications like Adobe PDF Reader which have a much worse history of exploitation.
    – summer
    Commented Apr 22, 2021 at 20:25
  • If you're running Chrome, you're fine with using a browser that is not fully open-source (or you are unaware of this). Thus, you never know what code is actually running on your device. Unlike Chrome, Firefox is completely open-source. Consequently, the standards and expectations tend to be higher for users of Firefox. Commented Apr 23, 2021 at 2:19

3 Answers 3


Regular folks don't have to worry about this feature more than any other part of Firefox. For a professional worrier like myself (I literally get paid to worry) it's less concerning than JavaScript in a web page because of the lack of functionality.

JavaScript in PDFs has an extremely limited set of objects it can manipulate: just the form data. It can't access or manipulate the document text, nor does it have access to any DOM (browser) APIs and can't send network requests. In addition, Firefox has always opened PDF files in a special local context and it's no longer considered part of the site the file was downloaded from. We still show that original URL in the address bar for convenience (you might want to copy it, or manually edit it to a related URL) but it's pretty much a lie. Even if the script could get out of the sandbox through some security bug--and this sandbox has been in use for years with Web Extensions--it wouldn't be able to affect the site it was uploaded to.

The one new potential is that a jerk could write an infinite loop and try a denial of service attack, but that's not any different from any web page or framed web advertisement you browse to all day. It doesn't seem to be a problem in practice given equally "vulnerable" PDF viewers in Chrome, Edge, and Opera. You can always just close the tab as you would with a bad web page.

You can turn it off if you want with the pdfjs.enableScripting pref, but there's no real reason to do so.


Since I am the OP, I am not currently certain how to accurately and completely answer the question "Is this a security concern"?

As of this time, there are no answers to this question, but 2 commenters voiced they both consider this to be a security concern. As such, I went through the Firefox source code, and figured out how to prevent JavaScript within PDF files from being executed in Firefox 88+. To do this, change the following advanced preference:




You can change this preference manually by going to about:config and entering in the name of the preference, and then toggle its value to false. Alternatively, you add the following line to user.js in your Firefox profile folder:

user_pref("pdfjs.enableScripting", false);

A final way to make this change is to use a Group Policy (for Windows only). This is a common technique used by IT Admins. The full details for doing that are beyond the scope of this answer, but can discerned by reading the details on Mozilla's support site, which references these two GitHub pages:


  • Yes, this was the default setting prior to Firefox 88. Commented May 4, 2021 at 0:56
  • @user10216038 Was it? According to the release notes I posted in the question, Mozilla is stating this is new functionality. If so, why would there have been a setting to disable functionality that didn't exist? Commented May 4, 2021 at 6:46
  • I don't know. I had read about this prior to upgrading to 88 and checked the settings in 87 (Linux) and found the value set to false. After upgrading to 88, it was set to true and I manually set it back to false. Commented May 4, 2021 at 15:05

I think a good way to frame this is - is running JavaScript on a website a security risk? Yes, but we think that the browser does a pretty good job of sandboxing JS and protecting against rendering/JS exploits. If you trust Firefox to do a good job on website, why not here? If you run your browser without JavaScript enabled or default disabled, this post is not for you. For everyone else, this is net neutral or a net positive improvement in security when opening PDFs because we no longer have to open most fillable form PDFs in Adobe PDF Reader.

Mozilla's implementation of using pdf.js in the browser has a separate sandbox targeted fro PDF reading. Here's a link to a related commit https://hg.mozilla.org/mozilla-central/rev/a13e286152a8

At the time of this post, there's some recent minor outrage about enabling JS in Firefox when Chrome has had this feature for ages to support fillable forms. Using fillable forms and validations is a huge quality of life improvement and prevents the user from using a PDF reader with a much worse history of exploitations (Adobe PDF Reader). Like Chrome, Firefox's implementation does not support all possible JavaScript that would be supported on Adobe PDF Reader, but it seems like enough to support most basic use-cases.

I for one am happy about the change and see it as a net security benefit since I no longer need to open potentially untrusted PDFs in an application outside of the browser.

  • One of the primary concerns about PDF files is that the author of the JavaScript contained in the PDF is often completely unknown and not affiliated in any way with the website on which it was delivered. With websites, you can make an somewhat educated guess as to who wrote the JavaScript; with PDF files, you often have no idea who wrote that code, or if that code has been tampered with by third-parties. Regarding Adobe PDF Reader, I don't recommend anyone use that software to read PDF files. Commented Apr 23, 2021 at 2:15
  • My concern would be that the same source restrictions of Javascript on a web site might not be nearly as reliable when applied to a saved PDf opened from local disk. Commented May 4, 2021 at 0:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .