Document security / Who can reach the document
What a PDF password actually protects, and what it does not
Password protection on a document, which is genuinely useful for one purpose and routinely presented as something much stronger.
The exposure
A password on a document is easy to enable and easy to over-describe. Reporting to a stakeholder that a file is encrypted invites them to hear something about the strength of the encryption, and the honest answer here is specific: the password option applies 40-bit RC4 as specified in the PDF Reference 1.4, using the standard security handler at /V 1 /R 2. That is a 1.4-era mechanism. It stops a document being opened casually by somebody it was not sent to, and it does not stop a determined attacker, who will open the file.
The decisions
Reasons rather than a description of the code. Each one has a default that is fine for a page and wrong for a file somebody keeps.
- Use it for what it is: a barrier against casual opening, particularly for a document that might be delivered to the wrong address.
- Say which encryption when reporting it. Forty-bit RC4 and AES-256 are the same word in a status report and nothing alike in a security review.
- Do not let it substitute for access control. A protected file that anybody can download is a file anybody can attack offline, at leisure.
- Never send the password alongside the document. A password in the covering email protects against nothing at all.
- Where the requirement is real encryption strength, apply it downstream rather than arguing about the option. The render produces the document; a later step can encrypt it properly.
- Note the interaction with conformance: a file that claims PDF/A in its metadata and is encrypted is a combination no validator will pass, so the two options do not usefully combine.
In practice
A fragment, with the thing that goes wrong kept in a comment where it is the more instructive half.
// Useful for one thing: a document delivered to the wrong address is
// not casually readable.
const res = await pdf.post("/v1/pdf", {
html,
options: {
password: derivePassword(customer), // never sent with the document
format: "A4",
},
});
/* State it accurately when reporting:
"The document is encrypted."
-> heard as AES-256. It is not.
"The document carries 40-bit RC4 encryption per the PDF Reference
1.4, which prevents casual opening and would not resist a
determined attempt."
-> the truth, and it takes one more sentence.
What it does not do:
it is not access control. A protected file anyone can download is
a file anyone can attack offline at their leisure.
it does not combine usefully with pdf_a: a file claiming PDF/A in
its metadata and encrypted is a combination no validator passes.
Where real strength is required, encrypt downstream: the render makes
the document, a later step can apply AES-256 to it. */
// And never: the password in the covering message.
// "Please find attached. The password is Smith2026."What people do instead
Reporting it as encryption without qualifying the cipher. The word satisfies a checklist, the requirement behind the checklist is not met, and nobody discovers that until an assessment asks which algorithm.
How this is found out
During a security review or a compliance questionnaire, at which point the file has been described as encrypted for some time in documents that are now inaccurate.
Frequently asked
Does this page tell me what the law requires?
No, and deliberately not. Retention periods, erasure obligations and residency rules vary by jurisdiction, by industry and by the kind of document, and they change. What these pages describe is the shape of the problem and the mechanisms a system needs in order to implement whatever answer your own advisers give you. Where a genuine tension exists, such as an immutable record against a right to erasure, it is named as a tension rather than resolved.
Why is so much of this about the contents rather than access control?
Because access control decides who can obtain a copy and has no opinion at all about what happens to the copy. Once a document is on somebody's laptop, forwarded to a colleague or printed, every control listed here has already stopped applying to it. What is inside the file is therefore the part that keeps mattering, which is the opposite of the balance you would strike for a page.
How much of this applies at a small volume?
Most of it, because these are decisions rather than infrastructure. Redacting by omitting rather than covering costs nothing. Deciding what goes on a template costs one review. Classification is one object in code. Legal hold and an audit trail are the two that take real work, and both are far cheaper to build before they are requested than under the deadline that comes with the request.
Related security topics
The decisions that depend on each other, then the rest of the same group.
Marking a document so a leaked copy can be traced back
Putting a per-recipient mark on a document so a copy found elsewhere can be attributed, which is a deterrent and an investigation aid rather than a control.
Sending a document as a link or as an attachment, and the tradeoff
Two delivery models with different security properties, where the convenient one is usually the less controlled one.
Personal data in a document that will be emailed
What a document discloses once it is attached to a message, which is more than the recipient asked for and travels further than the message.
Serving a generated document behind proper access control
Making sure the person downloading a document is entitled to it, which fails most often because the document lives somewhere the check does not.
Signed URLs for documents, and choosing an expiry that fits
Giving out a URL that carries its own authorisation for a limited time, which moves the access check to the moment the link is minted rather than the moment it is used.
Every document security topic
The full list, grouped by access, contents and what happens afterwards.
What this API actually does
The options and endpoints these decisions are built on, one page each.
Most of these are decisions rather than features, and the cheapest time to make them is before the first document is delivered rather than after one reaches the wrong person.