This section describes how to ensure the security of custom-written additions in Neo4j.
Neo4j can be extended by writing custom code which can be invoked directly from Cypher, as described in Developer Manual → Procedures. This section describes how to ensure the security of these additions.
Neo4j provides sandboxing to ensure that procedures do not inadvertently use insecure APIs. For example, when writing custom code it is possible to access Neo4j APIs that are not publicly supported, and these internal APIs are subject to change, without notice. Additionally, their use comes with the risk of performing insecure actions. The sandboxing functionality limits the use of extensions to publicly supported APIs, which exclusively contain safe operations, or contain security checks.
The configuration setting
dbms.security.procedures.unrestricted provides the possibility to circumvent the sandboxing functionality by defining a comma-separated list of procedures and/or
user-defined functions that are allowed full access to the database.
The list may contain fully-qualified procedure names, and partial names with the wildcard
Any attempt to load an extension which contains an unsupported API, which has not been marked as allowed in
dbms.security.procedures.unrestricted, will result in a warning in the security log.
The warning will point out that the extension does not have access to the components it is trying to load.
Additionally, a mocked procedure will be loaded with the procedure’s name.
Calling the mocked procedure will result in an error, saying that the procedure failed to load due to needing more permissions.
In this example we assume that the procedure
my.extensions.example, as well as some procedures in the
my.procedures library, make use of unsupported APIs.
In order to allow the running of these procedures we configure the setting as shown below.
# Example sandboxing dbms.security.procedures.unrestricted=my.extensions.example,my.procedures.*
White listing can be used to allow loading only a few extensions from a larger library.
The configuration setting
dbms.security.procedures.whitelist is used to name certain procedures that should be available from a library.
It defines a comma-separated list of procedures that are to be loaded.
The list may contain both fully-qualified procedure names, and partial names with the wildcard
In this example we wish to allow the use of the method
apoc.load.json as well as all the methods under
We do not want to make available any additional extensions from the
apoc library, other than the ones matching these criteria.
# Example white listing dbms.security.procedures.whitelist=apoc.coll.*,apoc.load.*
There are a few things that should be noted about
*. This means that if you do not explicitly give it a value (or no value), all libraries in the plugins directory will be loaded.