# Poorly set file permissions on shared hosting

> A folder or file left too open on a server shared by dozens of other sites can be enough to spread an infection from one site to another, without any password ever being compromised.

- Source canonique : [https://allaux.fr/en/securite/droits-de-fichiers-hebergement-mutualise](https://allaux.fr/en/securite/droits-de-fichiers-hebergement-mutualise)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> In your FTP client, display the permissions column and tighten anything too open: 755 for directories, 644 for files, 440 or 400 for wp-config.php, which holds the database credentials. No directory should stay at 777, including wp-content/uploads. Then ask your host whether accounts on the shared server are isolated from each other.

## What file permissions actually are

Every file and folder on a server has permissions defining who can read, modify or execute it: the file’s owner, a group of users, and everyone else on the server. These permissions are expressed as three digits, such as 644 or 755, each combining read, write and execute rights for those three categories.

On a server dedicated to a single site, an overly open permission is still a risk, but a limited one. On shared hosting, several different customer accounts often share the same physical server. If file permissions are too permissive, a script running under another account on that same server can, depending on the host’s configuration, read or write into a neighbouring site’s files. This is known as "cross-site" or "cross-account" compromise: a neglected site can become the way in to a perfectly up-to-date site hosted right next to it.

## What this page does not explain

> The precise mechanism enabling cross-account reads between accounts on shared hosting is deliberately not detailed here. This page stays at the level of the principle and its protections: strict permissions, and the isolation your host provides.

## The recommended values for WordPress

WordPress’s official documentation recommends folders at 755 (or 750 if the server allows it), files at 644 (or 640), and a special case for wp-config.php: 440 or 400, to stop other users on the server from even reading it, since it holds the database login credentials. No folder should ever be set to 777, including upload folders, which are often left too open to avoid write errors when a file is submitted.

## example of a correct permission

```
chmod 440 wp-config.php   # 644 leaves the file readable by other accounts on the server
```

## The recommended values for PrestaShop

PrestaShop’s official documentation and community guides recommend 644 for files and 755 for folders. Some hosts temporarily require 777 on certain folders during the installation step, so the installer can write without errors. Once installation is finished, permissions should be tightened back up: 775 for folders and 664 for files at minimum, ideally 755 for folders and 644 for files as soon as the host’s configuration allows it.

## How to check your own permissions

1. **Connect via FTP or SFTP** — Most FTP clients show a permissions column next to each file and folder, usually as three digits or a string of letters.
2. **Check your host’s file manager** — The hosting control panel usually offers a file manager with the same information, without needing an external FTP client.
3. **Check configuration files first** — wp-config.php on WordPress, or PrestaShop’s database configuration files, should be checked first: they hold the most sensitive information.
4. **Ask your host to confirm** — A reputable host can confirm whether your account benefits from isolation between customers on the same server, which reduces the risk even where a permission is misconfigured elsewhere.

## Related reading

- **Admin passwords and shared access** — Another flaw rooted in human oversight rather than code. ([/securite/mots-de-passe-administration-acces-partages](/securite/mots-de-passe-administration-acces-partages))
- **PHP versions past end of life** — Another server-level setting with a direct impact on your store’s security. ([/securite/versions-de-php-en-fin-de-vie](/securite/versions-de-php-en-fin-de-vie))
- **Security and cleanup of a hacked site** — The full service if your store has already been infected. ([/services/securite](/services/securite))

## FAQ

### How do I know if my site was infected from another site on the same shared server?

I check the creation date of the injected files, the available access logs and the permissions in place, which often makes it possible to distinguish a direct intrusion from spreading via the server.

### Does moving to a dedicated server permanently fix this risk?

It removes the risk of spreading between neighbouring accounts, but doesn’t replace correctly set permissions: a file at 777 is still a risk, even alone on its own server.

### Why does my host ask for 777 during installation?

Some CMS installers need to write configuration files before final permissions are applied. This is a temporary step, not a setting to keep after installation.

### Is an overly open upload folder really a significant risk?

Yes: a folder meant for images or documents, if set to 777, can allow execution of a file placed inside it depending on the server’s configuration, when it should only ever hold media.

### Should I check these permissions after every CMS update?

An update can recreate certain files with default permissions different from yours. A quick check after a major update prevents a sensitive file from ending up too open again.