Confluence Security Overview and Advisories

On this page

In this section

Still need help?

The Atlassian Community is here for you.

Ask the community

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:

Shared responsibility model

Atlassian believes security is a shared responsibility. We expect Data Center customers to apply security best practices while we deliver a secure product. Not applying our security best practices makes a product more likely to be affected during security incidents.

Use the extensive security checklist developed by the Data Center team to understand your responsibilities as a customer.

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.

Beyond user passwords, starting from version 9.1, Confluence automatically encrypts other passwords and configurations found in files.

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.

Cross-Site request forgery

Confluence requires an XSRF token to be present for update requests, to prevent the user's browser from being tricked into unintentionally performing malicious action.

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 apps (also known as plugins) at their own risk. Apps 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 apps they are installing, and whether they trust those apps.

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 apps, 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. Extra cautious administrators may want to 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 bigfixes 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.

Last modified on Dec 10, 2024

Was this helpful?

Yes
No
Provide feedback about this article

In this section

Powered by Confluence and Scroll Viewport.