Security Checklist for New Websites: 20 Hosting Settings to Configure on Day One

You can launch a new website in a few clicks, but getting its security foundation right on day one takes a bit more discipline. Most compromises we see at dchost.com do not start with exotic zero‑days; they start with default passwords, missing HTTPS, open ports, outdated PHP, or an admin panel exposed to the entire internet. The good news: if you treat hosting security as a checklist and not an afterthought, you can remove a huge portion of your real‑world risk before your first visitor arrives.

In this article we will walk through a 20‑point security checklist for new websites, focused entirely on settings you can (and should) configure on your hosting platform from day one. Whether your site is on shared hosting, a managed VPS, a dedicated server or colocation with us, you can follow the same structure: lock down access, secure the network edge, harden the application environment, and make sure you can recover if something goes wrong.

1. Identity, Accounts and Access: Don’t Start with a Skeleton Key

1. Change All Default Passwords and Enable 2FA

Your first job after provisioning hosting is to remove default credentials. That means:

• Hosting control panel login (cPanel, Plesk, DirectAdmin, custom panels)
• FTP/SFTP accounts
• Database admin accounts (phpMyAdmin, adminer, etc.)
• Application admin logins (WordPress, PrestaShop, Laravel admin, etc.)

Create unique, random passwords (use a password manager) and switch on two‑factor authentication (2FA) wherever the panel allows it. Many compromises happen because a reused password from another breach is tried against your newly created hosting account. 2FA breaks that chain immediately.

2. Create Separate Accounts and Follow Least Privilege

On day one it is tempting to do everything from one super‑privileged login. That is convenient but dangerous. Instead:

• Use one owner account with full rights, and separate developer or content editor accounts with limited permissions.
• If you are an agency, give each customer a separate hosting account rather than stacking many sites under one user.
• For FTP/SFTP, avoid sharing the main account; create per‑user logins restricted to relevant directories.

This “least privilege” design ensures a stolen credential cannot automatically control everything.

3. Harden SSH Access (For VPS, Dedicated and Colocation)

If your website runs on a VPS, dedicated server or colocation machine, SSH is your lifeline — and a common attack target. Before you put the site into production:

• Disable password logins; use SSH keys only.
• Change the SSH port from 22 to a non‑standard port (it does not replace security, but it cuts noise from bots).
• Disable root login via SSH and use a normal user with sudo.
• Consider using Fail2ban or the equivalent to ban IPs after repeated failures.

We go much deeper on this topic in our article the calm, no‑drama guide to securing a VPS server, which you can reuse as a server‑side companion to this checklist.

4. Lock Down Your Hosting Control Panel

Control panels (cPanel, Plesk, DirectAdmin, custom dashboards) are powerful; if attackers reach them, they can change DNS, upload malware, or steal backups. On day one:

• Restrict panel access to HTTPS only.
• If your hosting includes IP allowlists, restrict administrative access to office/VPN IP ranges.
• Ensure failed login attempts are rate‑limited or temporarily blocked.
• Disable or limit single‑click file managers or terminal features for non‑admin accounts.

In cPanel environments, follow our cPanel security hardening checklist for additional, panel‑specific controls like brute‑force protection and malware scanning.

5. Use a VPN or Bastion for Sensitive Access

For high‑value sites (e‑commerce, SaaS dashboards, internal tools) consider limiting SSH, database administration tools, and even panel access to a VPN or bastion host:

• Only the VPN subnet can reach SSH or database ports.
• Admin URLs (e.g., /wp-admin) can optionally be restricted by IP.

This adds one more layer between the public internet and your critical entry points without changing your application code.

2. DNS, TLS and Network Edge: Secure the Front Door

6. Configure DNS Correctly and Enable DNSSEC

Your DNS zone is as critical as your web server; if it is compromised, traffic can be silently redirected to malicious servers. When you first configure your domain:

• Ensure nameserver records (NS) correctly point to your intended DNS provider or to private nameservers you operate.
• Lock down access to the DNS management interface with strong passwords and 2FA.
• Enable DNSSEC (Domain Name System Security Extensions) to protect against DNS spoofing where supported by your registrar and DNS provider.

If you want a deeper dive on why this matters, read our explainer on what DNSSEC is and how it makes your website more secure.

7. Get an SSL/TLS Certificate and Enforce HTTPS

Serving your website only over HTTP on launch day is no longer acceptable. You need an SSL/TLS certificate from day one, even for simple brochure sites. On the hosting side, you should:

• Install a certificate (Let’s Encrypt or commercial) on your main domain and all relevant subdomains.
• Configure automatic renewal to avoid expired cert outages.
• Set up 301 redirects from http:// to https:// for every hostname.

If you are planning a full migration from HTTP, we recommend following our step‑by‑step HTTPS migration guide with 301 redirects and HSTS so you do not hurt your SEO while improving security.

8. Use Modern TLS Protocols and Ciphers

Once HTTPS is enabled, check the TLS configuration itself. On a VPS or dedicated server, that usually means editing your web server config (Nginx, Apache, LiteSpeed). In control panels, you often have presets such as “modern” or “high security”. Aim for:

• Enabling TLS 1.2 and 1.3; disabling TLS 1.0/1.1 and all SSLv2/3.
• Using strong cipher suites that support forward secrecy.
• Enabling OCSP stapling and proper certificate chains.

We maintain a separate deep‑dive on which SSL/TLS security updates you must keep up to date if you want a configuration checklist for Nginx and Apache.

9. Set Core HTTP Security Headers

HTTP security headers are lightweight but powerful protections you can enable on day one. At a minimum, configure these headers at the web server or hosting panel level:

• Strict-Transport-Security (HSTS) to force future HTTPS usage.
• X-Frame-Options or Content-Security-Policy frame-ancestors to prevent clickjacking.
• X-Content-Type-Options: nosniff to block MIME sniffing.
• Referrer-Policy to limit referrer leakage.

Later you can add stronger controls like CSP. For a practical walkthrough, see our friendly guide to HTTP security headers, which includes real example configurations.

10. Configure a Web Application Firewall (WAF)

A web application firewall inspects HTTP requests and blocks common attack patterns such as SQL injection, cross‑site scripting and malicious file uploads. On day one:

• Enable ModSecurity (or your panel’s built‑in WAF) with a ruleset like OWASP CRS.
• Start in blocking mode for critical rules; tune if you see false positives.
• Log WAF events to a dedicated file for later analysis.

Position your WAF as early as possible in the request path (ideally at the edge or front web server) so it can protect all your applications and subdomains behind the same shield.

3. Application and Server Hardening: Make Exploits Work Harder

11. Disable Directory Listing and Default Files

On fresh hosting accounts, web roots often allow autoindex or “directory listing”, showing visitors the raw list of files if there is no index file. That leaks sensitive structure and encourages exploration. On day one:

• Disable directory listing in your web server or via .htaccess if using Apache.
• Remove or rename default files (e.g., info.php, sample scripts, “It works!” pages).
• Ensure the document root contains only your application, not random tools or installers.

12. Set Correct File and Folder Permissions

Incorrect permissions are a classic reason malware can spread across sites on the same account. As you deploy your site:

• Use 644 for files and 755 for directories in most PHP setups.
• Ensure files are owned by the correct user (matching your PHP handler, e.g., PHP‑FPM pool user).
• Mark upload directories as non‑executable if you can, to prevent uploaded scripts from running.

For CMS platforms like WordPress, combine correct permissions with application‑level hardening (disabling file editors, protecting wp-config.php, etc.). We cover this angle in depth in our WordPress hardening and security articles.

13. Choose a Supported PHP Version and Disable Dangerous Functions

Your choice of PHP version and configuration can dramatically change your attack surface. On day one:

• Pick a currently supported PHP release (PHP 8.x at the time of writing).
• Make sure each website runs on its own PHP version/pool where possible.
• Disable or restrict dangerous functions (e.g., exec, shell_exec) unless your application really needs them.
• Set sensible limits for upload_max_filesize, post_max_size and max_execution_time to reduce abuse.

If you manage multiple sites per server, per‑site PHP configuration is critical, as we discussed in our piece on managing multiple PHP versions on common control panels.

14. Secure Database Access and Isolation

Every new website with dynamic content relies on a database. To keep it safe from day one:

• Create a separate database user per site with only the privileges it needs (usually just on its own database).
• Avoid using the global root account in application configuration.
• Bind the database server to localhost unless you explicitly need remote access.
• If remote access is required, restrict by IP and enforce TLS where possible.

This isolation prevents an exploited site from trivially reading or corrupting other applications’ data.

15. Protect Admin and Login Endpoints

Almost every automated attack we see targets login pages and admin URLs. On day one, configure:

• Rate limiting for login paths (e.g., /wp-login.php, /admin, /user/login).
• Optional IP allowlists for sensitive admin panels when feasible.
• CAPTCHA or other abuse controls for forms that create accounts or send emails.
• Unique admin paths where your platform supports safe renaming (be careful: some plugins break with URL changes).

Combine this with strong per‑user passwords and 2FA and you will stop the majority of brute‑force attempts before they become a resource problem.

4. Email, Backups and Observability: Prepare for Failure in Advance

16. Set SPF, DKIM and DMARC for Your Domain

Email might seem separate from web hosting, but attackers frequently abuse new domains to send phishing messages. Configuring SPF, DKIM and DMARC in DNS from day one helps protect your brand and inboxes:

• Publish an SPF TXT record listing legitimate mail servers.
• Enable DKIM signing in your email platform and add the public key records.
• Start with a DMARC policy in monitoring mode (p=none) with reporting addresses so you can see abuse attempts.

Our separate guides on SPF, DKIM, DMARC and mail deliverability go into the specifics of syntax and troubleshooting if you need a deeper configuration runbook.

17. Configure Automated, Off‑Server Backups

No security checklist is complete without backups. A compromise, misconfiguration or hardware failure is survivable if you can restore clean data quickly. On day one, configure:

• Automated daily backups of files and databases.
• Storage on a separate system (another server or object storage), not only on the same disk as your site.
• Retention policies (e.g., 7 daily, 4 weekly, 6 monthly backups).
• Periodic restore tests so you know backups are actually usable.

We strongly recommend following the 3‑2‑1 backup strategy from the start: at least three copies, on two different media, with one offsite. Our article on the 3‑2‑1 backup strategy and automating backups on cPanel, Plesk and VPS shows exactly how to configure this.

18. Separate Staging and Production Environments

It is risky to develop and test directly on your live site. On day one, plan for at least two environments:

• Production: Your real users, with strict security and change control.
• Staging: A copy of production for testing updates, plugin changes, and configuration tweaks.

Host staging under a separate subdomain or even account, protect it with HTTP auth or IP restrictions, and avoid indexing by search engines. This isolation means a broken plugin or misconfigured WAF rule is discovered before it affects real customers.

19. Set Up Monitoring, Alerts and Log Retention

Security is not only about prevention; you also need visibility. As soon as your site goes live, configure:

• Uptime monitoring to alert you if the site stops responding.
• Resource monitoring (CPU, RAM, disk, bandwidth) for servers and hosting plans.
• Centralized logging where feasible, with at least 7–30 days of logs.
• Alert thresholds for suspicious patterns (e.g., spikes in 4xx/5xx errors, WAF blocks, or login failures).

Even basic monitoring and log retention will help you detect attacks earlier and understand what happened if something does go wrong.

20. Document Your Security Baseline and Responsibilities

Finally, good security on day one should be repeatable. Take an extra hour to document:

• Which settings you applied on the hosting panel and server.
• Where backups are stored and how to restore them.
• Which admin accounts exist and who owns them.
• Which third‑party services are allowed to access your hosting (CI/CD, monitoring, email gateways, etc.).

This baseline becomes your reference when you add new sites or onboarding new team members, and it makes annual security reviews much easier.

5. Putting It All Together on Day One

Security can feel overwhelming when you list everything that could go wrong, but a structured hosting checklist turns it into a straightforward setup process. If you walk through these 20 items on the day you launch a new website, you will have covered the biggest real‑world risks: exposed admin panels, weak authentication, missing HTTPS, unsafe defaults, unprotected databases, absent backups, and zero visibility.

From the dchost.com side, we see a clear pattern: websites that start life with strong hosting‑level security settings and regular reviews remain far more resilient over the years, even as plugins, themes and business requirements evolve. As you grow, you can build on this foundation with more advanced techniques like CSP nonces, multi‑region redundancy, and dedicated WAF tuning, which we discuss across many of our security and infrastructure articles.

If you are about to launch a new project, treat this checklist as part of your go‑live runbook alongside design, SEO and performance checks. Work through it once, keep a copy in your documentation, and revisit it whenever you spin up a new hosting plan, VPS, dedicated server or colocation setup. A calm, well‑configured day one dramatically reduces the chances of a panicked day thirty.