How to Harden Nextcloud for an A+ Security Headers Rating

An A+ result from a security-header scanner is a useful configuration target, but it is not a complete security certification for a Nextcloud server. The rating reflects the HTTP response headers that a particular scanner checks at the URL it tested. It does not inspect your database, operating system, backups, user accounts, installed apps, or patch process. A safe hardening plan therefore starts with Nextcloud’s own health checks, then secures the server and its public-facing web layer, and finally retests the exact public URL.

This guide follows the current Nextcloud 35 Administration Manual available in October 2026. Configuration examples can differ between Apache, NGINX, containers, and reverse-proxy deployments. Confirm every change against the documentation for your server version and deployment before applying it.

Quick checklist

• Back up the database, data directory, and configuration before changes or upgrades.
• Install supported Nextcloud, PHP, database, operating-system, and app updates.
• Use HTTPS for every public connection and redirect HTTP to HTTPS.
• Enable HSTS only after HTTPS works across the domain and any affected subdomains.
• Keep the data directory and sensitive configuration outside the web root where practical.
• Use multi-factor authentication (MFA) for administrators and, where appropriate, all users.
• Configure trusted proxies narrowly; never trust arbitrary forwarded client-IP headers.
• Resolve Nextcloud Administration Overview warnings and test headers on the public endpoint.

1. Establish a safe baseline

Before changing headers or PHP settings, identify how the request reaches Nextcloud: directly through Apache or NGINX, through a container proxy, or through a managed load balancer. Record the Nextcloud version, PHP version, database type, enabled apps, and TLS termination point. Keep a copy of the active virtual-host or proxy configuration so you can roll back a broken change.

Make a restorable backup of the database, the complete data directory, and the Nextcloud configuration, including config.php. A file copy alone is not a complete backup: confirm that you know how to restore all three components together. Nextcloud’s update documentation specifically warns that its updater does not back up the database or data directory. See Nextcloud’s upgrade and backup guidance.

Log in as an administrator and open Administration settings, then Overview. Review the security and setup warnings, as well as background-job and database warnings. A clean overview is a useful application-level check, but it does not replace operating-system patching or an external header test. Avoid suppressing a warning until you understand its cause.

2. Patch Nextcloud and its host

Run a supported Nextcloud release with a supported PHP and database combination. Apply maintenance releases promptly, and review app compatibility before moving to a new major release. Update the operating system, web server, PHP runtime, database server, and installed Nextcloud apps through their supported update channels. Remove apps that are unused or no longer maintained, because each enabled component adds code and maintenance work.

Before an update, verify the backup and read the release notes for the target version. Use the supported updater for your installation type, then complete any required database migration and check the administration overview and logs. Do not downgrade by copying older application files over a migrated instance; Nextcloud documents downgrade as unsupported and recommends restoration from a compatible backup when a rollback is necessary.

3. Protect credentials and accounts

Use MFA and reduce administrator exposure

Enable a maintained two-factor authentication provider and require MFA for administrator accounts. Nextcloud’s 2FA support is provided through apps, so confirm that the selected provider is compatible with your release and that users have a recovery path before enforcing it. Keep emergency recovery codes offline and secure. Do not disable brute-force protection to solve login delays; investigate the source IPs and proxy configuration instead.

Use individual administrator accounts for routine work and grant administrator rights only where needed. Choose unique, long passwords and use a password manager. Revoke lost-device sessions and app passwords promptly. Review accounts, groups, public shares, and external storage on a schedule, removing access that no longer has a business need.

Keep brute-force protection effective

Nextcloud brute-force protection is enabled by default. Its effectiveness depends on the server seeing the real client IP address. If Nextcloud is behind a proxy, configure only the actual proxy address or network in trusted_proxies, and set forwarded_for_headers only to the header your proxy controls. Trusting a header that a client can forge can undermine IP-based protections. Avoid broad whitelist entries: excluded addresses can make authentication attempts without throttling. Review the brute-force protection documentation and the reverse-proxy configuration guide.

4. Reduce exposure from files and server configuration

Place the Nextcloud data directory outside the web root so a web-server mistake is less likely to expose stored files. Restrict filesystem ownership and permissions to the service account and administrators who need access; do not make the directory world-readable or world-writable. Protect config.php, which contains database credentials and instance secrets. The Nextcloud 35 hardening guide also documents moving the configuration directory outside the web root with NEXTCLOUD_CONFIG_DIR; set it consistently for the web process and command-line jobs, then verify that the instance still loads the intended configuration.

Keep production debug mode disabled. Enable operating-system hardening such as SELinux where supported and understood by your team. If you run in a container, protect the host, persistent volumes, container registry credentials, and management interface as well as the Nextcloud application. Restrict inbound network access to the services that must be public; do not expose a database port or administrative shell to the internet.

Nextcloud supports features that make outbound connections to other systems, so network segmentation and firewall policy matter. Place the instance in an appropriately restricted network zone and allow only the outbound destinations your enabled features require. The exact allowlist depends on apps and deployment choices.

5. Configure HTTPS and HSTS carefully

Serve the site with a valid TLS certificate and redirect all plain HTTP requests to HTTPS. Test the certificate chain, renewal process, and every hostname users actually access. The Nextcloud hardening guide recommends HTTPS and documents HSTS. HSTS tells browsers to keep using HTTPS for a period after they have received the policy, so enable it only after HTTPS works reliably.

Start with an HSTS policy appropriate to your environment, for example Strict-Transport-Security: max-age=15552000, then increase the duration after monitoring. Add includeSubDomains only if every affected subdomain supports HTTPS. Treat preload as a separate, high-impact decision: browsers may retain a preloaded domain for a long time, and removal can take months to reach users. Do not copy a preload example without checking all subdomains and the current requirements. TLS options vary by server and client needs; use Nextcloud’s linked TLS guidance and test the resulting endpoint.

6. Set response headers at the correct layer

Nextcloud already supplies several security headers, including X-Content-Type-Options, X-Frame-Options, X-Robots-Tag, and Referrer-Policy. Its documentation recommends ensuring security-related headers are served by the web server as well, so they remain effective for static responses. Apache deployments should confirm that the relevant modules and Nextcloud’s .htaccess rules are active. NGINX deployments must use the current Nextcloud NGINX configuration rather than assuming Apache rules apply. See the Nextcloud hardening guide and its NGINX configuration.

A common source of confusing results is setting the same header in Nextcloud, the web server, and a CDN or reverse proxy. The response can then contain duplicate or conflicting values. Choose the layer that owns each header, check the final response seen by a browser, and avoid replacing Nextcloud’s Content Security Policy with a generic policy copied from another site. A strict CSP may break scripts or features that Nextcloud and its apps need. Test policy changes on a staging host and inspect browser errors before production rollout.

For a scanner to report the intended result, test the final HTTPS URL users visit, including redirects and any CDN or proxy hop. Check both the landing page and a static asset, because different layers may return different headers. Confirm that HTTP redirects to HTTPS and that the final response contains one consistent value for each header. Use curl -I https://your-cloud.example as a quick check, then use a browser’s developer tools or an external scanner for the actual public response. Replace the example hostname with your own; do not publish private hostnames or credentials in scan reports.

7. Verify the result without mistaking a grade for security

Run the SecurityHeaders.com test against the public HTTPS URL and read every finding, not just the letter. Its FAQ describes the grade as an assessment of the security-related response headers its service checks. A+ therefore means the tested response met that service’s current scoring rules; it does not mean Nextcloud is vulnerability-free or that the entire server has passed a penetration test. Different scanners can grade the same configuration differently, and scoring criteria can change.

If the result is below A+, identify the exact missing or conflicting header, determine which layer should set it, and change one item at a time. Retest after each change and exercise login, file upload and download, desktop and mobile sync, WebDAV, sharing, and any critical apps. If behavior breaks, roll back the last header change and inspect the server and browser logs. Never add a broad Content Security Policy solely to satisfy a grade without checking the application’s documented requirements.

Final hardening review

• Can you restore the database, data directory, and configuration from a recent backup?
• Are Nextcloud, the host, PHP, database, web server, and enabled apps within supported update channels?
• Does every public hostname use HTTPS, with HSTS scoped only to domains that are ready?
• Are data and configuration files outside public reach with restrictive permissions?
• Do administrator accounts use MFA, and are stale accounts, sessions, and app passwords removed?
• Does Nextcloud see real client IPs through a narrowly trusted proxy configuration?
• Are Administration Overview warnings understood and resolved where applicable?
• Does the external header test show a consistent result for the final public response, and do normal Nextcloud workflows still work?

For version-specific steps, consult the Nextcloud 35 hardening and security guidance, the upgrade guide, and the documentation for your web server or hosting platform. The most useful outcome is a server that stays updated, is recoverable, limits exposure, and continues to work after each security change—not a letter grade by itself.