You can do alot of WordPress security stuff right. Strong password. Updates done. Two-factor on. And still get burned by something boring like file permissions.
That’s the annoying part. Nobody gets excited about chmod values. Nobody brags about setting folders to 755. But bad permissions can quietly turn a normal site into an easy target, especially on shared hosting or old server setups where too many things can write where they shouldn’t.
If you’ve ever seen someone say “just set it to 775” or even worse, “make it 777 so the plugin works,” stop there. Seriously.
Sometimes that quick fix is the start of the mess.
What file permissions actually do
Very simply, file permissions decide who can read, write, or execute files and folders on your server.
In WordPress, that matters because your site is just a pile of PHP files, uploads, themes, plugins, and config files. If the wrong user or group can write to those files, malware doesn’t need to “break in” the dramatic movie way. It can just edit things. Add things. Hide things in places you won’t notice for months.
Here’s the basic idea:
- 755 for folders – owner can write, everyone else can read and access
- 644 for files – owner can write, everyone else can read
- 600 or 640 for sensitive files like wp-config.php on some setups
Those aren’t magic numbers. They’re just the usual safe defaults for most WordPress sites.
Where people get into trouble is changing them blindly because some theme demo, plugin support thread, or random YouTube guy told them to.
Why 775 can be fine… or a quiet problem
This is where it gets a bit sneaky.
775 means the owner and the group can write to a directory. On the right server setup, that’s normal. Totally fine. If your hosting account is configured properly and your PHP process runs under your own user, 775 on some directories may not be dangerous at all.
But on the wrong setup? Different story.
If group ownership is messy, or multiple sites share the same group access, 775 can give write access more broadly than you think. That’s how a compromised neighboring site on the same account, or a badly isolated staging copy, sometimes ends up touching files it never should have been able to touch.
And no, you usually won’t get a big warning saying “hello, your permissions are now a backdoor.” It just sits there. Quietly open.
I’ve seen this with old agency hosting setups where 12 client sites lived under one account and half the folders were group-writable because it made updates easier. Easier, yes. Safe, nope.
Where this usually starts
Not with an attacker. With a shortcut.
A plugin can’t create a cache folder. A gallery plugin can’t upload thumbnails. A developer is in a hurry. Your host gives vague advice. So somebody changes a few directories to 775 or 777 and says it’s fixed.
Technically, maybe it is fixed. For today.
But the real issue – wrong ownership, bad server config, PHP running under the wrong user, sloppy deployment – stays there untouched. You just covered it with duct tape.
This is also why cheap builds often age badly. The site works at launch, nobody thinks about server hygiene, and then three years later you’re trying to figure out why spam PHP files keep appearing in uploads. If that sounds familiar, this article on building for maintenance, not just launch is worth a read.
The folders attackers love
If permissions are too open, some parts of WordPress become much more attractive.
/wp-content/uploads/ is the classic one. It needs to be writable for image uploads, sure. But it should not become a free-for-all dumping ground for executable junk. If an attacker manages to upload a PHP file there and your server executes it, that’s game over territory.
/wp-content/plugins/ and /wp-content/themes/ are also ugly if writable by the wrong users. Malware loves hiding in a fake plugin folder or adding a backdoor to functions.php. Tiny changes. Hard to spot by eye.
Then there’s wp-config.php. This file contains database credentials and security settings. If that file is writable when it doesn’t need to be, you’re giving away far too much.
Honestly, most small business owners don’t need to memorize every folder. You just need to know this: writable should be limited, deliberate, and boring. Not wide open because something failed once.
How to check your permissions without becoming a server admin
You do not need to turn into a Linux person overnight. Good news.
You can usually check permissions in one of three places:
- Your hosting file manager
- An SFTP client like FileZilla
- Your hosting support panel or SSH, if you actually use it
Look at the main WordPress folders and files. If you see lots of 777, that’s bad. If key directories are 775, don’t panic yet – check ownership and ask why they need group write access. If nobody can answer that clearly, that’s a red flag by itself.
A healthy small business site usually has pretty dull permissions. Dull is good.
If you want an easier way to tighten common weak spots inside WordPress itself, stuff like disabling risky extras and applying safer defaults, a one-click hardening tool can help without you poking around files all afternoon.
What to do if something only works with 775 or 777
This is the bit people hate hearing.
Don’t accept that as the final answer.
If a plugin, theme, or backup tool “needs” 777, I’d immediately distrust it. And if support tells you to make half of wp-content writable to everyone, I’d be looking for another plugin. Life’s too short.
Try this instead:
- Check file ownership – often that’s the real problem
- Ask your host how PHP is running on the account
- Use 755 for directories and test again
- Update or replace the plugin if it’s old and weird
- Have someone review the server setup instead of stacking permission hacks on top of each other
There’s a bigger pattern here. Quick “just make it writable” fixes are cousins of the whole install it and forget it trap. You get a green light, assume it’s handled, and the real risk stays put.
Signs permissions may already be part of a compromise
Sometimes file permissions aren’t the original cause. They’re what let the infection spread.
Watch for things like:
– PHP files showing up inside uploads
– Plugin folders you don’t recognize
– Reappearing malware after a cleanup
– Strange admin users
– Your host changing file permissions during an emergency suspension
– Security plugins warning about modified core files
If that stuff is already happening, don’t just reset a few chmod values and hope for the best. That’s like locking a window after somebody’s already sleeping on your sofa.
At that point you need cleanup, file review, and a check for how the attacker got write access in the first place. If you’re already in that situation, get proper help with site cleaning and restoration before the same junk comes back next week.
The safer default for most small business sites
Here’s my opinion: most WordPress sites should lean conservative.
Use standard permissions. Keep the number of people with hosting access small. Remove old plugins. Don’t leave abandoned staging sites on the same account. And don’t keep using a host setup from 2018 just because “it still works.” That sentence has started many fun disasters.
For ongoing care, updates, file checks, and someone actually noticing when the site starts behaving oddly, a proper WordPress maintenance service usually costs less than one messy recovery job. Which, honestly, is how small businesses should think about this stuff. Prevent the ugly expensive day.
Because file permissions aren’t glamorous. They’re housekeeping. But neglected housekeeping is how weird little server problems turn into hacked sites, blacklisted pages, and lost leads.
So if you spot 775 everywhere and nobody remembers why, don’t shrug it off.
That’s exactly the kind of quiet detail that bites later.