Restricting download, print and copy in Collabora Online for sensitive documents
Restrictions on downloading, printing and copying in Collabora Online are set mainly by the WOPI host, through the permissions it sends for each session. Collabora Online enforces what it receives. That decision therefore lives in your storage platform's configuration, so the team that owns the host has to own the policy. Regulated teams usually need these controls when documents carry personal data, legal privilege, board material, unreleased financial results or clinical records, and when the people editing them should work on the content without taking copies outside the platform. The controls reduce casual leakage. They are one layer beside access control, sharing settings, audit logging and endpoint policy, not a replacement for any of them.
Start by separating two kinds of control. Role decisions, such as which groups may open a document and which may edit it, are handled by the group settings described in the Nextcloud administration manual, and they apply before any document opens. Download, print and copy permissions are a finer set of flags that the host returns when Collabora Online requests file information through the WOPI CheckFileInfo operation. Check your host's documentation for which of these flags it supports, how it maps your roles to them, and whether a change applies to sessions that are already open. Then run a test matrix: open the same sensitive document as a viewer, an editor and an administrator, and confirm that menus and actions match the policy you wrote down.
Plan for what these controls cannot do. Restricted sessions can still show content, and anything a user can see can be captured by screenshot, retyped or read aloud. Files downloaded before a policy change stay where they are. Ask your host and Collabora how the restrictions apply to exported formats such as PDF, and test those exports before relying on them. Record which restrictions are enforced by Collabora Online, which by the host and which by policy alone, then share that map with the people who will approve the design. For document classes that need stronger guarantees, agree the approach with your data protection and compliance owners during design so the gap is known and accepted in advance.
Which control fits which sensitivity level
The host application decides, for each user and session, what the editor may do with a file. Through the WOPI integration, the host passes its permission settings when the editor opens a document, so the decision stays with the system that owns the file and is enforced for that session.
- What it limits: whether a session can edit, and which document actions the host allows for that session.
- Where it is configured: in the host's own file permissions and in the response the host returns to the editor when the session starts.
- Typical fit: internal documents where the standard view or edit split is enough and the team wants one control point for each file.
- Limit to know: the flags only restrict what the integration asks the editor to enforce. They do not stop a user who already holds a copy of the file.
- Check: list the exact flags your host version sends, then test each one with a non-administrative account before relying on it.
Confirm the flag names and their behavior against your host's documentation and your Collabora Online version before writing them into policy.
In Nextcloud Office, administrators can choose which groups may use the editor at all and which groups may edit rather than only view. This is a coarse control, set by group membership and applied before a document opens, so it suits broad rules more than document-by-document decisions.
- What it limits: who can open documents in the editor and who can change them, by group. Users outside the permitted groups do not get an editing session.
- Where it is configured: in the Nextcloud Office settings of the Nextcloud administration interface, as described in the Nextcloud administration manual.
- Typical fit: a department that handles sensitive material, where most members should read and only a small group should change documents.
- Limit to know: group rules do not stop a member who can open a file from downloading it, unless another control also applies.
- Maintain: access follows group membership, so joiner, mover and leaver steps in your directory need to update the groups promptly.
Check the group lists in Nextcloud Office against current directory membership, and confirm how view-only users are handled for each file type your teams use.
Secure view is a session mode in which a document is shown with reduced ability to export, copy or print its content. Whether it is available, and how far it reaches, depends on the host or integration and on the Collabora Online version in use, so the exact scope must be confirmed before a policy depends on it.
- What it limits: export, copy and print actions from the viewing session, to the degree the mode enforces them.
- Where it is configured: in the host or integration that starts the session. Confirm the setting name and the supported versions with the host and Collabora documentation.
- Typical fit: contracts or reports shared with external reviewers, where reading is the goal and full export is not needed.
- Limit to know: a browser-side mode cannot stop a photograph of the screen, and it does not remove content that was exported before the mode applied.
- Test: open the document with a reviewer account and try each export path the team is concerned about, including copy and print.
Record exactly which paths the mode blocks in your environment, because that result decides whether it is sufficient for the sensitivity level.
A watermark marks the displayed content with text such as the viewer's identity or a classification label. It does not block any action. Its value is deterrence and attribution: if a copy leaks, the mark points to the session that displayed it. Support depends on the host or integration, so confirm it for your setup.
- What it limits: nothing directly. It makes copies traceable and discourages casual leaks.
- Where it is configured: in the host or integration that renders the session, if the feature is supported in your version.
- Typical fit: broad internal circulation of confidential material, where attribution matters more than blocking.
- Limit to know: a watermark does not prevent copying, and an overlay can be cropped or removed from an exported file.
- Test: confirm the mark shows the user's identity, stays in the print and export output you allow, and remains legible for each document type.
Decide whether attribution meets the requirement for each sensitivity level, or whether a blocking control must sit alongside the mark.
Options for limiting download, print and copy and when each fits
This table compares the controls that can limit downloading, printing and copying in a Collabora Online session, showing what each restricts, where it is configured and when it fits. Read it alongside the host and version you run, because support for these controls varies by integration. The main takeaway is that the host controls the stored original and its sharing settings, so editor-side settings alone do not stop a user from keeping a copy.
| Control | What it restricts | Where it is set | When it fits |
|---|---|---|---|
| Host permission flags | Whether the session allows editing, export, printing or copying, as the host reports per user | WOPI host, in the file information it returns when Collabora opens the document | When the host already knows each user's role. Confirm which flags your host version honors. |
| Nextcloud Office group rights | Which groups may open the editor and which may edit rather than only view | Nextcloud administration settings for Nextcloud Office, by group | When access differs by team. It limits who can use or edit, not what a session can export or print. |
| Read-only sessions | Changes to the document, while the content stays visible in the browser | Host grants read-only access for the user or file | When reviewers need the content but no edit rights. Viewing still allows reading and may allow copying. |
| Secure view | Intended to reduce local retention and handling of viewed documents; exact behavior depends on integration and version | Collabora and host settings, to be confirmed for your build | When the host supports it and you need fewer local copies. Confirm which actions it blocks in your environment before relying on it. |
| Watermarks | Visible marking that ties a printout or screenshot to a user or session | Host or document template, to be confirmed | When deterrence and attribution matter more than prevention. A watermark does not stop copying. |
| Host download and sharing settings | Whether users can download the original file outside the editor, and who it is shared with | Host file storage and sharing permissions | Always relevant for sensitive files, because editor controls do not govern the original the host stores. |
| Client-side limits | Screenshots, camera capture and copying into other applications | Not configurable in Collabora Online or the WOPI host | Plan for these as residual risk and address them through device, network and policy controls. |
Configuring restrictions for a sensitive document set
This sequence sets who can edit, view, print, copy or download a sensitive document set, enforces those choices through the integration, and confirms each one from a real user session. It ends with a tested record of what each group can and cannot do, plus the limits that remain.
Classify the document set and its readers
The document owner and the compliance lead first decide which folders, sites or document types count as sensitive, and which groups need to read, change or simply open them. Build a decision sheet with one row per group and columns for view, edit, print, copy and download, naming the integration and the folder or site it covers. The step is complete when every group that touches the set has a row and the owner has signed off on the sheet. Nothing is changed in the platform yet.
Decide which groups can edit
In Nextcloud Office, administrators can limit which groups can use the editor and which groups can edit, rather than only view, so use those group settings to match the decision sheet. Give edit rights only to groups that need them and confirm that the group settings apply to the integration you run. Check by signing in as a member of a view-only group, opening a document from the sensitive set, and confirming that editing controls are unavailable.
Configure host permissions for the document set
The WOPI host, not Collabora Online, decides whether a user may write to a file, and it passes its decision in the CheckFileInfo response. Set the permission values for each file or folder in the sensitive set so they match the sheet, and confirm in the documentation for your Collabora Online version which flags for printing, exporting and copying it honors. Check by calling CheckFileInfo as a read-only user and recording the returned values against the decision sheet.
Enable secure view or watermarks where supported
Where your Collabora Online version and WOPI host support secure view or watermarking for this set, turn it on for the relevant folders or sites. Make watermarks identify the viewer, such as the user's name and the access date, so that a leaked copy can be traced. Treat both as deterrents: they reduce casual copying but do not stop a determined user from reading or photographing the screen. Check by opening the document as a viewer and confirming the watermark appears and the feature behaves as its documentation describes.
Test each permission from a real user session
Sign in with one test account per group, not with an administrator account, and attempt each action on the sheet: open the editor, save a change, download the original, export to PDF, print, and copy text out of the editor. Record the outcome for each action in a test matrix. The step passes when the read-only account cannot save, and the download and print options are absent from the menus, and when every other cell matches the decision sheet. Retest any failure after correcting the setting.
Record the limits and retest after changes
Write down what the configuration does not prevent. A user who can view a document can still read it, retype its content, photograph the screen, or use a copy obtained through another route, so confirm these limits against your own environment and decide whether they are acceptable for the set. Repeat the test matrix after every Collabora Online or Nextcloud upgrade and after any permission change. Store the signed matrix and the limits list with the change records. The step is complete when both documents are filed and linked to the sensitive set.
Security and operational considerations
Download, print and copy restrictions only hold if the host, the server and the people using them agree on what is allowed. The cards below cover the places where that agreement tends to drift: configuration, token design, change tracking, upgrades, monitoring and user expectations.
Keep permissions consistent across host and server
The host decides who may open a document and in which mode, while Collabora Online enforces what the editor exposes to that session. If a user is read-only in the host but the server session still offers copy or export, the two layers disagree. Map each permission level in your host to the expected editor behavior, then test each combination with a real account. Confirm the mapping before any sensitive document is opened.
Set token lifetime and scope
WOPI access tokens carry the permissions for a session, so a long-lived or broadly scoped token can outlast a change in the user's rights. Ask your integration team how long tokens live, whether each token is tied to one file and one user, and what happens when a user is removed mid-session. Tokens that are not scoped to a single document make download and print restrictions easy to bypass by reusing a session.
Audit permission changes
Record who changed a sharing or group setting that controls editing, viewing or export, and when. Permission changes that are made in the host and never logged leave you unable to explain why a user could copy a document last month. Keep host audit logs for group membership and share settings, and retain them long enough to match your document retention policy. Confirm which events your host records by default.
Review behavior after upgrades
Upgrades to the host or to Collabora Online can change how restrictions are applied, which options appear in the editor, or how a read-only session behaves. Treat each upgrade as a change to the control set, not only a patch. Keep a short test script with one account per permission level, run it on staging before production, and rerun it after every minor release. Release notes for each branch are the first place to check for changed behavior.
Monitor for failed restrictions
Restrictions can fail quietly, for example when an integration falls back to a default permission or a session is created without the expected flags. Review server and host logs for sessions opened with unexpected modes, and alert on permission errors that cluster around sensitive folders. Pair this with periodic sample checks in which a test user attempts download, print and copy on a watermarked file. Agree on who reviews these signals and how often.
Train users on what controls do
Users who expect a restriction to stop screenshots, photographs or retyping will assume a document is safer than it is. Explain in plain terms that download, print and copy limits reduce casual leakage inside the editor but cannot prevent a determined person from capturing what is on screen. Show users which documents carry watermarks, and tell them who to contact when a restriction blocks legitimate work. Document this guidance in the same place as your data classification policy.
How these controls fit a data protection program
Download, print and copy restrictions reduce accidental and casual exfiltration, but they do not stop a determined user with a camera or a second device. Their value is that they turn a documented access policy into settings that are enforced by the editing session rather than left to individual judgment. Before configuring anything, map each restriction to a specific clause in your data classification or acceptable use policy, such as which document classes may leave the editor, which roles may print, and whether external sharers may receive copies. A control that does not trace back to a written rule is hard to justify to an assessor and hard to maintain when the integration changes.
Treat the output of this work as evidence, not as a certification. DeployOpen prepares the configuration, the test records and the operating procedures that show how each control behaves, but independent auditors and certification bodies are the only parties that issue audit reports or certifications. Ask your assessor early which requirements in your framework expect preventive controls on document export, which accept compensating controls such as logging and access review, and what records they will want to sample. Where a requirement names a specific control outcome, confirm the wording with the assessor rather than inferring it from this page.
Plan ownership for the controls after go-live. The permissions live partly in the WOPI host, such as Nextcloud Office group settings, and partly in the Collabora Online session, so a change in one place can silently alter the other. Assign a named owner for each policy mapping, record which settings were tested against which document classes, and repeat those tests after every Collabora Online and host upgrade. Confirm with your security and compliance leads how often reviews happen and who signs off on exceptions for documents that must remain printable or copyable for business reasons.
Questions buyers ask before restricting document access
How long does it take to set up download, print and copy restrictions?
The duration depends on how many document types, user groups and integration points need different permissions, and on how much of the control sits in the host application rather than in Collabora Online. No fixed duration is supplied for this work, so ask for a timeline in a written scope rather than a generic figure. The main drivers are the number of sensitivity classes, whether the host already maps groups to editor and viewer roles, and how much testing is needed across browsers and file formats. Ask the partner to break the timeline into design, build, test and rollout phases.
What does the work need from our team?
Expect to supply people who own the document classification policy, the administrators of the host platform, and someone who can test real documents from each business area. In Nextcloud, administrators can limit which groups can use the editor and which groups can edit rather than only view, according to the Nextcloud administration manual, so the host administrators will do much of the configuration. Your security team should agree the policy before build starts, because the policy decides which controls are needed.
Can our own team do this without a partner?
Yes, if your team already runs the host platform and Collabora Online and has staff who can write and test the permission rules. The configuration itself is not large, but the risk lies in the gaps: which downloads remain possible through other routes, which formats behave differently, and what happens when a user opens a document in a second tab. A partner adds value mainly through an independent test plan and a written record of what was checked. Weigh that against the skills and time your staff can spare.
What does a fixed-scope engagement cover for this topic?
A fixed-scope engagement sets out the scope, deliverables and timelines in writing before work starts. For this topic, that typically means reviewing the document classification policy, configuring permissions in the host and Collabora Online where supported, documenting which controls are enforced by which component, and handing over test results. Ongoing support, upgrades and continuous testing are available as retainers, so recurring work can be priced separately. Ask for the list of hosts and file types in scope, and for what is excluded.
How is the testing of these restrictions done?
Testing should check each restriction from the user's side, including the viewer role, the editor role, and the download, print and copy actions in the browser. Test each supported document type, because behavior can differ between Writer, Calc and Impress and between formats such as docx, xlsx and pptx. Also test the host's own download routes, since a restriction in the editor does not stop a user from downloading the file from the storage interface. DeployOpen runs security testing for applications and APIs, cloud and infrastructure, and can include these checks in the scope.
Can download, print and copy restrictions be fully enforced?
No. Restrictions that depend on the browser or the editor can be bypassed by a determined user with screenshots, a second device or a copy of the rendered content, so they reduce casual leakage rather than prevent it. Treat them as one layer alongside access control, watermarking and logging, and document the residual risk for each class of data. Ask any partner, including DeployOpen, to state which controls are enforced by the server, which depend on the client, and what remains open. DeployOpen does not issue certifications, and independent assessors judge whether the controls meet a given standard.
Which parts of this work recur after rollout?
Permission rules need review when staff roles change, when new document types are added, and when Collabora Online or the host receives updates. Updates matter here because security fixes can change editor behavior, and the Collabora Online 25.04 release notes record point releases such as 25.04.7.5 fixing CVE-2026-23623. Plan a recurring check of the permission matrix after each update. Ask whether the quote includes this work or whether it is handled through a retainer.
How DeployOpen scopes and delivers document restrictions
DeployOpen treats download, print and copy restrictions as a design decision that spans the WOPI host, the Collabora Online configuration and the users who handle sensitive files. We scope the controls against your document classes, build them inside infrastructure you control, and document where the controls stop, so your team knows what is enforced and what still depends on policy.
How we scope
- Written scope lists which document classes, user groups and WOPI hosts the restrictions cover, agreed before work starts.
- We record which permissions the host integration controls and which, if any, depend on Collabora Online features you must confirm.
- The scope names the limits in writing, including what copy and print controls cannot prevent on a user's own device.
How we build
- We configure integration-side permissions and group rules in your Nextcloud or other WOPI host, then test each rule with real accounts.
- Where secure view or watermarking is in scope, we build and test them against your document samples and check formatting fidelity.
- We test restricted sessions for download, print and clipboard paths, including direct links, API access and shared links.
How we hand over
- Deliverables include the configuration record, a test matrix with expected and observed results, and a list of known gaps.
- Runbooks explain how administrators grant or revoke restricted access and how to verify a rule after an upgrade.
- We document the residual risk statement so compliance and business owners sign off on what the controls do not stop.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so restrictions are rechecked after each release.
- Retainer work can cover re-running the test matrix when Collabora Online or the WOPI host moves to a new version.
- Ask us to confirm the support hours, response terms and upgrade scope in the written quote before you commit.
