Security Guidelines

Also known as the principle of minimal privilege, the Principle of Least Privilege dictates that a workload should only be given the minimal set of permissions it requires in order to operate. APOC offers a wide range of functionality which is unlikely to be used in its entirety by any given APOC installation. Users are recommended to only enable those procedures and functions that are strictly needed. Users are recommended to disable any other procedures and functions.

By only enabling the bare minimum required, users will reduce the risk incurred by running vulnerable procedures, while also supporting their functional requirements.

Also known as the principle of redundancy, the Principle of Defence in Depth dictates that users secure their installations at every level of the software stack, even though it may seem redundant to do so.

APOC is built on top of interfaces that are exposed and controlled both by the database and by the operating system. By securing an APOC installation using the defense in depth approach, the installations are wrapped in multiple layers of protection, thus mitigating the risk of failure of the protection mechanisms at any layer. If installations are protected by APOC, by the database, and also by the operating system, then it is less likely that the protected workloads can be exploited by a single bug.

As the functionality provided by APOC is built on top of the database, installations cannot be secure unless the database is secure. The first point of order is therefore to ensure the database installation is secure, which can be achieved by following the existing database Security Checklist. This guide will revisit some steps that are covered by the checklist again in more detail.

APOC is a Neo4j extension with a lot more functionality than any given workload is likely to need. As is the case for any Neo4j extension, there are several control mechanisms that help ensure only required functions and procedures are installed onto the database.

APOC contains several procedures which can read or write to specific files on the file system. If misconfigured, these procedures can lead to high-impact vulnerabilities, such as Sensitive Data Exposure. If required by the workload, users need to enable procedures to be able to interact with the file system, but only in specific directories. If not required by the workload, users should restrict procedures from being able to interact with the file system altogether.

Examples of procedures that can read from the file system include apoc.import.* and apoc.load.*. Examples of procedures that can write to the file system include apoc.export.*. Examples of Cypher clauses that allow the database to read from the file system include LOAD CSV.

The Neo4j Knowledge Base offers excellent introductory guidelines on Protecting Against Cypher Injection which are recommended learnings in order to better appreciate the challenges related to Cypher injection.

Many APOC procedures make direct use of Cypher, and under the hood, they will build and execute new queries derived from the inputs they receive. These procedures represent an additional challenge for APOC users, who need to be able to recognise them, and understand the limited safety guarantees they are able to provide.

In the first example below, an initial query invokes the apoc.refactor.rename.label procedure, which in turn builds a second query behind the scenes and executes it. The second query fetches all nodes, removes a label, and then reattaches a different label.

In the second example below, an initial query invokes the apoc.cypher.run procedure, which in turn builds a second query behind the scenes and then executes it. The second query fetches all nodes and returns them.

Both of the procedures in the above examples build and execute new queries derived from the inputs they receive. The only difference between these two procedures is the inputs they receive. In the first example, the procedure knows the inputs represent Cypher Literals. In the second example, the procedure knows the input represents a whole Cypher query. The inputs in the first example can be sanitized, whereas the input in the second example cannot be sanitized.

APOC guarantees it will sanitize inputs that correspond to a Cypher literal. However, APOC cannot offer the same guarantees for inputs which correspond to a whole Cypher query. In the latter case, the responsibility to sanitize the Cypher queries is delegated to the user, and users are recommended to carefully follow the aforementioned Cypher Injection guidance.

APOC provides a range of hashing functions that provide the ability to convert any object to a fixed-length uniform string. This capability has a number of applications, both cryptographic and non-cryptographic. Cryptographic applications may include message digests and password verifications, whereas non-cryptographic use cases may include distributing data uniformly and data deduplication. Using an APOC hashing function which is cryptographically unsafe for use cases that require cryptographic safety can lead to high-impact vulnerabilities such as Weak Encryption.

The key determinant in deciding whether a hashing function provided by APOC is cryptographically secure is whether it possesses the property of irreversibility. A hashing function is considered irreversible if it is easy to compute a hash given an input, but hard to compute the original input given its hash.

When using hashing functions it is important to first analyse whether a workload requires an irreversible hash, and to then determine whether the hashing algorithm provided by a given APOC function is able to provide this property. It is recommended to keep up to date with the latest security research, as weaknesses are sometimes found in hashing functions that were once believed to be irreversible.

If a workload does not require an irreversible hash, then the cryptographically unsafe hashing functions provided by APOC are preferable since they should execute faster.