As a vendor of a commercial PDF SDK, customers routinely ask about the security of our cross-platform offerings as well as how they can protect their users and their documents. And we take customer trust in the PDFTron SDK extremely seriously.

In this article, we explain how we secure the PDFTron SDK and support our customers in securing their PDF apps, confidential information, and important documents.


The biggest security danger for PDF SDKs as seen in the wild usually involve the use of a boobytrapped PDF to exploit an underlying weakness in the library’s complex PDF rendering engine. This could be used to hijack control over an app and steal confidential data from within such as SINs, emails, and banking information -- or even documents.

To be certain of absolute security, we’ve implemented several precautions:

1. End-to-end Quality Assurance

Fixes and patches performed without proper quality assurance are common sources of new security vulnerabilities. To ensure this doesn’t happen, we implement extensive quality assurance with every official update of the PDFTron SDK through code-base quality controls such as extensive test and regression suites.

2. Closed-source Core, Open-source Front-end

As hinted above, a core PDF rendering engine has a lot of moving parts. (The PDF spec itself is over 1,000 pages long, not including extensions and supplements.) This complexity offers a lot of possible attack vectors.

For example, many vulnerabilities in PDF revolve around the use of JavaScript. Thus to address this specific class of weaknesses, JavaScript is disabled by default in the PDFTron SDK.

Additionally, and in contrast to some PDF libraries, the core PDFTron rendering engine was built entirely from the ground up without any open source. This means the underlying code is not available, in practice, offering a significant deterrent to hackers who will scour publicly available code and vulnerability databases for exploitable weaknesses.

(Read our article on the security risks of PDFium-based PDF apps and SDKs to learn more.)

We still provide all our UI and tool source code, however, to afford clients maximum freedom to optimize the UX and change the UI appearance and behavior. This is not a risk because the front-end does not offer access to the native code behind the APIs.

3. Third-party Audits and Review

Having more eyes on code is also essential to ensuring an SDK’s continued stability and security. And because the PDFTron SDK is used by many large organizations and governments, our processes & code are under frequent scrutiny by third-party tools and groups.

We had three independent security reviews in recent years involving use of static analysis tools (e.g., Veracode and HP Fortify). The most recent audit was performed by in July 2019.

The Bottom Line

As of writing, there are no known security vulnerabilities in the PDFTron SDK.

We hope this article was helpful! If you’d like to talk to our developers about how we secure our SDK, or if you have any other questions, don’t hesitate to get in touch .