Page History

Magnolia is inherently protected against OS and SQL injections by not using a 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.

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.

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.

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. 

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.

Magnolia security is based on node access, reading the data itself. Permissions are checked on every access to the data. 

Session management is handled by the application server that Magnolia is deployed on, not by Magnolia itself.

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.

Out of the box Magnolia doesn't forward any requests to other sites. When configuring such a functionality in Magnolia, the implementor is fully responsible for preventing abuse of such features.