Nutrient Web SDK security

Nutrient Web SDK is developed with a security-conscious approach and is suited to a broad variety of applications. Some key points:

  • Code commits to our software undergo our standard review process, which includes manual reviews and automated testing.

  • Encrypted PDFs are supported and cannot be accessed without the matching password.

  • PDF passwords are never persisted.

Accessing an underlying PDF file

Nutrient Web SDK may keep parts of extracted text or annotations in memory to perform the requested operations.

When Web SDK is used in standalone mode, all the processing and rendering of documents occurs on the client side. There’s no transmission of a user’s files or data to any external server, and we don’t have access to your deployment. Keep in mind that since the document fetching is done on the client side, a malicious user could potentially access underlying PDF documents.

If you want to learn more about access to protected files, refer to our accessing protected files guide.

Document permissions

Permissions set on a PDF document are honored by Nutrient Web SDK. Refer to our document permissions guide to learn more.

Nutrient Web SDK with Document Engine

When Web SDK is used with Document Engine, the processing and rendering of PDF documents is done through a container instance of Document Engine, which may be hosted in either your infrastructure or within our managed services (Managed Document Engine).

Refer to our security guide to learn more about security in Document Engine.

Screenshots

Taking a screenshot on the web cannot be prevented. If you’re concerned about users taking screenshots, we advise reevaluating your organization’s threat model regarding the distribution of documents and implement complementary physical security controls as necessary. Even if it were technologically possible for us to prevent screenshot capture, there’s nothing stopping a user from obtaining a screen capture by taking out their mobile phone and snapping a photo of their computer screen.

Digital signing keys

Nutrient offers complete flexibility over how public and private encryption keys are handled for both operational modes.

When using standalone Web SDK, you’re responsible for generating a valid digital signature by registering a callback that receives a file’s byte range and allows you to implement your own logic to generate a DER PKCS#7 container that Nutrient will apply as a signature. Nutrient doesn’t need access to any private key.

On the other hand, when used with Document Engine, Web SDK relies on a network service that you’re responsible for maintaining and operating. This network service needs to expose a single HTTP endpoint that — after receiving the information required to generate the signature — returns a DER PKCS#7 container to be set as a value of the digital signature field.

Check out our digital signatures on web guide to learn more.