A security checklist for after you install a script

A fresh install is the moment a site is easiest to harden, and the moment people are least likely to bother. None of these checks is advanced. Together they remove most of the easy ways in, and most of them take minutes.

The checklist

1. Change every default login and secret. If the script shipped with a default admin account or example keys, replace them now. Use a password manager and a unique password per account.
2. Turn on two-factor sign-in for admin accounts if the script offers it.
3. Delete or lock the installer. A reachable install page can let a stranger reset your site.
4. Serve everything over HTTPS and redirect plain HTTP to it. Mark session cookies as secure if there is a setting for it.
5. Keep source and configuration out of the web root. Configuration files, .env files, backups and logs should not be downloadable.
6. Tighten file permissions. Only the folders the script writes to should be writable, and uploaded files should not be executable.
7. Turn debug mode off. Debug output can print passwords and paths. Production should show a plain error page and write details to a log.
8. Keep PHP supported. Run a PHP version that still receives security fixes, and one the script's listing says it supports.
9. Limit the database user. One database user per site, with only the rights the script needs.
10. Update on a routine. Read the changelog for each release, test the update on a copy, back up, then update the live site.
11. Back up, and test the restore. Files and database, stored somewhere that is not the same server. A backup you have never restored is a hope, not a backup.
12. Make someone responsible. A site nobody looks after is the easiest target.

The rest of this page shows how to check the items that are easiest to get wrong.

Check that private files are not downloadable

Request them the way a stranger would. From any computer:

curl -I https://example.com/.env
curl -I https://example.com/config.php
curl -I https://example.com/storage/logs/laravel.log
curl -I https://example.com/backup.zip
curl -I https://example.com/install/

A 403 or 404 is what you want. A 200 means the file or folder is public and has to be moved or blocked. Adjust the paths to match your script.

To block dot-files and common backup extensions on Apache, add this to the site's .htaccess or virtual host:

<FilesMatch "^\.(?!well-known)|\.(sql|bak|zip|log|env)$">
    Require all denied
</FilesMatch>

On Nginx, put this in the server block:

location ~ /\.(?!well-known) { deny all; }
location ~* \.(sql|bak|log|env)$ { deny all; }

Test again with curl -I after you change anything. Better still, keep these files outside the document root where the script allows it.

Permissions that make sense

find /var/www/example.com -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;

Then make only the folders named in the script's documentation writable (usually uploads, cache and logs). If a folder holds uploads, make sure the web server will not run PHP from it. For Apache that can be a .htaccess in the uploads folder; for Nginx, a location block that denies .php there. Never use chmod 777.

Limit what an attacker can reach

• Give the database user only the rights the script needs, and use a different user for each site. Check what yours can do:

SHOW GRANTS FOR 'example_user'@'localhost';

• Remove plugins, themes and modules you do not use. Each one is code that needs updating.
• Use the script's own roles properly: staff who only moderate should not have full administrator rights.
• Rate-limit or add a challenge to login and registration forms if the script supports it.
• Restrict the admin area by IP address or an extra password at the web-server level if it suits how you work.

Debug mode and error output

Many frameworks have a debug switch. In a Laravel-based script, for example, the environment file should say:

APP_ENV=production
APP_DEBUG=false

Other scripts have a DEBUG constant or a setting in the admin area. After you switch it off, trigger a harmless error (open a page that does not exist) and confirm you see a plain error page instead of a stack trace.

Updates, PHP and the operating system

• Check your PHP version against the PHP supported versions page, and move to a supported release your script's listing names.
• On a VPS, install operating-system security updates regularly. Many distributions can apply security updates automatically; decide whether you want that and monitor it.
• Subscribe to the script's changelog or release notes, and read why the changelog matters before you click update.

Backups you can actually restore

A minimal routine for a small site:

mysqldump --single-transaction -u example_user -p example_site | gzip > backup-$(date +%F).sql.gz
tar -czf files-$(date +%F).tar.gz /var/www/example.com

Copy both files to storage that is not on the same server, and keep several generations. Then, once, restore them into a staging copy to prove it works (see testing on staging).

Watch for trouble

Check your logs now and then for repeated failed logins and unexpected requests. Turn on email alerts for new admin accounts if the script offers them. If something looks wrong, change passwords, restore from a clean backup, and update before you bring the site back.

Make someone responsible

Many security problems on small sites are not clever attacks. They are sites nobody was assigned to look after. If you run a site for a client, write down who handles updates and backups.

If you found a vulnerability in a script you bought, contact the author first through the listing, and use the contact page if you cannot reach them. Do not publish details before the author has had a chance to fix it.

Frequently asked questions

Is HTTPS enough to make my site secure?

No. HTTPS protects data in transit. It does nothing about weak passwords, leftover installers, outdated code or exposed files.

How often should I update?

Read each release's changelog. Apply security fixes promptly after testing, and batch smaller feature updates for a quiet moment.

Do I need a firewall or a security plugin?

A firewall on a VPS is a sensible baseline, and some hosts provide one. Extra tools can help, but they do not replace the checks above.

My host says it handles security. Can I skip this?

Not entirely. A host usually secures the server; the script's settings, passwords, permissions and updates are still yours.