Site Hardening · Part 6
The numbers everyone quotes
Every hardening guide has the same line: 644 for files, 755 for folders, 640 or tighter for your configuration file. Part 10 of the investigation series gives the same numbers, and they are right.
What the guides rarely explain is what those numbers actually stop, what they don’t, and how to tell whether they’re working. That matters, because permissions are one of the few hardening steps that can fail in both directions — too loose and they protect nothing, too tight and they quietly break the owner’s own work.
What a permission actually is
Every file has an owner and three sets of rights: what the owner can do, what the owner’s group can do, and what everyone else on the server can do. Each can be allowed to read, to write, or to run.
644 means the owner can read and write; everyone else can only read. 755 on a folder means the owner can change what’s in it; everyone else can look inside. The last digit — everyone else — is the one that matters most on shared hosting, because “everyone else” can include other accounts on the same machine.
A file that everyone can write to is a file anyone on the server can change. No legitimate WordPress setup needs that.
From the case file. When the intruders rebuilt one WordPress install after the compromise was discovered, its configuration file was left writable by everyone. It was one of only two files in that install touched after it was set up. A world-writable configuration file isn’t a setting anyone chooses by accident, and the most likely reading is that someone wanted to be able to change it again later.
The limit nobody mentions
Here is the part that makes permissions easy to over-trust.
On most shared hosting, your website’s PHP runs as you — the same account that owns the files. That is good for isolation between customers. It also means that code running on your site has the owner’s rights. A malicious script that is already executing can change a file’s permissions back, then write to it.
So permissions don’t stop an intruder who is already running code as you. What they do stop is real, and worth having:
- Other accounts on a shared machine writing into yours.
- Plugins and themes quietly rewriting files they shouldn’t touch.
- Upload forms and file managers that write only where the rules allow.
- Your own mistakes — a file overwritten by the wrong upload.
Treat permissions as a floor, not a lock. The lock is making sure nothing hostile runs in the first place — which is why turning PHP off in folders that should only ever hold images and uploads matters more than any single number.
Read-only where nothing should change
Some files on a finished site should essentially never change: the configuration file, the server configuration files, the main index files. Setting those to read-only — 444, or 440 for the configuration file — means an accidental write fails instead of succeeding.
That buys two things. Anything that tries to rewrite them without changing permissions first simply fails. And a change to a read-only file is never routine — if one happens, something deliberately changed the permissions first, which is exactly the kind of event worth noticing.
WordPress has a matching switch of its own. DISALLOW_FILE_EDIT in the configuration file removes the built-in code editors; DISALLOW_FILE_MODS goes further and stops plugins and themes being installed or updated from the dashboard at all. In this case, two file-manager plugins were added to one site a minute apart and nobody noticed. Locking file changes out of the dashboard closes one of the routes that kind of change can take.
The trap on the other side
Harden deeply enough and you will eventually lock yourself out — without being told.
From the case file. After the compromise, the owner tightened permissions across his sites far enough that some edits now fail silently. The editor reports that the file saved; nothing on the server changes. It has caught him more than once, because months later it’s easy to forget exactly how deep a given site was hardened. The fix isn’t looser permissions. It’s a habit: after any edit to a protected file, check the live site, not the save message.
The same habit catches the opposite failure. A permission you set last month may not be the permission the file has today — hosts reset them during migrations, restores and support work. Check them occasionally, and check them after anyone else has touched the account.
A practical order
- Set the ordinary baseline: 644 files, 755 folders.
- Tighten the configuration file to 640, or 440 once the site is finished.
- Make the files that should never change read-only.
- Turn off PHP execution in upload and image folders.
- Lock file changes out of the dashboard.
- Write down what you set, where, and why — somewhere off the server.
- After every future edit, confirm it on the live site.
Step six is the one people skip, and it’s the one that saves you six months later when a save quietly does nothing.
Permissions can’t tell you whether something hostile is already running. A recovery review checks what is executing on the server, not just what should be able to.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: Files That Should Never Live on a Web Server
Next: Locking Down .htaccess Without Breaking Your Site
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.