Confluence Security Overview and Advisories
This document is for system administrators who want to evaluate the security of the Confluence web application. The page addresses overall application security. As a public-facing web application, Confluence's application-level security is important. This document answers a number of questions that commonly arise when customers ask us about the security of our product.
Other topics that you may be looking for:
- For information about user management, groups and permissions, please refer to the internal security overview.
- For guidelines on configuring the security of your Confluence site, see the administrator's guide to configuring Confluence security.
- For public security advisories and bulletins issued for Confluence (and all Atlassian Server and Data Center products), see Atlassian's Security Advisories & Bulletins.
Application Security Overview
Password Storage
When Confluence's internal user management is used, since version 3.5 of Confluence passwords are hashed through the salted PKCS5S2 implementation provided by Embedded Crowd before being stored in the database. There is no mechanism within Confluence to retrieve a user's password – when password recovery is performed, a reset password link is generated and mailed to the user's registered address.
When external user management is enabled, password storage is delegated to the external system.
On this page:
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 customizations of the application
When cross-site scripting vulnerabilities are found in the Confluence web application, we endeavor 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: Running Confluence Over SSL or HTTPS
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. 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.
Stack Traces
To help when debugging a problem, Confluence provides stack traces through the web interface when an error occurs. These stack traces include information about what Confluence was doing at the time, and some information about your deployment server.
This includes information such as operating system and version and Java version. With proper network security, this is not enough information to be considered dangerous. The username of the current user may be included.
Thread dumps include usernames and URLs by default. If you don't want to include this additional diagnostic information, you can disable Thread diagnostics.
Finding and Reporting a Security Vulnerability
Atlassian's approach to reporting security vulnerabilities is detailed in How to Report a Security Issue.
Publication of Confluence Security Advisories
Atlassian's approach to releasing security advisories is detailed in Security Advisory Publishing Policy.
Severity Levels
Atlassian's approach to ranking security issues is detailed in Severity Levels for Security Issues.
Our Security Bugfix Policy
Our approach to releasing patches for security issues is detailed in our Security Bugfix Policy.
Published Security Advisories
All security advisories for Atlassian Server and Data Center products are now published exclusively at atlassian.com/trust/security/advisories.