In recent years, I’ve seen a growing number of Drupal security issues that don’t come from the code — they start with how the server is configured and maintained.

I want to walk you through how I secure the server for any Drupal project I touch. This article is not full of theory. It’s based on real-world experience. If you’re a developer, site owner, or even a project manager, this will give you a solid understanding of what needs to be done and why. If you’re just starting out or planning an upgrade, you can also work with a team that handles both application and infrastructure hardening. Our Drupal web development services help you design security-first systems from the start.

Why server security is step zero

Drupal security starts with the machine your Drupal site is running on. You can install all the best modules, follow every Drupal coding guideline, and update everything daily, but if your server is misconfigured, it won’t help. A weak server setup is like building a bank with a glass front door. Drupal is secure, but it’s not magic. It depends on the environment it lives in.

That’s why we focus first on the server. Get that right, and you already reduce your risks by a huge margin.

Certificates: always start with HTTPS

Every site should use HTTPS. That’s not optional anymore. If you’re still running HTTP, you’re putting user data at risk. HTTPS encrypts the connection between the user and your server. That protects login details, session cookies, and form data.

I recommend Let’s Encrypt for certificates. It’s free, trusted, and easy to automate. Your setup should also redirect all HTTP traffic to HTTPS. Use a permanent redirect so browsers remember the preference. If you’re using NGINX or Apache, this is a one-liner in your config.

Don’t forget about HSTS. It tells browsers to always use HTTPS. That way, even if someone tries to reach your site through HTTP, the browser will refuse it.

Disable directory listing

If your server doesn’t find an index file in a directory, it might show a list of files to the user. That sounds small, but it’s actually dangerous. People could find configuration files, backups, or scripts that should stay hidden.

Turn off auto-indexing in your server config. In Apache, that’s Options -Indexes. In NGINX, use autoindex off;. Set it globally. Then check that it’s not re-enabled in any subdirectory or .htaccess.

Web application firewall

A Web Application Firewall, or WAF, helps stop a lot of attacks before they hit Drupal. I use Cloudflare and sometimes Sucuri, depending on the client’s needs. These services block common Drupal security threats like SQL injection and XSS at the edge.

If you manage your own server, you can install ModSecurity. It takes more work but gives you local control. Choose the OWASP core rule set. Keep it updated. Test carefully, because false positives are common.

PHP execution protection

This is a big one. In a proper Drupal setup, all requests go through one entry point, usually index.php. If someone can directly access other .php files, you’ve got a problem.

Many older servers or custom themes include random PHP files. If those files are directly accessible, someone could use them to execute malicious code. I’ve seen this happen. One forgotten file took down a whole site.

The fix is to block access to any .php files outside of the main entry point. In NGINX, you can write a rule that only allows index.php and blocks everything else. In Apache, use .htaccess rules to deny access to files you don’t need.

Backups: your last line of defense

No matter how secure your server is, something can still go wrong. That’s why backups matter. A good backup setup includes:

• Automated daily backups
• Offsite storage
• Version history
• Regular restore tests.

Back up both your codebase and your database. Store backups on a separate server or cloud storage. Don’t store them on the same machine. If someone gains access to the server, they shouldn’t find the backups sitting right there.

Updated software and the right stack

Your server stack – including the operating system, web server, database, and PHP version – needs regular attention. Don’t wait for major releases; apply security patches as soon as they’re available.

Make sure you’re running a supported PHP version, as older ones often come with known vulnerabilities – the same goes for MySQL or PostgreSQL.

Personally, I prefer a lean setup: NGINX with PHP-FPM and MariaDB or PostgreSQL. Keep it simple and avoid installing anything you don’t actually need.

Limit user access

Limit server access to your Drupal website security to those who truly need it, and always use SSH keys instead of passwords. Disable root login, and only grant sudo access when it’s absolutely necessary.

Clean up old accounts regularly – if a developer leaves the team, remove their key right away. It only takes a few minutes and can prevent serious risks.

For file access, set strict permissions. Drupal’s files directory shouldn’t be writable by the web server unless it’s required. And avoid 777 permissions – they’re never safe.

Restrict file uploads

Drupal allows users to upload files through forms, but the server still plays a role here. Don’t let uploaded files be executable. That means configuring your web server to treat them as static files only.

Set rules so .php, .js, or other executable extensions can’t be uploaded or executed. Also, validate the MIME type. A common trick is renaming malware.php to image.jpg. Drupal may see it as an image, but the server could still execute it if it’s not protected.

There are good modules for this in Drupal, but your server should also be ready to stop bad files before they cause damage.

Use fail2ban

Fail2ban scans your logs for bad behavior and blocks IP addresses that step out of line. It’s great against brute-force login attempts, spam bots, and repeated error requests.

Set up filters for SSH, NGINX, and other services. Ban IPs for a few hours after too many failed logins. It won’t stop targeted attacks, but it removes the noise.

Secure headers at the server level

You can and should add secure headers in Drupal, but setting them on the server adds another layer. These are the ones I always use:

• Content-Security-Policy (CSP): Defines where content can load from
• Strict-Transport-Security (HSTS): Forces HTTPS
• X-Content-Type-Options: Stops MIME-type sniffing
• X-Frame-Options: Prevents clickjacking

Add them in your NGINX or Apache config. They help a lot and don’t impact performance.

Firewall and port control

Use ufw, firewalld, or another tool to manage your firewall. Block everything by default. Only open the ports you need — usually 80, 443, and maybe 22 for SSH.

If possible, restrict SSH access to specific IPs. Use a different port than 22 to avoid basic scans.

Limit request sizes

One simple but often forgotten step is setting a maximum size for incoming requests. Without a limit, attackers can send oversized requests to overload the server or sneak in large, hidden payloads. This kind of behavior can lead to Drupal website security performance issues or even downtime.

It’s best to define a reasonable file upload limit and make sure the server won’t accept anything larger. The exact size depends on your site’s functionality — for example, if users need to upload images or documents — but the key is to have a cap in place. This protects your server from unnecessary strain and reduces the risk of abuse.

Environment separation

Never host development, staging, and production on the same server. If a dev site gets hacked, it could be used to jump into production.

Each environment should have its own machine, container, or VM. Also, don’t use real user data in lower environments. If you must, anonymize it.

Monitoring and alerts

Use a monitoring service – or set up tools like Prometheus and Grafana – to track CPU spikes, unusual traffic, failed logins, and file changes.

If you’re not watching logs or alerts, you’re essentially flying blind. Many security attacks start quietly, and by the time you notice, the damage is often already done.

Set up email alerts for critical events and make log reviews a regular habit. Staying proactive is the easiest way to catch issues before they escalate.

Rate limiting

You can limit how often a user can perform actions. This is useful for login forms, comment submissions, and any form, really.

Tools like ngx_http_limit_req_module in NGINX can help. Set rules to allow a few requests per second per IP. You’ll stop a lot of bots this way.

Disable unnecessary services

Many servers have services you never use: FTP, mail, and SNMP. Shut them down. If a service is running, it can be exploited. Make your server do only what it needs to do.

Don’t expose admin panels

If you use tools like phpMyAdmin, web-based deployment tools, or other dashboards, don’t leave them open to the internet. Restrict by IP. Or better, don’t install them unless you have to.

They’re convenient, but they’re also common targets. One weak password and it’s over.

Use minimal base images (for containers)

If you run your Drupal site in a container, use minimal base images. Alpine Linux is a good option. Don’t install tools or packages you don’t need.

Smaller containers mean fewer attack surfaces. It also makes it easier to audit your stack.

Enforce secure cookie settings

Your Drupal cookies should have the Secure and HttpOnly flags. That’s partly configured in Drupal, but the server should also enforce HTTPS and restrict access to cookies via JavaScript.

That way, even if someone injects a script, they can’t steal the session cookie. It’s a small change that makes a big difference.

Consider containerization

If you’re hosting multiple sites, consider putting each in its own container. Use Docker, Podman, or another tool to isolate environments.

This makes deployments cleaner and reduces cross-site risks. One mistake in Site A won’t affect Site B.

Final thoughts

Server-level security is not flashy. It’s not something you show in a client demo. But it’s one of the most important parts of building a secure Drupal site.

I’ve seen good code brought down by bad hosting. I’ve also seen simple servers hold strong because they were well configured. It’s not about doing something fancy. It’s about doing the basics really well.

Drupal security is not a one-time setup. You need to run a Drupal audit to find issues, test regularly, and adapt as threats change. But if you start with a solid server, you’ve already won half the battle.

I hope this article helps you think more seriously about your server. It’s the foundation of your entire Drupal site. If you build it right, it’ll hold everything else in place.

Author: Alex Lyzo

Alex Lyzo is an Acquia-certified specialist and Team Lead at Attico, with deep expertise in backend development and Drupal security.