Hardening a ProjectSend Instance

Keeping a ProjectSend instance secure comes down to a few practices: staying current with releases, terminating TLS at your reverse proxy, enabling TOTP two-factor authentication, issuing API tokens with only the abilities they need, and scanning uploads for malware. This note is based on ProjectSend 2.7.0 (October 2026).

The hardening checklist

Here is the full list, in order of impact:

• Stay current: update promptly as releases come out; security fixes arrive regularly
• HTTPS: terminate TLS at your reverse proxy and bind the container port to loopback
• Two-factor authentication: enable TOTP for all staff accounts
• Roles: grant only the permissions each role needs
• API tokens: tick only the abilities each token needs; always set an expiry
• Virus scanning: add ClamAV for installations that accept uploads from client accounts
• Backups: back up the database, the uploaded files, and APP_KEY together
• Encryption at rest: not in the 2.x -- handle at the storage layer if you need it

The sections below explain each one.

Keep up to date

ProjectSend 2.x has included security fixes in nearly every release. The 2.2.1 release was a dedicated security release, closing several ways a staff member could reach past the application's own access boundaries. The 2.4.0 release closed three ways someone could see more than they should. The 2.7.0 release (October 2026) fixed four security issues, including an API token that could change its own owner's credentials.

The dashboard's System card shows the running version and has a Check now button that queries GitHub and reports whether a newer release exists. Once you update, the notice disappears on its own -- it compares against the installed version on every page load. For the update procedure -- what to back up first, the two Docker commands, and what to do when something goes wrong -- see Updating ProjectSend.

HTTPS and your reverse proxy

ProjectSend is meant to run behind a reverse proxy that terminates TLS -- nginx, Traefik, Caddy, or Nginx Proxy Manager. Two settings matter on the ProjectSend side.

First, set TRUSTED_PROXIES in the Docker environment. Without it, the application does not know it is behind a proxy, session cookies are marked non-secure, and the first authenticated form submission usually returns a 419 error. With it set correctly, the download log and the activity trail record real client addresses rather than the proxy's IP. The compose.example.yaml file already sets this.

Second, publish the container port on 127.0.0.1 rather than on every network interface. With TRUSTED_PROXIES: "*" set, anything that can reach the container port directly can claim any client address -- bypassing the login rate limiter and the address recorded in the download log. The 2.3.0 release corrected the example file on this point. The Running ProjectSend with Docker note and the Docker guide cover both settings in detail.

Two-factor authentication

ProjectSend 2.x supports TOTP two-factor authentication -- the kind that uses an authenticator app (Google Authenticator, Authy, 1Password, or any TOTP-compatible app) and generates recovery codes. It does not send one-time codes by email in the 2.x.

Each staff account sets it up in their profile. Administrators can require two-factor authentication for specific roles under Settings → Security → Two-factor authentication.

As of 2.7.0, accounts that sign in through a provider (Google, Microsoft, or LDAP) receive their first password through an email link, rather than from whoever holds the browser session. If your installation cannot send email, an administrator sets the first password from the account's edit screen.

Roles, permissions, and API tokens

Use the minimum permissions each role genuinely needs. Uploading to public folders, modifying other people's files, and managing clients are separate abilities -- they do not have to be combined in a single role.

For API tokens, the same principle applies: grant only the abilities the token needs for its specific task, and always set an expiry. The default is 90 days; the maximum is 365.

As of 2.7.0, the token creation screen shows a warning when you choose Edit clients or Edit users: a token with either ability can sign in as any account below its owner that it may edit, and act as that account. Give these abilities only when you would trust the token's holder with those accounts themselves. Checking the activity log periodically is the fastest way to spot a token doing more than expected.

The API guide has the full list of abilities and what each one unlocks.

Virus scanning for uploads

If clients can upload files to your installation, the ClamAV integration (added in 2.5.0) scans each upload before anyone can download it. Files the scanner refuses go to a Quarantine screen where you can review and release them.

On Docker, the scanner is an extra container:

docker compose --profile scanner up -d

Then go to System → Settings → Virus scanning, enable it, and enter tcp://clamav:3310 as the address. The Test scanner button sends a harmless test file (EICAR) and confirms the scanner caught it.

Two things to know before you enable it: the scanner needs about 1-1.5 GB of memory for its virus definitions, and the first start takes a few minutes to download those definitions. The Docker guide's virus scanning section has the compose config section to keep when you edit the file.

Backups and the APP_KEY

Three things to back up together: the database, the uploaded files, and APP_KEY stored in storage/.env. The key decrypts the saved SMTP and LDAP passwords in the database. Losing it while keeping everything else means those credentials are unreadable -- silently, with no immediate error.

The Running ProjectSend with Docker note covers the backup commands and the restore procedure for Docker, including why bind-mounting the storage volume is the approach we recommend. The same three pieces exist at different paths on a manual install; the principle is the same. Test the restore at least once on a different machine: a backup that has never been restored is a hypothesis.

What the 2.x does not do yet

ProjectSend 2.x does not encrypt files at rest. The Legacy generation did; the 2.x does not yet -- the comparison table on the home page notes "Not yet in 2.0". If your use case requires file-level encryption, handle it at the storage layer: full-disk encryption on the host, or server-side encryption on your S3-compatible bucket. Neither requires changes to ProjectSend itself.

The 2.x includes access controls, download limits, expiry, and a complete activity trail -- capabilities that may support certain compliance obligations. It does not carry formal certifications, and the assessment of what your own requirements demand is yours to make.

Questions

If something here does not match what you see on your install, ask on Discord or open an issue on GitHub. The docs live in the repository, so corrections are welcome as pull requests.