Legal orgs and agencies don’t adopt Docassemble because it’s “cool tech.” They adopt it because it reduces friction, standardizes intake, and generates documents faster—often while handling sensitive data (PII, financial info, immigration facts, custody details, protected addresses, etc.).
That’s why security in Docassemble isn’t a checkbox. It’s part of product quality.In this guide, we’ll cover docassemble security best practices that actually matter in production-especially for US legal teams: access control, audit trails, data handling choices, and deployment hardening. We’ll keep it practical, and we’ll include a small technical section your dev team can use immediately.
Why Docassemble security feels “different” than typical web apps
Docassemble is a web app, but it behaves like an interview engine: users answer questions over time and the system stores an “interview session” state (variables) that later generates PDF/DOCX/RTF outputs.
That session model introduces unique risks—especially around links, session keys, and multi-user workflows.
Docassemble’s own security docs explain that each interview session has a unique session key and that server-side encryption is used by default, but it can be disabled depending on configuration (more on that below).
1) Access control: the simplest way to prevent the worst mistakes
Most security incidents aren’t advanced hacking. They’re:
- a link sent to the wrong person
- a staff member accessing a case they shouldn’t
- a shared login used across a team
- a misconfigured admin role
Use Docassemble privileges the right way
Docassemble includes a privileges/roles model (e.g., user, admin, and custom privileges you define). Admin users can control other users’ privileges, and developers can use privilege checks inside interviews.
2) Data handling: encryption choices that change your risk profile
Here’s a Docassemble-specific security point that many teams miss:
Understand multi_user and server-side encryption
Docassemble encrypts interview answers (the session dictionary) on the server by default, and setting multi_user to True disables this encryption (because it’s needed for multiple users to access the same interview answers).
What this means in plain English
- If you want “collaborative” interviews (multiple staff working on the same session), you may trade off default encryption.
- If you want maximum confidentiality per-user session, keep server-side encryption enabled and be careful about sharing session links.
Docassemble also warns that emailing links that include session keys can create risk—especially when server-side encryption is turned off—because the URL contains the session key.
Practical best practice
- Avoid emailing “magic links” that directly open a session unless you’ve validated your encryption mode and access rules.
- Prefer authenticated portals or time-limited access patterns for staff workflows.
Be careful with exporting and emailing user data
Docassemble documentation explicitly notes that putting interview variables into a file and emailing them can reduce security, particularly when server-side encryption is being used.
3) Audit trails: what to log (and what not to log)
US legal orgs often need accountability for:
- who accessed a case
- when a document was generated
- when an intake was submitted
- when data was exported or deleted
Docassemble can be deployed in ways that support audit readiness through controlled permissions and logs, but it’s not “automatically compliant”—you need intentional configuration and operational discipline.
Practical best practice
Log events like:
- login attempts (success/failure)
- privilege changes (admin actions)
- interview start/submit timestamps
- document generation events
- export actions
Avoid logging
- full SSNs, DOBs, medical details
- full interview variables/session data
- encryption keys or tokens
4) Deployment hardening: Docker security isn’t optional
Most Docassemble installs use Docker. That’s a good thing—if you run it like a production system.
Docassemble’s Docker documentation highlights operational risks like avoiding forced shutdowns because the internal PostgreSQL data can become corrupted if not shut down gracefully; the container performs backup/restore during shutdown/startup.
That’s not just uptime advice—it’s data integrity advice.
What “docassemble docker security best practices” looks like
At a minimum:
- HTTPS everywhere (terminate TLS properly)
- firewall rules: only expose required ports
- secrets in environment variables or secrets manager (not in Git)
- persistent volumes with controlled access
- regular updates and patching of base images and dependencies
Technical section: quick hardening snippets you can copy
A) Example: Restrict exposure with Nginx reverse proxy (conceptual)
If you run Docassemble behind Nginx, expose only 443 publicly, and keep internal ports private.
Nginx basics
- Force HTTPS redirect
- Add HSTS
- Limit request size if you don’t need huge uploads
B) Example: Minimal webhook-safe logging policy
In your app logs:
- mask session keys
- mask authorization headers
- keep request IDs for traceability
C) Example: Safer operational checklist
- Confirm whether multi_user is enabled and why (encryption implications)
- Confirm you are not emailing exported variables or session files casually
- Confirm Docker shutdown is graceful + backups are tested
- Confirm privileges are least-privilege and admin access is limited
5) “Docassemble security hardening” priorities for US legal teams
If you only do five things this month, do these:
- Lock down admin access and define privileges intentionally.
- Confirm encryption mode (multi_user implications) and adjust link-sharing workflows accordingly.
- Set a data retention policy for interview sessions and generated docs (keep only what you need).
- Implement audit logging for high-risk actions (exports, privilege changes, document generation).
- Harden the deployment (HTTPS, firewall, secrets management, backups).
This is the core of docassemble encryption at rest, operationally: encrypted storage + controlled access + minimum retention + secure backups.
FAQs
1) What are the most important docassemble security best practices for US legal orgs?
Start with least-privilege access control, confirm encryption mode (multi_user implications), avoid emailing exported variables, implement audit logging, and harden the Docker deployment.
2) Does Docassemble encrypt interview answers by default?
Yes—Docassemble encrypts interview answers on the server by default, but certain configurations (like enabling multi_user) can disable that encryption to support shared access.
3) Is it safe to email users a link to continue an interview?
It depends on your configuration and workflow. Docassemble warns that links can include session keys, and risk increases if encryption is disabled. Prefer authenticated portals or controlled access patterns for sensitive matters.
4) What should we log for audit trails without exposing sensitive data?
Log high-level events (logins, privilege changes, submission timestamps, document generation, exports) but avoid logging full interview variables or highly sensitive PII.
5) What are common “docassemble docker security best practices”?
Use HTTPS, restrict exposed ports, manage secrets securely, keep images updated, and ensure graceful shutdown/backups are tested—Docassemble notes forced shutdowns can risk data corruption.
6) How can we align Docassemble with compliance expectations in the US?
Docassemble itself isn’t a compliance certification, but with proper configuration (permissions, access logs, controlled data handling), deployments can be aligned with typical legal IT security requirements.
English