Magnolia 6.1 reached end of life on March 31, 2021. This branch is no longer supported, see End-of-life policy.
This page explains how we ensure that Magnolia is a secure platform for your project.
There is no single certificate that would validate a Web application as secure. Magnolia is a platform, which means security depends on the environment Magnolia is deployed in and on your project-specific implementation.
Only you know the specifics of your environment and your business. For any given application, there may not be a threat agent that can perform the relevant attack, or the technical impact may not make any difference to your business. Therefore, you should evaluate each risk for yourself, focusing on the threat agents, security controls, and business impacts in your enterprise. – Open Web Application Security Project (OWASP)
OWASP Top 10 is a list of critical web application security risks. While there is no certificate that could certify the Magnolia platform as secure, OWASP Top 10 is a very reasonable checklist. It's a good idea to validate your project implementation against the Top 10.
Magnolia is inherently protected against OS and SQL injections by not using direct access to the OS or database in any way. All access to database and OS data is handled via JCR APIs.
However Magnolia allows the implementor of a solution on top of Magnolia to use custom queries for SQL-like JCR search. The implementor is fully responsible for making sure that such custom queries can't be used by an attacker for injection.
Broken Authentication and Session Management
In order to make security configurable and allow integration with external security systems, Magnolia's security implementation is based on the Java Authentication and Authorization Service (JAAS) standard. The configuration of the JAAS login chain and implementation of JAAS modules provided by Magnolia are secure and handle user security correctly. However, it is the responsibility of the implementor to ensure that their custom configuration also behaves correctly and that by changing configuration they do not allow any insecure access.
Cross-Site Scripting (XSS)
All templates provided by Magnolia are continuously checked and improved to prevent any such attacks. In case of discovering any such vulnerability, Magnolia is fully committed to providing a fix immediately. The in-place templating functionality in Magnolia allows the client to apply a patch for the issue in a quick and easy manner to help protect their site. By default, Magnolia wraps all content nodes to prevent malicious input entered also by users who have access to the system such as an editor with malicious intent. However, since implementors often introduce custom templates with special functionality, it is the responsibility of the implementor to ensure that all such modifications are still safe from XSS.
Insecure direct object references
Magnolia doesn't expose any database objects, all database access is handled over the JCR API, nor any file object for direct user manipulation.
Magnolia delivers secure rather than insecure default configuration. Active action from implementor is required to make configuration insecure.
Sensitive data exposure
The only sensitive data used by Magnolia is user credentials. Those are either not stored in Magnolia at all but rather in LDAP/AD/custom security or when stored, Magnolia stores only a hash of such information. The hash itself is generated with slow hashing functions with additional complexity to prevent brute force, rainbow and other forms of attacks.
When storing sensitive additional data, the implementor has to ensure encryption of such data. Magnolia provides cryptographic libraries out of the box to make such a task as simple as possible.
Missing Function level Access Control
Magnolia security is based on node access, reading the data itself. Permissions are checked on every access to the data.
Cross Site request forgery (CSRF)
Session management is handled by the application server that Magnolia is deployed on, not by Magnolia itself.
Using components with known vulnerabilities
Magnolia is not aware of any vulnerabilities in the libraries used in the product at the moment. If at any point such a vulnerability is discovered, Magnolia immediately upgrades to a newer version of the library to avoid the issue or provides a workaround to be applied on top of the library to prevent an exploit.
Unvalidated Redirects and Forwards
Out of the box Magnolia doesn't forward any requests to other sites. When configuring such functionality in Magnolia, the implementor is fully responsible for preventing abuse of such features.
If you find a security vulnerability in Magnolia, please report it privately:
Our goal is to keep the vulnerability private. Issues in the SUPPORT project are private to Magnolia and the issue reporter.
All currently maintained Magnolia branches get security fixes backported if the branch is vulnerable. For example, if a vulnerability is reported in Magnolia 6.1 we backport the fix to Magnolia 5.7.
Maintenance releases for the current major version are available for the Community Edition as well as DX Core.
Maintenance releases for previous major versions of Magnolia are available to DX Core customers only (i.e. customers that have an active subscription to DX Core).