Cloud hosting configuration errors are the number one cause of outages, security breaches, and poor performance — even more so than hardware failures. The good news: most are preventable with a clear checklist from day one.
Below are the most frequent and costly mistakes, with an explanation of why they happen and what to do to avoid them.
1. Leaving File Permissions Too Open
Assigning chmod 777 to folders or files is the quick fix that turns your server into an open door. With world-writable permissions, any process — including a compromised script — can overwrite system or site files.
The Correct Configuration
- Directories:
755(owner reads/writes/executes; group and others only read/execute). - Files:
644(owner reads/writes; group and others only read). - Configuration files with credentials (e.g.,
config.php):640or600, never readable by "others." - CMS upload directories:
755maximum; never executable by the web server.
Audit your permissions regularly with find /site/path -perm -o+w -type f to detect world-writable files.
2. Not Configuring Automatic Backups
Trusting that "the provider does backups" without verifying it is one of the most expensive mistakes. Many plans include snapshots, but with minimal retention (24–48 h) or no database coverage.
- Define a 3-2-1 policy: 3 copies, on 2 different media, 1 offsite.
- Automate a daily compressed
mysqldumpand transfer it to external storage (S3, Backblaze B2, etc.). - Test restoration at least once a month. An untested backup is not a backup.
- Keep at least 7 daily and 4 weekly versions to be able to roll back after a silent ransomware attack.
If you manage multiple cloud sites and want a professional backup strategy, the team at elenlace.com can design and implement the system for you.
3. Ignoring PHP Configuration for Production
PHP ships with default values intended for development, not production. Leaving them as-is exposes internal errors to visitors and opens attack vectors.
| Parameter | Development value | Recommended production value |
|---|---|---|
display_errors |
On | Off |
log_errors |
Off | On |
expose_php |
On | Off |
upload_max_filesize |
2M | Per actual need (e.g., 10M) |
memory_limit |
128M | 256M–512M (adjust per app) |
max_execution_time |
30 | 30–60 (no more without justification) |
Also, enable OPcache in production. It's the most overlooked free performance boost in PHP: it can cut response time by up to 50% without any code changes.
4. Not Separating Development and Production Environments
Working directly on the production server — editing live files, running tests with real data, installing untested plugins — is a practice that will eventually end in disaster.
- Maintain at least two environments: staging (a copy of production for testing) and production.
- Use environment variables or
.envfiles to separate credentials between environments. Never use the same database username and password in both. - Apply a deployment process (git pull, rsync, or CI/CD) instead of editing files directly in production via FTP.
- Disable debug mode, debug toolbars, and directory listings in production.
5. Misconfiguring HTTP Security Headers
Your web server delivers security headers that the browser uses to protect users. Omitting them is a silent configuration error with real consequences.
Minimum Security Headers You Should Enable
- Strict-Transport-Security (HSTS): forces HTTPS on future visits even if the user types
http://. - X-Content-Type-Options: nosniff — prevents the browser from trying to "sniff" the MIME type of a file.
- X-Frame-Options: SAMEORIGIN — protects against clickjacking.
- Content-Security-Policy (CSP): defines which origins can load scripts, styles, and images.
- Referrer-Policy: controls what referrer information is shared when navigating to other domains.
You can verify your site's headers at securityheaders.com in under a minute. An A or B rating is the minimum target for any production site.
Find more cloud best-practice articles in our cloud hosting blog.
Key Takeaways
chmod 777permissions are an active security breach; use755/644at most.- Verify and test your backups — don't assume the provider covers everything.
- Tune
php.inifor production: disabledisplay_errors, enable OPcache. - Never edit files directly in production; use staging and a controlled deployment process.
- Implement the five essential HTTP security headers from day one.
Avoiding these mistakes requires time and technical knowledge that isn't always available in-house. Contact us at elenlace.com and we'll audit your cloud hosting configuration for free so you can operate with complete peace of mind.
FAQ
What is the most dangerous cloud hosting configuration error?
Overly permissive file permissions (chmod 777) are the most dangerous because they allow any server process to modify or delete files. Combined with a vulnerable plugin or an unprotected form, they give an attacker full access to the server.
How often should I audit my cloud hosting configuration?
At minimum every three months, and always whenever you install new software, change your plan, or onboard a new developer. Minor configuration changes accumulate and create vulnerabilities that weren't there at launch.
Does OPcache carry any risk in production?
Minimal. The only practical issue is that OPcache stores compiled bytecode in memory: if you deploy code changes without restarting PHP-FPM, the site may keep serving the previous version. The fix: set opcache.validate_timestamps=1 in staging and 0 in production, and force a PHP-FPM reload with each deployment.
Is a free SSL certificate (Let's Encrypt) enough for a cloud site?
For the vast majority of sites, yes. Let's Encrypt provides TLS 1.2/1.3 with the same cryptographic strength as paid certificates. The real difference with paid certificates lies in liability insurance (Extended Validation) and commercial support — not in the level of encryption.
Further reading
Other providers and guides worth comparing:
