Doconut Viewer becomes part of your application's security boundary as soon as it displays contracts, invoices, engineering drawings, or customer records. Doconut supplies the viewing layer; the surrounding application must still decide who may open a file, where the source is stored, how long derived data remains available, and what is recorded for investigation.
Doconut's article on secure document-viewing practices describes server-side rendering as one layer in a defense-in-depth design. This article therefore focuses on the application responsibilities around Doconut and directs implementation details to the maintained product documentation.
Begin with a Threat Model
“Private” and “secure” are not configurations. Define the events you need to prevent or detect before choosing controls.
| Risk | Example | Application control |
|---|---|---|
| Unauthorized access | A user changes a document identifier in the URL | Object-level authorization on every request |
| Tenant crossover | A valid user requests another customer's file | Tenant scope included in the authorization decision |
| Source exposure | A storage path or original file is returned directly | Server-controlled lookup and rendering flow |
| Stale access | A link remains usable after a role or case changes | Short session lifetime plus authorization revalidation |
| Excessive retention | Temporary input or output accumulates | Explicit lifecycle jobs with observable outcomes |
| Sensitive logging | Tokens or file locations appear in logs | Structured redaction and identifier-only telemetry |
Prioritize risks according to the documents and users in your system. A public brochure library and a legal evidence portal should not share the same policy merely because they use the same viewer.
Doconut's legal document-review use case is a useful reference for the product's role inside authenticated case, contract, evidence, and compliance workflows. It also reinforces the architectural boundary: permissions, storage, customer records, and business rules remain close to the host application.
Authorize Before Opening the Document
Perform authentication and object-level authorization before opening the document with Doconut. The official .NET 6 or higher setup guide shows how the viewer is configured and how a server-side document is opened; place your application's identity, tenant, and document-permission checks before that product step.
Repeat the same authorization rule for every related operation your application exposes, including pages, thumbnails, search, annotations, conversion, download, and print. Hiding a button does not protect the underlying request.
Avoid accepting a filesystem path, storage key, or remote URL directly from the browser. Resolve an application-owned document ID to its storage location on the server, then confirm the resolved object belongs to the authorized tenant and workflow.
Separate the Viewer from Storage Policy
The viewer should not define your retention period. Document each storage class and owner:
- Source document — controlled by your primary content or records policy.
- Temporary working files — created for processing and removed by a scheduled, observable lifecycle.
- Rendered pages or caches — scoped to the minimum useful lifetime and protected like the source.
- Exports and print-ready files — created only when the user has the matching permission.
- Logs and audit events — contain identifiers and outcomes, not document content or credentials.
Encryption in transit and at rest depends on your web server, storage provider, key management, and deployment settings. Verify those controls in the actual environment; do not infer them from the presence of a viewer library.
Use Short-Lived References Carefully
A short-lived reference can reduce the time available for replay, but it does not replace authorization. If your design uses a signed route or session token:
- Bind it to one document and intended operation.
- Give it a narrow lifetime based on the workflow.
- Avoid placing sensitive claims or storage locations in clear text.
- Revalidate authorization for privileged operations.
- Define what revocation means before the natural expiry time.
- Keep tokens out of analytics, referrers, exception messages, and screenshots.
When a browser session expires, show a neutral message and offer a safe way to reauthenticate. Do not expose whether another tenant owns the document.
Understand What Client-Side Controls Can and Cannot Do
Removing download or print controls can improve the intended workflow, but it is not a confidentiality guarantee. A user who can see content may still capture the screen, photograph it, or use browser capabilities outside the viewer.
Treat client-side restrictions as usability and deterrence measures. Stronger controls come from keeping source files behind the server, applying authorization to every related request, limiting exports, and using visible watermarks when your policy calls for them.
Do Not Turn Product Features into Compliance Claims
Regulatory compliance depends on purpose, data categories, lawful basis, contracts, regional processing, retention, incident response, and organizational procedures. A viewer can support a compliant design, but it does not make an application compliant by itself.
For a GDPR assessment, document at least:
- Where source and derived files are processed and stored
- Who acts as controller and processor for each service
- Which subprocessors and transfers are involved
- How deletion requests reach every storage class and backup policy
- Which events are logged and how long logs remain available
- How access reviews and incident response are performed
Have privacy and legal stakeholders validate those decisions for your deployment.
Add Security Headers and Cache Rules
For authenticated preview routes, evaluate a restrictive Content Security Policy, frame policy, MIME-sniffing protection, and a referrer policy. If the preview appears inside an iframe, make the intended parent origins explicit.
Choose cache headers according to the sensitivity and rendering route. no-store may be appropriate for some responses, but it can affect performance and does not erase content already captured elsewhere. Test browser, proxy, and CDN behavior rather than relying on a header in isolation.
Log Decisions, Not Secrets
A useful audit event might contain:
- User and tenant identifiers
- Document identifier
- Requested operation
- Authorization result
- Timestamp and correlation ID
- Retention or cleanup outcome
Avoid logging raw tokens, query strings, storage URLs, document names containing personal data, or extracted text. Protect audit logs from modification and limit access to the teams that need them.
Verify the Complete Flow
Security testing should include negative cases:
- Change the document ID while staying authenticated.
- Reuse a preview URL from another user or tenant.
- Call page, thumbnail, print, and export endpoints directly.
- Expire the session during a long preview.
- Remove a user's permission while a document is open.
- Submit unsupported, oversized, damaged, or password-protected input.
- Confirm cleanup jobs remove eligible data and report failures.
- Inspect logs, analytics, and error pages for sensitive values.
Automate the stable cases and retain a manual review for storage configuration, browser policy, and viewer-version changes.
Conclusion
A security-conscious integration has clear ownership. Doconut supplies the document-viewing capability described by its official documentation; your application supplies authentication, authorization, storage controls, retention, monitoring, and incident response. Keeping those responsibilities explicit produces stronger controls and more honest privacy claims.