New Website Security: 20 Hosting Controls

You can launch a new website in a few clicks, but getting its security foundation right on day one takes a bit more discipline. Default passwords, missing HTTPS, unnecessarily open ports, outdated PHP, and poorly protected admin panels are common security risks. Treating hosting security as a checklist rather than an afterthought helps address these risks before your first visitor arrives.

This 20-point hosting security checklist for new websites covers access, network controls, application settings and recovery. The same questions apply to shared hosting, a VPS, a dedicated server or colocation, but your permissions and responsibilities differ. Configure only the layers you administer and confirm the rest with the provider; a managed-service label does not establish the scope of every security task.

Identity, Accounts and Access

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.)

Use unique, long random passwords stored in a password manager and enable 2FA where supported on hosting, registrar, email and application accounts. Keep recovery codes securely and verify the recovery process. For email, do not assume webmail 2FA also protects IMAP/SMTP connections or application passwords; verify their protection in the service documentation and disable unused access. 2FA helps against stolen passwords but does not stop every form of account takeover; protect administrator devices and active sessions too.

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 individually assigned administrator, developer and editor accounts with only the privileges each role needs.
• Separate customer sites into appropriate hosting users/accounts. A panel package or different domain name alone does not establish a security boundary.
• Use encrypted transfer such as SFTP or supported FTPS with separate, restricted logins. Remove temporary access and revoke associated sessions, keys and tokens when work ends.

This “least privilege” design limits the damage a stolen lower‑privilege credential can cause; the owner account still needs especially strong protection.

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

If you administer the server and have SSH access, prepare secure access before launch. On shared or managed hosting, confirm which controls the provider applies and which you can configure:

• Set up SSH keys for a normal administrative user with sudo. Verify key login and privilege elevation in a separate session, keep the current session open and test console/recovery access before disabling direct root or password login. Validate the effective SSH authentication policy, including any intended MFA, before applying it.
• Changing the SSH port may reduce routine scanning noise but does not replace access controls. If you do change it, update firewall rules and clients and verify the new path before removing the old one.
• Where appropriate, configure Fail2ban or a comparable control with filters and actions for the actual log/journal source. Test detection and blocking without locking out administrators; installation alone does not protect every service.

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 gain administrative control of them, they can change DNS, upload malware, or steal backups. On day one:

• Require HTTPS with a valid certificate and monitor renewal.
• Where supported, restrict administrator access to trusted office/VPN ranges while retaining a tested recovery path.
• Apply appropriate login rate limits and test legitimate access.
• Restrict file-manager, terminal and other powerful features by role; record who may administer accounts and backups.

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:

• Restrict administrative SSH and database connections to the VPN subnet or bastion, while allowing any required application-to-database traffic.
• Admin and login URLs can optionally be restricted by IP. For WordPress, cover the actual login endpoint (normally /wp-login.php) separately from /wp-admin, and preserve public access to /wp-admin/admin-ajax.php where front‑end features require it.

A VPN or bastion adds an access layer only when enrollment, routing and authorization are configured correctly. Test allowed and blocked administrative access and required public functions, including customer logins. Restrict unnecessary ports on both IPv4 and IPv6 while allowing needed web, DNS, mail or other services; verify recovery access before tightening rules. A private address alone is not an authorization control.

DNS, TLS and Network Controls

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) where supported by your registrar and DNS provider. Enable zone signing, publish the matching DS record in the parent zone through your registrar, and verify the validation chain. This protects validating resolvers against forged DNS responses; it does not prevent changes made through a compromised DNS management account. Coordinate DS updates when changing DNS providers or signing keys, since stale or mismatched records can break resolution for validating resolvers.

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

Configure HTTPS before visitors submit credentials or other sensitive information. TLS protects data in transit and helps authenticate the hostname; it does not remove application vulnerabilities or prove that content is trustworthy. Prepare and verify the following:

• Install a valid certificate covering every served hostname and supply the required chain.
• Configure renewal and deployment/reload of the renewed certificate. Monitor the certificate actually served, rather than only the renewal job.
• After HTTPS works, configure appropriate permanent redirects from http:// to https:// on public pages, preserving paths and required query strings. Check application/API behavior, proxy loops, certificate validation paths and mixed content.

If you are planning a full migration from HTTP, we recommend following our step‑by‑step HTTPS migration guide with 301 redirects and HSTS to reduce migration-related SEO risks while improving security.

8. Use Modern TLS Protocols and Ciphers

Use supported web-server and TLS-library versions. If you administer Nginx, Apache or another TLS endpoint, validate its configuration and clients before applying changes. On shared or managed hosting, confirm the provider’s supported options:

• 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.
• Serving proper certificate chains and enabling OCSP stapling only where the CA and certificate support it. Let’s Encrypt retired its OCSP service on August 6, 2025; its current certificates do not support stapling.

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

Apply security headers at a layer you control and verify the effective responses from the application, server and CDN. Avoid conflicting policies and test login, forms, payment and embedded content. Relevant headers include:

• Strict-Transport-Security (HSTS): Requires HTTPS once the browser learns the policy. Verify HTTPS, certificate coverage and renewal first, then begin with a short lifetime. Cover subdomains or request preload only after all affected hosts are ready; deleting the header does not immediately erase a previously stored policy.
• X-Frame-Options or CSP frame-ancestors: Restricts which pages may frame your site. Choose values compatible with legitimate embedding.
• X-Content-Type-Options: nosniff: Reduces unsafe MIME interpretation when used with correct Content-Type responses.
• Referrer-Policy: Controls how much referrer information is sent on subsequent requests.

For a broader CSP, assess legitimate sources with Content-Security-Policy-Report-Only and configure a reporting endpoint if reports are needed. Report-only does not block violations; enable an enforcing policy after testing critical workflows. Our HTTP security headers guide explains the controls in more detail.

10. Configure a Web Application Firewall (WAF)

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

• Use a WAF supported by the hosting platform, such as compatible ModSecurity/OWASP CRS or an appropriate external service. Confirm who manages rules and exceptions.
• Test legitimate workflows in detection-only mode or an isolated environment, then enable blocking for validated rules. Detection-only records matches but does not block attacks.
• Protect WAF logs, limit sensitive data and set suitable retention and alerts. Keep application security patches current; a WAF does not replace them.

Ensure intended applications and hostnames actually pass through the WAF. If it runs at an external proxy, restrict direct origin access where appropriate so the protection cannot be bypassed. Test the control and its failure behavior; early placement alone does not guarantee coverage or protect against every network-level attack.

Application and Server Hardening

11. Disable Directory Listing and Default Files

If autoindex or “directory listing” is enabled, visitors may see the raw list of files when there is no index file. That leaks sensitive structure and encourages exploration. On day one:

• Disable directory listing through the supported web-server configuration, or .htaccess on Apache where overrides are permitted. Disabling listing does not prevent access to a known file URL.
• Remove unnecessary diagnostics such as info.php, sample scripts and installers from the public document root.
• Keep backup archives, secrets and internal tools outside public delivery or explicitly deny access. Confirm the public document root is the one intended by the application.

12. Set Correct File and Folder Permissions

Design permissions around the deployment user, PHP/web-server identity and files each must read or write. Do not apply a numeric mode or ownership change recursively without understanding those requirements:

• 644 files and 755 directories are common examples, not universal safe defaults. They allow other users to read files or traverse/list directories; choose tighter owner/group permissions where required, especially for credentials and keys.
• Keep application code writable by the deployment/maintenance identity, and read-only to PHP where the update design permits it. Grant the runtime write access only to required upload, cache or session paths. Do not simply make the PHP pool user own all code; coordinate legitimate updates rather than leaving broad write access.
• A directory’s execute bit means search/traversal permission; removing it can break file access and is not a specific PHP-execution control. PHP can interpret a readable script through its handler without that file having a Unix execute bit.
• Store uploads outside the public web root or on a separate restricted file-serving service where feasible. If uploads are web-accessible, prevent those requests from reaching PHP or another executable handler, block unsafe uploaded configuration overrides and validate allowed file types, size and authorization. Test the effective web-server routing, allowed media and rejected script paths; a generic permission number is not proof.

For WordPress, disabling the dashboard file editor can reduce one route to code modification. Protect wp-config.php so only necessary identities can read it, and separately prevent HTTP download. These measures complement updates, restricted privileges and safe uploads; none is a complete isolation boundary by itself.

13. Keep PHP and Application Components Supported

Choose software with active security maintenance and assign responsibility for its updates. Operating-system maintenance does not update the CMS, plugins, themes or application dependencies automatically:

• Use a currently supported PHP branch compatible with your application, monitor its maintenance status and prepare upgrades before support ends.
• Use per-site settings and separate identities/pools where supported; different pool names alone do not establish filesystem isolation.
• Restrict unneeded functions such as exec and shell_exec only after testing application needs. PHP’s disable_functions is not a sufficient security boundary and can be circumvented.
• Set suitable upload_max_filesize, post_max_size and max_execution_time, together with application and web-server limits. Validate file type, authorization and processing cost as well as upload size.

Track security updates for the OS, panel, PHP, CMS, plugins, themes and dependencies; remove unused components. Prepare a consistent backup and recovery plan, test risky changes in isolated staging, apply security fixes promptly and verify critical functions afterward. Check update failures and required service restarts rather than assuming automation completed every step.

14. Secure Database Access and Isolation

If your website relies on a database, secure its access from day one:

• Create a separate database user for each application with only the permissions needed for its database; separate runtime and migration privileges where practical.
• Avoid the global root account in application configuration.
• Use a local-only listener where the database is local and no remote client needs access.
• For required remote connections, restrict network access and authenticate clients. Use verified TLS or another appropriate encrypted transport and protect credentials; a private IP alone is not sufficient.

Separate database users limit what each site’s database credentials can access. They do not protect other applications’ data if a compromised site can also read those applications’ credentials.

15. Protect Admin and Login Endpoints

Login pages and admin URLs are targets for automated attacks. On day one, configure:

• Apply rate limits to actual login paths such as /wp-login.php, /admin and /user/login, accounting for legitimate users behind shared addresses.
• Use administrator IP restrictions where feasible, preserving required customer logins and public handlers. WordPress public features may use /wp-admin/admin-ajax.php; blanket directory blocking can break them.
• Use suitable abuse controls for registration and email-sending forms, and test accessibility and legitimate submissions.
• Changing an admin path may reduce routine scanning but does not replace authorization or 2FA. Use only platform-supported changes and test integrations and recovery access.

Combine these controls with strong per‑user passwords and 2FA to reduce account takeover risk. Rate limiting can also reduce request load, but it does not guarantee that brute‑force traffic will stay within your resource limits.

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 your domain’s mail authentication also needs attention. Configuring SPF, DKIM and DMARC helps receivers assess mail claiming to come from your domain:

• Maintain one appropriate SPF policy for the domain covering legitimate sending services; review it when senders change.
• Enable DKIM signing and publish the matching public keys using the mail provider’s instructions.
• Begin DMARC monitoring with p=none and usable aggregate reporting. Evaluate legitimate senders and alignment with the visible From domain before requesting quarantine or rejection; aligned SPF or DKIM success is needed for DMARC pass. A reject policy is not recommended for general-purpose domains whose users participate in mailing lists. If you deploy reject, ensure valid DKIM signing rather than relying only on SPF. Monitoring does not request blocking, receivers make the final delivery decision and correct authentication does not guarantee inbox placement.

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

Backups support recovery from compromise, mistakes and failure, but they must contain usable data and be reachable when production credentials or storage fail. Define acceptable data loss (RPO) and recovery time (RTO), then prepare:

• Consistent backups of databases, files, offloaded media and required configuration, at a frequency matching the data-loss target. Daily is not sufficient for every site.
• Independent offsite storage with restricted, separate deletion credentials where feasible and protected encryption/recovery keys. A copy on the same disk is not enough.
• Retention based on change rate, detection delay and recovery obligations; a fixed daily/weekly/monthly schedule is only an example.
• Isolated restore tests after the first backup and relevant changes, repeated at a frequency suitable for the site. Block real payment, email, webhook and scheduled-job side effects and measure recovery time.

The 3-2-1 approach is a useful starting point: three total copies including production, on two suitable media/storage systems, with one offsite. It does not prove immutability or recoverability. Our 3-2-1 backup and automation guide provides context; confirm the selected plan, backup tool and restore responsibilities.

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.

Protect staging with suitable authentication/access restrictions and prevent indexing, but do not treat a subdomain or noindex as isolation. Use separate databases, credentials, storage/cache namespaces and restricted identities. Sanitize sensitive data and disable real payments, emails, webhooks and scheduled jobs before testing. Keep useful version/configuration parity with production and verify deployment afterward; staging cannot guarantee identical live behavior.

19. Set Up Monitoring, Alerts and Log Retention

Configure monitoring before launch so the first live requests are covered. Useful checks include:

• External uptime and representative application checks, plus TLS expiry and backup/update failures
• CPU, memory, disk and bandwidth monitoring where the plan exposes them
• Centralized logs with protected access, reliable timestamps and retention chosen for detection, investigation and applicable obligations; 7–30 days is not a universal minimum
• Alerts for relevant errors, WAF blocks and login failures, tested with a known recipient and escalation/recovery procedure

Monitoring improves visibility only when the checks cover the failure you care about and someone acts on alerts. A responding homepage does not prove checkout or backups work; noisy error counts alone do not identify an attack.

20. Document Your Security Baseline and Responsibilities

Record a repeatable baseline before launch. Document:

• Each control, its scope, verification result and maintenance owner
• Who follows security advisories and updates the OS, panel, CMS, plugins, themes and dependencies
• Backup locations, required keys, restore steps, data-loss/recovery targets and last test results
• Administrative accounts, temporary access and third-party tokens, including how they are revoked
• Incident contacts, recovery access and responsibilities shared with the provider

Review the baseline during regular maintenance and after meaningful changes to hosting, application, DNS or email. Follow security updates and incidents as they arise rather than waiting for an annual audit; choose restore-test frequency from the site’s risk and rate of change.

Complete the Pre-Launch Review

Use these 20 items to record what is configured, who maintains it and how it was checked. Address missing access controls, insecure defaults, unprotected data and incomplete recovery before launch. Completing the checklist reduces specific risks but cannot guarantee that a website is secure.

Add more advanced controls when they solve a defined need and the team can operate them. CSP, WAF rules and redundancy each have scope and maintenance requirements; test compatibility and recovery rather than assuming more features always improve security.

Keep the checklist with your deployment runbook and repeat relevant checks after changes. If you use DCHost, verify which hosting, update, backup, monitoring and security tasks are actually included in the selected service. Record any additional work and support responsibilities explicitly.