Website Server Security Checklist: 40+ Things to Secure Your Server

Website Server Security Checklist

A fast server is useful. A secure server is essential.

Website performance discussions often focus on CPU, memory, caching, response time, and Core Web Vitals. Security is sometimes treated as a separate concern, but the underlying infrastructure affects both.

A compromised server can lead to downtime, unauthorized changes, injected code, excessive resource consumption, data loss, and a long recovery process. Even when an attack does not directly affect visitors, cleaning up a compromised environment can become a significant operational problem.

Server security does not come from one plugin, firewall, or setting. It comes from reducing unnecessary exposure, keeping software maintained, controlling access, protecting data, and monitoring what happens on the system.

This checklist is designed for website owners, developers, and administrators who want a practical starting point for securing a web server.

Quick Answer

A secure website server should have:

• Current operating system and server software
• HTTPS configured correctly
• A firewall restricting unnecessary ports
• SSH protected and preferably limited to key-based authentication
• Strong administrator access controls
• Separate user accounts and least-privilege permissions
• Secure file and directory permissions
• Regular, tested backups
• Malware and intrusion monitoring where appropriate
• Secure database configuration
• Unnecessary services disabled
• Logs collected and reviewed
• Rate limiting or other protections for exposed services
• Automatic security updates where appropriate
• A documented recovery process

The exact configuration depends on whether you manage a VPS, dedicated server, cloud instance, managed hosting environment, or shared hosting account.

You should also avoid changing security settings blindly. A setting that is appropriate for one server can break another application’s functionality.

Website Server Security Checklist

Use the following as a practical audit.

1. Know What You Are Actually Running

Before securing a server, establish what is installed and exposed.

Record:

• Operating system
• Operating system version
• Web server
• Runtime versions
• Database server
• Control panel
• CMS
• Installed services
• Publicly exposed ports
• SSL/TLS configuration
• Server IP addresses
• Hosting provider
• Backup location
• Administrative accounts

You cannot properly secure infrastructure you cannot describe.

A simple inventory also makes future maintenance much easier.

2. Keep the Operating System Updated

Security vulnerabilities are regularly discovered in operating systems and their packages.

Install security updates promptly.

Check:

• Operating system updates
• Kernel updates
• OpenSSL or equivalent cryptographic libraries
• Web server updates
• Runtime updates
• Database updates
• Control-panel updates
• Security-related dependencies

Do not assume that an old version is safe simply because the website still works.

At the same time, major version upgrades should be tested before production deployment when compatibility could be affected.

3. Remove Unsupported Software

End-of-life software is a security risk because vulnerabilities may no longer receive fixes.

Review:

• Old PHP versions
• Unsupported Node.js versions
• Outdated Python runtimes
• Old database versions
• Deprecated server modules
• Abandoned plugins
• Unused control-panel components

If a service is no longer required, removing it is often better than leaving it installed and hoping it remains harmless.

4. Disable Services You Do Not Need

Every unnecessary network-facing service can increase the attack surface.

Check whether the server really needs:

• FTP
• Telnet
• Mail services
• Database access from the public internet
• Remote administration interfaces
• Development servers
• Unused APIs
• Monitoring dashboards
• File-sharing services

The principle is simple:

If a service is not required, do not expose it.

5. Use a Firewall

A host-level firewall can restrict which network connections are allowed to reach the server.

A typical web server may only need a small number of publicly accessible ports.

For example:

Internet

   ↓

Firewall

   ├── HTTPS → Web server

   ├── HTTP  → Web server / redirect

   └── SSH   → Restricted administration

The exact rules depend on your infrastructure.

Do not simply open every port because an application might need it.

Start with what the server actually requires.

Firewall checklist

• Enable a host-level or provider firewall where appropriate
• Allow required web traffic
• Restrict administrative ports
• Block unnecessary inbound traffic
• Review outbound rules where appropriate
• Remove obsolete firewall rules
• Document unusual exceptions
• Test rules before closing your current administrative session

That final point is important.

A poorly planned firewall change can lock administrators out of their own server.

6. Secure SSH Access

SSH is one of the most important administrative interfaces on a Linux server.

Review:

• Disable root login where practical
• Prefer SSH keys over passwords
• Remove unused SSH keys
• Use separate administrator accounts
• Restrict SSH access by network where practical
• Keep SSH software updated
• Consider additional authentication controls for sensitive environments
• Monitor failed authentication attempts

Do not copy a hardened SSH configuration from another server without understanding what each setting does.

A secure configuration that prevents legitimate administrators from connecting is not a useful production configuration.

7. Protect Administrator Accounts

Administrator accounts have more power than ordinary users, so they require stronger protection.

Use:

• Strong unique passwords
• Multi-factor authentication where supported
• Separate administrative accounts
• No shared administrator credentials
• Regular access reviews
• Immediate removal of former users
• SSH key reviews
• Password-manager-based credential management

Avoid using one administrator account for every person who needs server access.

You want to know who accessed the server and why.

8. Follow the Principle of Least Privilege

Users and applications should have only the permissions they actually need.

For example, a web application generally should not have unrestricted access to the entire filesystem.

Separate:

• System administration
• Web application users
• Database users
• Deployment accounts
• Monitoring accounts
• Backup processes

Least privilege limits the damage that can occur if one account or application component is compromised.

9. Review File Permissions

Incorrect permissions can expose sensitive information or allow unauthorized modification.

Check:

• Website files
• Configuration files
• Environment files
• Upload directories
• Backup files
• SSH directories
• Application logs
• Database credentials
• Temporary directories

Particular attention should be paid to files containing secrets.

A configuration file containing database credentials should not be publicly downloadable simply because the web server was configured incorrectly.

10. Protect Environment and Configuration Files

Applications commonly store sensitive information in configuration files or environment variables.

Examples include:

• Database passwords
• API keys
• Application secrets
• Encryption keys
• Service credentials
• SMTP credentials

Make sure these values are not:

• Committed to public repositories
• Served as downloadable files
• Included in client-side JavaScript unnecessarily
• Stored in world-readable locations
• Printed into application logs

If a secret is accidentally exposed, changing the configuration file is not enough. The compromised credential itself may need to be rotated.

11. Secure the Database

The database should not normally be exposed directly to the public internet unless the architecture specifically requires it.

Where possible:

• Bind database services to appropriate interfaces
• Restrict database firewall access
• Use strong database credentials
• Create separate database users
• Grant only required permissions
• Remove unused database accounts
• Keep the database software updated
• Encrypt sensitive connections where appropriate
• Monitor unusual access

A web application often needs database access.

That does not mean everyone on the internet needs database access.

12. Configure HTTPS Correctly

HTTPS protects data exchanged between visitors and your website.

Check:

• Valid TLS certificate
• Automatic certificate renewal
• HTTPS enabled across the site
• HTTP redirected appropriately
• No mixed content
• Secure cookie configuration
• Modern TLS configuration
• Unnecessary legacy protocols disabled

HTTPS is not just a security feature anymore. It is a basic requirement for modern websites.

13. Use Secure Cookies

For applications that use cookies, review their security attributes.

Depending on the application’s needs, cookies may benefit from:

• Secure
• HttpOnly
• SameSite

Secure helps ensure a cookie is transmitted over HTTPS.

HttpOnly prevents client-side JavaScript from directly reading the cookie.

SameSite controls how cookies are sent in cross-site contexts.

The correct configuration depends on how the application actually works.

Do not enable a restrictive cookie policy without testing authentication and legitimate cross-site flows.

14. Add Appropriate Security Headers

HTTP response headers can provide browser-side security controls.

Depending on the website, useful headers may include:

• Content-Security-Policy
• Strict-Transport-Security
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy
• appropriate framing protections

Not every header belongs on every site, and some policies can break legitimate functionality if implemented incorrectly.

A Content Security Policy, for example, should be designed around the resources the application actually needs.

15. Protect the Server From Directory Listing

If a directory contains files that are not intended to be publicly browsable, directory listing should generally be disabled.

More importantly, sensitive files should not be stored inside publicly accessible directories in the first place.

Do not rely on hiding filenames as a security mechanism.

16. Protect Upload Functionality

File uploads are a common security concern for dynamic websites.

Review:

• Allowed file types
• Maximum upload size
• Filename handling
• Storage location
• File permissions
• Executable file handling
• MIME-type validation
• Content validation
• Authentication requirements
• Rate limiting

Do not assume that checking a filename extension is sufficient.

An upload feature should be designed so that uploaded content cannot unexpectedly become executable server-side code.

17. Keep the Web Server Hardened

Whether you use Nginx, Apache, or another web server, review its configuration.

Look for:

• Unnecessary modules
• Directory listing
• Information disclosure
• Exposed configuration files
• Weak TLS settings
• Unnecessary methods
• Incorrect proxy configuration
• Incorrect file permissions
• Default test pages
• Debug output

Remove default content and configurations that have no role in production.

18. Disable Debug Mode in Production

Development environments often expose useful diagnostic information.

Production environments should not.

Make sure debug output does not reveal:

• Database credentials
• Filesystem paths
• Stack traces
• Internal service addresses
• Environment variables
• Framework details
• SQL queries

A visitor should not receive a detailed server error simply because an application encountered an exception.

19. Protect Error Pages

Error pages should provide enough information for the user to understand that something went wrong without revealing internal implementation details.

Avoid publicly exposing:

• Full stack traces
• SQL statements
• Internal filesystem paths
• Authentication details
• Server configuration
• Secret values

Detailed errors belong in protected server or application logs.

20. Secure DNS and Domain Configuration

Server security extends beyond the machine itself.

Review:

• Domain registrar account
• DNS provider account
• Nameservers
• DNS records
• DNS management permissions
• Domain renewal
• Registrar MFA
• DNSSEC where appropriate

A perfectly hardened server does not help much if an attacker can take control of the domain or DNS account.

21. Protect the Hosting Account

Your hosting control panel or cloud account is another administrative boundary.

Use:

• Strong unique credentials
• MFA
• Limited administrative access
• Account activity monitoring
• API-key reviews
• Removal of unused users
• Restricted billing/account access where possible

Cloud credentials can sometimes provide access to far more infrastructure than an individual server account.

Treat them accordingly.

22. Back Up the Website

Security is not complete without recovery.

Maintain backups of the information required to rebuild the website.

Depending on the architecture, this may include:

• Website files
• Database
• Server configuration
• Application configuration
• Infrastructure configuration
• Certificates or certificate-management information
• Deployment configuration

The exact backup contents depend on what can be recreated automatically.

23. Keep Backups Separate From the Server

A backup stored only on the same server is not a strong recovery strategy.

If an attacker gains control of the server and deletes or encrypts its files, the local backup may disappear too.

Maintain copies in a separate environment where appropriate.

For important websites, consider:

• Off-server backups
• Separate storage credentials
• Versioned backups
• Retention policies
• Access controls
• Encryption

24. Test Your Backups

A backup that has never been restored is an assumption, not a recovery plan.

Periodically test:

1. Can the backup be accessed?
2. Can the database be restored?
3. Can website files be restored?
4. Can the application start?
5. Are required configuration values available?
6. Can DNS and infrastructure be recreated?
7. How long does recovery take?

Record the recovery process.

When something goes wrong, documentation can be as valuable as the backup itself.

25. Monitor Server Logs

Logs provide visibility into what the server is doing.

Depending on your environment, monitor:

• SSH authentication
• Web server access
• Web server errors
• Application errors
• Database activity
• Firewall events
• System events
• Authentication changes
• Privilege escalation
• Unexpected processes

You do not necessarily need to inspect every log manually.

Centralized logging and alerting can make important events easier to identify.

26. Watch for Unusual Resource Usage

A compromised server may behave differently from normal.

Monitor:

• CPU usage
• Memory consumption
• Disk usage
• Network traffic
• Process activity
• Unexpected outbound connections
• Sudden traffic changes

A sudden unexplained increase in CPU or outbound network traffic does not prove that the server has been compromised, but it is worth investigating.

Resource monitoring also helps distinguish security incidents from ordinary performance problems.

27. Use Intrusion and Malware Detection Where Appropriate

Depending on the operating system and hosting environment, security monitoring tools can detect suspicious activity.

Possible controls include:

• Malware scanning
• File-integrity monitoring
• Intrusion detection
• Login monitoring
• Web application firewalls
• Security event alerting

These tools should complement, not replace, secure configuration and software maintenance.

Installing a scanner does not compensate for an unpatched server.

28. Protect Against Brute-Force Attempts

Public authentication services can attract automated login attempts.

For administrative interfaces, consider:

• Key-based SSH authentication
• MFA
• Rate limiting
• Account lockout strategies where appropriate
• IP restrictions
• Login monitoring
• Application-level protections

Avoid relying solely on changing a default port as your primary security measure.

Reducing automated noise can be useful, but it is not a substitute for authentication controls.

29. Restrict Administrative Interfaces

Control panels, database management tools, monitoring dashboards, and internal administration interfaces should not be publicly accessible without protection.

Where practical:

• Restrict by IP
• Require VPN access
• Require authentication
• Enable MFA
• Use HTTPS
• Keep software updated
• Remove unused interfaces

The fewer administrative surfaces exposed to the internet, the smaller the attack surface.

30. Remove Default Accounts and Credentials

Default credentials are among the easiest problems to eliminate.

Review:

• Hosting panels
• Databases
• CMS accounts
• Server applications
• Monitoring systems
• Deployment tools
• Cloud services

Change default passwords or remove unused default accounts where appropriate.

31. Secure Deployment Access

Your deployment system can become a path into production.

Review:

• CI/CD credentials
• Deployment SSH keys
• Repository access
• API tokens
• Build servers
• Deployment users
• Secret storage
• Production permissions

A developer does not necessarily need unrestricted root access simply because they deploy application code.

32. Separate Development and Production

Do not use production infrastructure as a development playground.

Where possible, separate:

• Development
• Testing
• Staging
• Production

This reduces the chance that experimental code, debug settings, test credentials, or temporary services become exposed in production.

33. Keep Third-Party Components Updated

Websites often depend on more software than the server administrator realizes.

Review:

• CMS
• Plugins
• Themes
• Frameworks
• Libraries
• Runtime packages
• Server modules
• Container images
• Monitoring tools

An old plugin can be just as relevant to website security as an old server package.

34. Remove Abandoned Plugins and Applications

Unused software creates unnecessary maintenance and attack surface.

If something is no longer required:

Remove it.

Do not leave an abandoned application installed simply because it is not currently being used.

35. Protect APIs

If your website exposes APIs, review:

• Authentication
• Authorization
• Rate limits
• Input validation
• Output exposure
• CORS configuration
• Logging
• API keys
• Token expiration

An API should expose only the information and operations that clients actually require.

36. Validate User Input

Applications should not trust data received from users.

Validate and handle:

• Form fields
• Query parameters
• Headers
• Cookies
• Uploaded files
• API requests
• URL parameters

The specific protections depend on the application and technology stack.

Security validation belongs in the application itself, not only at the firewall.

37. Use Parameterized Database Queries

Applications that construct SQL queries from untrusted input can create serious security vulnerabilities.

Use the database access methods appropriate to the application’s framework, such as parameterized queries or prepared statements.

Do not rely on manually escaping strings as the only protection.

38. Protect Secrets During Development

Security problems often begin before code reaches production.

Avoid committing secrets to:

• Public Git repositories
• Source code
• Configuration templates
• JavaScript bundles
• Documentation
• Chat messages
• Issue trackers

Use appropriate secret-management practices and rotate credentials if exposure occurs.

39. Have an Incident Response Plan

Eventually, something may go wrong.

Decide in advance:

• Who has server access?
• Who can disable traffic?
• Where are backups?
• How are credentials revoked?
• How are compromised keys replaced?
• How is malware investigated?
• How is the server rebuilt?
• How are users notified if necessary?

A written incident plan reduces decision-making pressure during an actual security event.

40. Know When to Rebuild Instead of Clean

If a server has been seriously compromised, simply deleting suspicious files may not be enough.

An attacker could have:

• Added accounts
• Installed persistent access
• Modified system files
• Added scheduled tasks
• Replaced binaries
• Stolen credentials
• Changed application files

For significant compromises, rebuilding from a known-clean image and restoring verified application data can be safer than trying to prove that every malicious modification was removed.

The appropriate response depends on the incident.

Server Security vs Website Security

These terms are related but not identical.

Server security concerns the infrastructure hosting the application.

Website security includes the application, CMS, plugins, authentication, user input, APIs, and browser-facing behavior.

For example:

Problem	Primary area
Open SSH access	Server security
Outdated operating system	Server security
Weak database permissions	Both
Vulnerable WordPress plugin	Website/application security
SQL injection	Application security
Exposed database port	Server/infrastructure security
Weak administrator password	Both
Missing HTTPS	Website/server configuration
Malicious upload handling	Application security

A secure server cannot compensate for vulnerable application code.

Likewise, a secure application should not be placed on an unnecessarily exposed server.

Does Server Security Affect Website Performance?

Sometimes, but not in the way a speed optimization normally does.

Security controls can introduce small amounts of processing overhead, but properly designed security should not be viewed as the enemy of performance.

The bigger relationship is operational.

A compromised server can:

• Consume CPU
• Consume memory
• Generate unwanted network traffic
• Modify website files
• Cause downtime
• Trigger excessive database activity
• Disrupt caching
• Damage reputation

Security therefore supports the reliability of the performance environment.

But do not make the claim that adding a firewall or HTTPS will automatically improve Core Web Vitals.

Performance and security have overlapping infrastructure, but they remain different engineering objectives.

Server Security and Core Web Vitals

Security is not a Core Web Vital.

A secure server can still have poor LCP, INP, or CLS.

Likewise, a fast website can still have a serious security vulnerability.

There are, however, indirect relationships.

Security area	Possible performance relationship
HTTPS	Required for modern web delivery and secure browsing
Firewall	Usually little direct effect on frontend metrics when properly configured
Malware	Compromise can consume server resources and cause instability
Server updates	Can improve reliability and sometimes performance, depending on the update
Access controls	Primarily a security concern
Backups	Primarily a recovery concern
WAF	Can introduce processing overhead, depending on configuration
DDoS protection	Can protect availability during malicious traffic

The correct approach is to optimize both objectives rather than treating one as a replacement for the other.

A Practical Server Hardening Order

If you are starting from scratch, do not attempt every security control simultaneously.

A sensible order is:

First: Control access

Secure administrator accounts, SSH, hosting accounts, and MFA.

Second: Reduce exposure

Use a firewall and close unnecessary ports and services.

Third: Patch the system

Update the operating system, web server, runtime, database, CMS, and dependencies.

Fourth: Protect the application

Review permissions, uploads, APIs, authentication, secrets, and debug settings.

Fifth: Protect recovery

Create separate, tested backups.

Sixth: Add monitoring

Collect logs and watch for suspicious authentication, resource, and network activity.

Seventh: Test

Review the configuration periodically and test your recovery process.

This order addresses the highest-value fundamentals before adding more specialized controls.

30-Minute Server Security Audit

If you only have half an hour, start here.

Access

• MFA enabled where available
• Unused administrator accounts removed
• SSH keys reviewed
• Root login reviewed
• Password authentication reviewed

Exposure

• Firewall enabled
• Public ports reviewed
• Unnecessary services disabled
• Database not unnecessarily exposed
• Administrative interfaces restricted

Software

• Operating system updated
• Web server updated
• Runtime updated
• CMS and plugins updated
• Unsupported software removed

Website

• HTTPS working
• Debug mode disabled
• Sensitive files protected
• Uploads reviewed
• File permissions reviewed

Recovery

• Recent backup exists
• Backup is stored separately
• Restore procedure is known

Monitoring

• SSH/authentication logs available
• Web server logs available
• Resource monitoring enabled
• Security alerts configured where appropriate

This short audit will not make a server perfectly secure. It gives you a useful baseline from which to continue.

Common Server Security Mistakes

Installing a security tool and stopping there

Security is a layered process.

Leaving unused ports open

An unused service does not need public exposure.

Using one administrator account for everyone

Individual accounts provide better accountability.

Keeping old software because “nothing is broken”

Security vulnerabilities do not necessarily produce visible functional problems.

Storing backups on the same server

A compromised server can compromise its backups.

Never testing restoration

A backup can fail when you need it most.

Giving applications excessive permissions

Least privilege limits the impact of application compromise.

Exposing databases publicly

Most websites do not need their database directly accessible from the internet.

Hiding a service instead of securing it

Changing a port number can reduce automated scanning noise, but it is not a substitute for authentication and access controls.

Making security changes without a recovery path

Always know how you will regain access if a configuration change goes wrong.

Website Server Security Checklist: Final Version

Use this condensed checklist for recurring reviews.

Server

• Operating system supported
• Security updates installed
• Unused software removed
• Unnecessary services disabled
• Firewall configured
• Public ports reviewed

SSH and administration

• SSH access restricted
• Root login reviewed
• Key-based authentication preferred
• Unused keys removed
• MFA enabled where available
• Individual administrator accounts used
• Former users removed

Web server

• Web server updated
• HTTPS enabled
• TLS configuration reviewed
• Directory listing disabled where appropriate
• Default content removed
• Debug mode disabled
• Sensitive files protected

Application

• CMS updated
• Plugins and dependencies updated
• Unused plugins removed
• Upload functionality reviewed
• Input validation implemented
• Authentication protected
• API access controlled
• Secrets protected

Database

• Database updated
• Public access restricted
• Separate database users used
• Least-privilege permissions applied
• Strong credentials configured

Backups

• Automated backups configured
• Backups stored separately
• Backup retention defined
• Restoration tested
• Recovery process documented

Monitoring

• Authentication logs monitored
• Web server logs monitored
• Resource usage monitored
• Suspicious activity alerts configured
• Security reviews performed periodically

Final Verdict

A secure website server is built through layers.

Keep the operating system and applications updated. Reduce the number of exposed services. Protect administrative access. Use least-privilege permissions. Secure the database. Protect secrets. Configure HTTPS correctly. Monitor the system. Most importantly, maintain backups that are stored separately and have actually been tested.

Do not wait for a security incident before figuring out how your website will recover.

The best server security checklist is not the one with the longest list of tools.

It is the one that reduces unnecessary exposure, limits the damage of a compromise, and gives you a reliable way back to a known-good system.

Related Guides:

For the performance side of server infrastructure, continue with:

• What Is TTFB? How to Reduce Server Response Time
• How TTFB Affects LCP
• How a CDN Improves Website Speed
• HTTP/2 vs HTTP/3 for Website Performance
• Shared Hosting vs VPS vs Dedicated Server
• Redis vs Memcached: Which Caching Layer Makes Sense?
• Browser Caching and Cache-Control Explained
• Website Speed Optimization Checklist

More Resources:

• OWASP Top 10: https://owasp.org/www-project-top-ten/
• CISA Cybersecurity Best Practices: https://www.cisa.gov/topics/cybersecurity-best-practices
• Ubuntu Server Documentation: https://documentation.ubuntu.com/server/
• Let’s Encrypt: https://letsencrypt.org/
• Mozilla Server Side TLS Guidelines: https://ssl-config.mozilla.org/