TL;DR
This is Part 3 of a three-part series on Collabora’s Security Architecture detailing the company’s multi-layered ‘security onion’ strategy.
In Part 1 we explained how Collabora Productivity’s security strategy is built on organisation compliance from our ISO 9001 and ISO 27001 certifications and large-scale continuous automated crash testing, fuzzing and regular static code analysis.
In Part 2, we continued revealing Collabora’s multi-layered ‘security onion’ by exploring the architecture of Collabora Online’s three main processes.
This part outlines how Collabora Online (COOL) secures documents through a WOPI-like REST protocol rather than managing file storage directly. Security is enforced at this layer by validating connection requests exclusively from trusted hosts using access tokens and RSA-signed proof keys.
To prevent data leaks, the server-side engine renders a document into heavily compressed, unique image tiles that are sent to the client (iframe) for display. This server-centric approach enables “Secure View” features and enables administrators to enforce granular permissions—such as disabling copying, pasting, and downloading—and overlay dynamic, user-identifying watermarks onto the rendered tiles.
Finally our whole security approach is backed by Collabora’s engineering team which actively maintains security through a daily cycle of tracking upstream dependencies, patching external libraries, and conducting audits and intensive automated fuzz testing. Outside of regular updates, the company releases timely security advisories with CVSS ratings to help prioritise vulnerabilities.
Document security, active maintenance and support
In the first two parts of this series, we explored how our company-wide ISO compliance and rigorous automated testing lay the groundwork for our security (read part 1). We also peeled back the three main processes of Collabora Online that integral to our “security onion” strayegy, detailing how CoolWSD, CoolForKit, and CoolKit isolate document processes on the server (read part 2). In this final part, we’ll cover document storage and how document information is transported and rendered on an end-user’s screen securely, and the active security maintenance our engineers undertake every day.
WOPI-like Protocol for Storage
Collabora Online (COOL) itself does not handle file storage. Instead, COOL integrates with existing platforms, such as Enterprise File Synch and Sharing (EFSS) systems, that provide a host server, where documents are held and retrieved by user requests. Inspired by the open standard, we use Web Application Open Platform Interface (WOPI), Collabora’s WOPI-like REST-based protocol that enables web-based applications to view and edit files.
COOL’s hosting options are very flexible, it can be hosted on-premise, in the cloud, in a private data centre or by a preferred hosting provider. As well as providing greater data control, there is greater potential for ensuring significant data sovereignty, depending on how hosting is implemented.
WOPI can be thought of as a ‘communication bridge’ between the chosen file storage (WOPI host) and CoolWSD (which WOPI treats as the WOPI client). In terms of security, and as mentioned above, CoolWSD authenticates and validates any incoming connection requests by sending on an access token from the client via WOPI request to the designated WOPI Host. Collabora Online will only accept connection requests from trusted WOPI host names and / or IP addresses, which the administrator lists in the storage.wopi block.
Access Control
The user client JS iframe post provides a WOPI server host to interact with (in a WOPISrc parameter) as well an access token. COOLwsd matches the WOPISrc against configured allow/deny storage.wopi (see above), and if successful requests access control information using the CheckFileInfo REST method. The remote WOPI-like server then provides access permissions to CoolWSD for the file. The permissions are enforced on the server-side, with advisory UI updates in the client.
Signing WOPI requests
COOL signs and timestamps each request to prove that they have come from our server. A WOPI proof keypair can be included in the configuration, which COOL can use to sign every WOPI request with this private key, while the matching public key is advertised in the public discovery information. The RSA key pair required for this can be re-generated by running coolwsd-generate-proof-key, if necessary. We recommend that an integration that does not check the WOPI proof-key should block WOPI requests except when they originate from the COOL server. That can be done by configuring an edge proxy or firewall.
You can learn more about how WOPI works in this recent blog.
| Security in WOPI |
|---|
| Access control: WOPIsrc is matched against COOL’s allow/deny list of acceptable WOPI storages, and will only accept documents and edits from approved WOPI storages. |
| WOPI proof key: COOL uses an RSA key pair and a timestamp to certify the server origin and time of each request. |
| Physical security: Using a WOPI-like approach to hosting means COOL can be hosted on-premise, in a private cloud or private data centre, and behind as many layers of network security e.g., VPNs as a user wishes. |
Document Security
COOL’s server-side approach means that browser clients have very limited access to document information. The original document never leaves the file storage (WOPI host), and clients receive rendered image tiles (see, below). Access control and policy enforcement stays on the server where it belongs, and not in the browser’s JavaScript. This contrasts with other solutions where often the first step is to download the full content of your documents to the browser client.
Tile Rendering & Secure View
A document is rendered into raster images on the internal Kit instance (‘document engine’) and the images are heavily compressed, in both space and across time, and sent as pre-defined tiles to the client (iframe) for display. Modifications to the document are tracked on the client. When the current user or another user collaborating on a displayed document makes a change, Kit sends an invalidation notification to all active clients, often along with a tile content delta update for any visible tiles that are affected. Each tile is unique and rendered by its coordinates on the page, its size and zoom level. To increase performance, tiles are cached in Kit and served to multiple users that request the same unique tile.
Collabora’s Secure View feature takes advantage of this technology to offer a high-degree of practical document security and provides the option to add watermarks to rendered tiles with user identifying information. Administrators can apply powerful policy rules on top of our granular per-user access controls, customising watermarks and permissions. A WOPI storage can provide a number of security related JSON properties specific to each user controlling policy and permissions. For example, whether a user can comment, edit, print, copy/paste or download a document. For instance, when DisableCopy is set Collabora Online will refuse to serve any textual content for selections to the browser. In addition, server-side logging can trace who accessed a document and when.
Access Control
All permissions, access control and storage for documents is handled by our WOPI-like protocol and the access control data is provided via a CheckFileInfo REST method.
There are a number of settings that an integration can provide to enable granular security permissions for a given user. These are enabled by returning extended properties as JSON from an integration’s implementation of the CheckFileInfo REST call. For fuller documentation please read our SDK’s Advanced Integration section.
Controlling Filetypes in Apps
Using the discovery.xml, administrators can define which COOL application can be used for a certain file type and what action should be used, for example opening Writer in read-only, but with adding or editing comments available.
The supported actions are “edit”, “view” and a special “view_comment”. When the action is “edit”, the document will open for editing. When the action is “view”, the document will open in read-only mode for viewing. When the action is set to “view_comment”, the document will open read-only, but adding or editing comments will still be possible.
Content Security Policy
The Content-Security-Policy response header enables administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks. Extensions to security policy to allow integrations to do more can be made in the content_security_policy in the net section of the coolwsd.xml file.
Active Security Maintenance
Behind the scenes, our security engineers take a proactive approach to maintaining security and pursuing potential security issues. As part of a daily cycle, they track up-stream projects, research and study the latest security intelligence, developments, proof of concepts and package announcements and carefully follow CVE-tracked external library updates and dependency fixes for libraries bundled in Collabora products. In addition, sometimes libraries require patching depending on the age of supported branches. Commits for new versions of external libraries are tracked to ensure actively developed product release branches are updated correctly.
All the main components continuously undergo intensive automated validation, such as, for example, fuzz driven testing of CoolKit, the document engine, and online-side WSD. As well as explicit crash and static analysis fixes, the team undertakes thorough security campaigns for vulnerabilities reported internally and externally.
Our security engineers carry out other proactive measures, such as improving error reporting on specific features and other fixes, for example CI / build plumbing, that aren’t specifically security fixes, but help raise the validation rate of security-relevant fixes.
Outside of regular security updates, Collabora Online will release a timely update to address specific vulnerabilities in a layer of protection to help partner and customer security teams prioritise a security issue. Alongside any update, we publish a security advisory, assigning CVSS ratings to any vulnerability which clearly indicates the nature of the vulnerability, recommendations on versions affected and advice on what version to upgrade to.
Collabora also publishes a low-traffic security newsletter which provides security announcements for Collabora Office and Collabora Online, which anyone can subscribe to.
Our products are fully supported by a full-time team. Our Level 3 code-fix support contracts include a dedicated support platform and direct contact with engineers. This is further enhanced with a full and complete range of technical documentation, comprehensive SLAs and signed security updates.
Evaluate Collabora Online for your organisation today and try a pilot deployment of a document editor that keeps your data entirely within your control.
