Confluence Security

Application Security Overview

As a public-facing web application, Confluence's application-level security is obviously important. This document answers a number of questions that commonly arise when customers ask us about the security of our product.

This document is for system administrators looking to evaluate the security of the Confluence web application. It does not address Confluence's internal security model – user/group management and content permissions – except as it relates to the overall application security.

Password Storage

When Confluence's internal user management is used, passwords are hashed through SHA1 before being stored in the database. There is no mechanism within Confluence to retrieve a user's password – when password recovery is performed, a new random password is generated and mailed to the user's registered address.

When external user management is enabled, password storage is delegated to the external system.

Buffer Overflows

Confluence is a 100% pure Java application with no native components. As such it is highly resistant to buffer overflow vulnerabilities – possible buffer overruns are limited to those that are bugs in the Java Runtime Environment itself.

SQL Injection

Confluence interacts with the database through the Hibernate Object-Relational mapper. Database queries are generated using standard APIs for parameter replacement rather than string concatenation. As such, Confluence is highly resistant to SQL injection attacks.

Script Injection

Confluence is a self-contained Java application and does not launch external processes. As such, it is highly resistant to script injection attacks.

Cross-site Scripting

As a content-management system that allows user-generated content to be posted on the web, precautions have been taken within the application to prevent cross-site scripting attacks:

The wiki markup language in Confluence does not support dangerous HTML markup
Macros allowing the insertion of raw HTML are disabled by default
HTML uploaded as a file attachment is served with a content-type requesting the file be downloaded, rather than being displayed inline
Only system administrators can make HTML-level customisations of the application

When cross-site scripting vulnerabilities are found in the Confluence web application, we endeavour to fix them as quickly as possible.

Transport Layer Security

Confluence does not directly support SSL/TLS. Administrators who are concerned about transport-layer security should set up SSL/TLS at the level of the Java web application server, or the HTTP proxy in front of the Confluence application.

For more information on configuring Confluence for SSL, see: Adding SSL for Secure Logins and Page Security

Session Management

Confluence delegates session management to the Java application server in which it is deployed. We are not aware of any viable session-hijacking attacks against the Tomcat application server shipped with Confluence Standalone. If you are deploying Confluence in some other application server, you should ensure that it is not vulnerable to session hijacking.

Plugin Security

Administrators install third party plugins at their own risk. Plugins run in the same virtual machine as the Confluence server, and have access to the Java runtime environment, and the Confluence server API.

Administrators should always be aware of the source of the plugins they are installing, and whether they trust those plugins.

Administrator Trust Model

Confluence is written under the assumption that anyone given System Administrator privileges is trusted. System administrators are able, either directly or by installing plugins, to perform any operation that the Confluence application is capable of.

As with any application, you should not run Confluence as the root/Administrator user. If you want Confluence to listen on a privileged network port, you should set up port forwarding or proxying rather than run Confluence with additional privileges. The extra-careful may consider running Confluence inside a chroot jail.

Vulnerabilities, Advisories and Patches.

If you find a security bug in Confluence

Open an issue on http://jira.atlassian.com in the Confluence project.

Set the priority of the bug to "Blocker"
Provide as much information on reproducing the bug as possible
Set the security level of the bug to "Developer and Reporters only"

All communication about the vulnerability should be performed through JIRA, so we can keep track of the issue and get a patch out as soon as possible.

Confluence Security Advisories

When a security issue in Confluence is discovered and resolved, we will inform customers through the following mechanisms:

A security advisory will be posted on this page
A copy of the advisory will be sent to the confluence-users and confluence-announce mailing-lists (subscribe here).
If the person who reported the issue wants to publish an advisory through some other agency (for example, CERT), we'll assist in the production of that advisory, and link to it from our own.

Our Patch Policy

When a security issue is discovered, we will endeavour to:

issue a new, fixed Confluence version as soon as possible
issue a patch to the current stable version of Confluence
issue patches for older versions of Confluence if feasible

Patches will generally be attached to the relevant JIRA issue.

Past Security Advisories

Related Server Security Pages

Content by label

There is no content with the specified labels