Neo4j Security: Authentication, Role Based Access and Cypher Injection

A graph database answers questions about relationships, so one over-broad role or one concatenated Cypher query can expose not just records but the connections between people, accounts and systems. Neo4j gives administrators the controls to prevent that: native, LDAP and single sign-on authentication, role based access control down to labels, relationship types and properties, TLS policies for every connector, procedure allowlists and detailed security and query logs. Growing use of graphs for GraphRAG and AI agent memory adds application identities that query the graph on behalf of users, which makes these controls more important. This guide covers self managed Neo4j and the customer side settings in Neo4j Aura, plus how to write Cypher that resists injection. It is written for database administrators, application developers and security architects. For general database controls, see the Database Security Guide.

This is an independent guide from NHI Mgmt Group, based on Neo4j's public documentation as of November 2026. It is not sponsored or reviewed by Neo4j. Product features change, so confirm settings against Neo4j's current documentation.

Key takeaways

• Set the initial password before first start. Use neo4j-admin dbms set-initial-password so the neo4j user never runs with its default password, and keep dbms.security.auth_enabled=true.
• Build custom roles, not admin for everyone. Built-in roles step from reader to admin; create application roles with GRANT and DENY on specific labels, relationship types and properties, remembering that DENY always wins.
• Parameterise every Cypher value. Parameters keep user input out of the query structure; avoid building labels from input and never concatenate into strings passed to APOC procedures that run Cypher.
• Require encrypted Bolt and HTTPS. Enable SSL policies and set server.bolt.tls_level=REQUIRED, since Bolt starts with TLS disabled until you configure it.
• Watch security.log and query.log. The security log records logins, administration commands and authorisation failures; the query log shows who ran what.

How identity and access work in Neo4j

Neo4j stores native users, roles and privileges in the system database. External providers can authenticate users and map their groups to Neo4j roles, and several providers can run together in a defined order.

Availability: Neo4j's documentation describes these authentication and authorisation features as Enterprise Edition capabilities, with a limited set of user management functions in Community Edition. Check the edition notes for the features you plan to use.

Native authentication settings

• Initial password: the default user is neo4j with password neo4j, which must be changed at first login unless set beforehand. Run neo4j-admin dbms set-initial-password before the first start, add --require-password-change when issuing a temporary value, and avoid putting the password on the command line where shell history keeps it.
• Password length: at least 8 characters by default, adjustable with dbms.security.auth_minimum_password_length; raise it to match your password policy.
• Lockout: dbms.security.auth_max_failed_attempts (default 3) and dbms.security.auth_lock_time (default 5s) slow guessing; tune both and alert on repeated lockouts.

Single sign-on details

For OIDC, keep auth_flow at its default pkce, which the documentation recommends always using, point well_known_discovery_uri at the IdP, and map groups with claims.groups and authorization.group_to_role_mapping. Neo4j checks the token's issuer and audience against configuration. Turn off dbms.security.logs.oidc.jwt_claims_at_debug_level_enabled in production. See the JWT Security Guide.

Admin roles and privileged access

Built-in roles are hierarchical, each adding to the one below. Every user also holds PUBLIC, which cannot be revoked but whose privileges can be changed.

Fine grained access control

Access to a graph element needs a GRANT and no matching DENY. DENY does not erase a GRANT; both exist, and DENY overrides. Read restrictions make data invisible, so the graph simply looks smaller, while write restrictions raise an error.

• Database access first: without the ACCESS privilege a user is denied the whole database, so grant ACCESS per database rather than relying on reader's all-database scope.
• Labels and relationship types: target NODES label, RELATIONSHIPS type or ELEMENTS label to limit what each role traverses and reads.
• Property based rules: FOR pattern grants or denies reads based on property values, useful for tenant or classification fields (not supported for write privileges).
• Immutable privileges: IMMUTABLE privileges can only be created or removed with authentication disabled, so they protect key rules from even an admin account.
• Review: SHOW ROLE <name> PRIVILEGES AS COMMANDS exports privileges as Cypher, ready for version control and diffing.
• Recreated databases: privileges are not restored when a database is dropped and recreated with the same name, so reapply them from source control.

For GraphRAG and agent workloads, give the retrieval service a role that can read only the labels and properties its users are entitled to, so the graph enforces permissions before content reaches a model. See the Permission-Aware RAG Guide.

Integrations, API tokens and service accounts

Applications connect over Bolt with driver credentials, and those application users usually hold more privilege than any person. Treat them as non-human identities with owners, scoped roles and rotation. See the Service Account Security Guide.

• One user per application: separate users for each service make the query log attributable and let you revoke one integration without touching others.
• Least privilege role: a read only application should hold a custom role with read on specific labels, never editor or admin, which limits the damage of any injection.
• Secrets storage: keep driver passwords in a secrets manager and inject them at runtime. See the Secrets Management Guide.
• Procedures and plugins: review dbms.security.procedures.unrestricted and dbms.security.procedures.allowlist so only intentionally exposed procedures are available, and restrict the plugins, lib and bin directories to the Neo4j operating system user.
• LOAD CSV: limit load privileges to trusted users, keep server.directories.import pointing at a dedicated directory, set dbms.security.allow_csv_import_from_file_urls to match your need, and allow only HTTPS sources.

Preventing Cypher injection

Neo4j's knowledge base describes Cypher injection as input that escapes its context and alters the query, the counterpart of SQL injection. The defences are application side:

LLM generated Cypher in text-to-Cypher and agent tools carries the same risk at a larger scale: run it under a read only, label restricted role and validate it before execution. See the SQL Injection Prevention Guide for the shared principles. Parameters also help Neo4j cache execution plans, so the secure pattern is the fast one.

Logging and detection

Passwords appear masked in the security log. Disable parameter logging where parameters carry personal or secret data. Alert on new users and role grants, on any grant of admin, on DENY rules being revoked, on authorisation failures from an application user, and on queries from a service account outside its normal patterns. Forward both logs to the SIEM; see the SIEM Guide.

Metrics that show it is working

• Number of users holding admin, reviewed monthly.
• Share of application users on custom least privilege roles rather than built-in editor or admin.
• Share of connections using encrypted Bolt or HTTPS (target 100%).
• Count of procedures on the unrestricted list, each with an owner.
• Code review findings for concatenated Cypher, trending to zero.

Hardening baseline

1. Before first start: set the initial password, confirm dbms.security.auth_enabled=true and set password length and lockout values.
2. TLS: create certificates/bolt and certificates/https directories with private.key (mode 0400) and public.crt from a trusted CA, enable dbms.ssl.policy.bolt.enabled and dbms.ssl.policy.https.enabled, set server.bolt.tls_level=REQUIRED, and keep tls_versions at TLS 1.2 and 1.3. Leave trust_all false and verify_hostname true.
3. Cluster and backup: enable the cluster and backup SSL policies, block the backup listener from outside, and if you do not cluster, bind server.cluster.listen_address and server.cluster.raft.listen_address to 127.0.0.1 and firewall ports 6000, 7000 and 7688.
4. Roles: create custom roles per application and team, grant ACCESS per database, trim PUBLIC, and store privilege scripts in version control.
5. Extensions: review procedure allowlists, LOAD CSV settings and remote JMX options in server.jvm.additional.
6. Files: set data, configuration and log directories to mode 700 or 750 on Linux (owner and service account only on Windows) and encrypt volumes, dumps and backups.
7. Single sign-on: configure OIDC with PKCE and group to role mapping for people, keeping native users for services.
8. Logging: confirm security and query logs reach the SIEM before go-live.
9. Test and roll back: apply changes in staging first and keep the previous neo4j.conf and privilege scripts for rollback.
10. Patching: run the latest patch release and follow Neo4j security advisories.

Neo4j Aura

In Aura, Neo4j runs the servers and the customer controls access, network exposure and keys. Aura documentation describes TLS 1.2 and 1.3 with a restricted cipher list for client connections, public, private or combined network access with the option to disable public traffic, private endpoints over cloud private link services and dedicated VPC isolation on AuraDB Virtual Dedicated Cloud and AuraDS Enterprise, and lists customer managed keys, IP filtering, single sign-on and multi-factor authentication among its security features. Database roles and Cypher practices above apply unchanged. Check the Aura documentation for the tier each feature requires.

Framework mapping

Common misconfigurations

• Disabling authentication to recover access and forgetting to re-enable it: the documentation advises disabling auth only with network connections blocked. Re-enable immediately and check security.log.
• Applications running as admin: an application on the admin role turns any injection into full control of users and databases (ATT&CK T1078 Valid Accounts describes misuse of such credentials). Use custom roles.
• Unencrypted Bolt: leaving server.bolt.tls_level at its default sends credentials and data in clear text. Set REQUIRED once clients are ready.
• Concatenated Cypher in APOC calls: passing user input inside the query string of apoc.cypher.run stays injectable even when the value is also passed as a parameter. Keep inner queries static.
• Open cluster and backup ports: an exposed backup port lets an unauthorised user copy the database. Firewall it and enable the backup SSL policy.
• Sensitive parameters in query.log: parameter logging records personal data and tokens. Disable it where parameters are sensitive.

Practitioner checklist

• The initial password was set before first start and dbms.security.auth_enabled is true.
• Password length and lockout settings match policy, and lockouts raise alerts.
• People sign in through OIDC with PKCE or LDAP over StartTLS, with groups mapped to roles.
• Admin is held by a small named group; applications use custom roles with ACCESS on specific databases and reads on specific labels.
• Privilege scripts are exported with SHOW PRIVILEGES AS COMMANDS and kept in version control.
• All application Cypher uses parameters, including inside APOC procedures, and code review checks for concatenation.
• Bolt and HTTPS SSL policies are enabled with server.bolt.tls_level=REQUIRED, and cluster and backup traffic is encrypted.
• Procedure allowlists, LOAD CSV settings and plugin directories are restricted and reviewed.
• security.log and query.log reach the SIEM, with parameter logging off for sensitive data.

Standards and references

• Neo4j: Authentication and authorization
• Neo4j: Built-in roles
• Neo4j: Role-based access control and privileges
• Neo4j: Security checklist
• Neo4j: SSL framework
• Neo4j: Protecting against Cypher injection
• Neo4j: Logging
• Neo4j: Aura secure connections

Related NHI Mgmt Group resources: Database Security Guide · Permission-Aware RAG Guide · Service Account Security Guide · SQL Injection Prevention Guide · Secrets Management Guide