ERPNext security hardening

Role permissions decide what a role can do on each DocType. In ERPNext, the Role Permission Manager and the permission rules on each DocType control read, write, create, submit, cancel, delete, export, print and report access for that role. The same role can hold broad rights on Sales Invoice and none on Stock Entry, so a role name alone tells you little. User permissions sit on top of these rules. They limit which linked values a user can see, such as a company, cost center or warehouse. A user with create rights on Sales Invoice who has a user permission for one company will only see and work with that company's records. Hardening starts by checking both layers separately, because a correct role can be silently widened or narrowed by the user permissions attached to the account.

Permissions drift over time. People move from sales to finance, from finance to stock, or take on cover for a colleague on leave. An administrator adds a role to unblock a task, and the change is rarely reversed when the task is finished. Each addition looks small, but a user can end up holding rights from several roles plus user permissions created for a previous job. Removing a role does not automatically remove the user permissions set up alongside it, so the review must cover both. Schedule a recurring access review, tie role changes to a request that names the business owner, and record who approved each change so drift is visible before an auditor or incident finds it.

The System Manager role should be rare. It gives broad administrative power across the desk, including configuration changes that affect every user, and it is designed for system administration rather than daily accounting or stock work. Ask for a list of every account that holds it and confirm that each holder needs it for administration, not convenience. Keep a small number of named administrators, give them separate accounts for everyday work, and make sure business users receive narrower roles that match their tasks. The Administrator account should be protected under its own controls and used only for break-glass situations. Treat any new grant of System Manager as a decision that needs a documented reason.

Review the role matrix with the business owners who will live with the outcome. Build a matrix with users or roles in rows, DocTypes and actions in columns, and user permission scopes noted for each. Ask the accounting owner who may post journal entries, change accounts, or close a period. Ask the stock owner who may create stock entries, adjust valuation, or work across which warehouses. Ask the production owner who may release work orders and issue materials. Look for segregation of duties problems, such as one person who can both create a supplier and approve its payment. Owners should sign off their own area, and sensitive rights such as access to scripts and bulk data import should be listed and approved separately.

Verify the matrix with test accounts rather than assuming it from role names. Create test users that carry each role and each user permission combination, then attempt the actual tasks on a test site that mirrors production configuration. Try to open, edit, submit, cancel, export and print records outside the permitted scope, and check list views, report results, link field search results and API responses, since these can expose data differently from the form view. Record each result with the user, the action and the outcome. Repeat the tests after every role change, every upgrade and every custom app or script deployment. Ask any implementation partner to include this testing in the written scope and to hand over the test accounts and results.

Each hardening control needs a test that tries to break it, written before go-live and repeated after every bench update, app change or role edit. Treat the control list as a set of claims and write one pass or fail check for each. Record the test account, the ERPNext and Frappe versions, the date and the expected result so a second engineer can rerun the same check. A single successful test proves little if the next update quietly reopens a gap.

Start with permissions. Create a non-admin test user with the role it would normally hold, limited to one company or customer through user permissions. Attempt to open, list, search, report on and export records outside that scope. Repeat the same attempts through the REST API, because list views and API calls can follow different code paths. Then confirm that Server Scripts stay unavailable. With server_script_enabled not set, a user should not be able to create or run a Server Script, and a call to a script endpoint should fail. Run this on your own environment, since Frappe Cloud public shared benches do not allow Server Scripts at all.

Next, test the access paths. Issue an API token with the narrowest scope you intend to allow, then call a DocType or method outside that scope and confirm the request is refused. Log in with a fresh browser session as a user whose role requires two-factor authentication and confirm the prompt appears. Remove a test account in LDAP or the identity provider and confirm ERPNext access ends. For transport, request the site over plain HTTP and confirm a redirect to HTTPS. From a machine outside your network, inspect the certificate chain, hostname match and expiry date with a tool your team already trusts.

Failure behavior matters as much as success. Enter wrong passwords repeatedly and confirm the lockout threshold and lock duration in your version's settings, then check that API calls cannot bypass the lock. Trigger errors with malformed requests and missing records, and confirm the error page shows a generic message without stack traces, file paths, database errors or framework version details. Then confirm denied actions reach your logs. Check the application logs, the reverse proxy access log and any audit trail, and verify each entry includes the user, timestamp and action. Confirm that retention is long enough for your incident process and that logs leave the host.

Finally, restore the latest backup onto a separate host running the same versions and apps. Log in, compare record counts and sample transactions against the source, and confirm the scheduler and background workers start. A restore that succeeds only on the original server does not prove recovery. An independent penetration test of the deployed environment is a separate engagement. Scope it in writing with the tester, agree on rules of engagement and test windows, and ask for findings that map to the controls above. Internal checks confirm the controls work as designed. An outside tester checks whether they can be bypassed.

Hardening an ERPNext instance is not finished at go-live. The controls you set on day one drift over time as people change roles, credentials age, certificates approach expiry and new minor releases ship. Assign a named owner for each recurring task below, and agree in writing which of them your internal team runs and which, if any, a partner covers under a retainer.

Start with access. Review users, roles and user permissions on a fixed schedule, and treat every role change as a security event. Leavers and movers are the most common source of excess rights in an ERP, because accounting and stock permissions often accumulate silently. Check the list of users with System Manager or other administrative roles separately, and confirm that Server Scripts remain disabled unless a documented need exists. Rotate API keys and secrets used by integrations on a schedule, and retire keys belonging to systems that no longer exist. For monitoring, watch failed logins and permission denials in your logs and your reverse proxy. Repeated failures from one account or address, or a sudden burst of denials on sensitive DocTypes such as Journal Entry or Payment Entry, should trigger investigation.

Patching needs its own routine. Frappe and ERPNext publish frequent minor releases for each supported major version, and the GitHub releases page shows this pattern. Track the releases for the version you run, then apply each one through bench update and bench migrate on a staging copy of production first, with your custom apps tested against it. Do not apply minor releases directly to production. The version support windows and the planning for major moves are covered in the upgrades section of this page series, so this section only concerns the routine of applying updates safely.

Backups count only when they restore. Schedule a restore test at a defined interval: restore the most recent backup to a separate environment, confirm that the site loads, that files are present and that a sample of transactions reconciles. Record the result, the time taken and any gaps. Also confirm that backups are stored outside the primary server and that the encryption keys needed to read them are held separately from the backup set. Renewing TLS certificates belongs on the same calendar. Check expiry dates for the Nginx certificate and any internal certificate authority, and test renewal on staging so that an expiring certificate does not become an outage.

Documentation is what allows someone other than the original builder to keep the system secure. Maintain five artifacts and keep them under version control: the permission matrix showing each role, its DocTypes and its user permission restrictions; the Server Scripts register listing each script, its owner, its purpose and the business reason it is enabled; the network and TLS configuration, including firewall rules, Nginx settings and certificate locations; the backup and restore runbook with the steps, owners and last successful test date; and a change log recording every permission change, script change, configuration change and applied update. An auditor or new administrator should be able to reconstruct the security state of the system from these records alone.