How to set file permissions on an e-commerce server
Permissions that are too restrictive break a store's normal operation; permissions that are too permissive open an exploitable security hole. The right setting is almost always somewhere in between, never a blanket 777 applied everywhere.
What the numbers actually mean
A file or folder permission breaks down into three rights (read, write, execute) for three categories (owner, group, others), each expressed as a digit from 0 to 7. A folder set to 755 means the owner can read, write and execute, while the group and others can only read and execute, not write. A folder set to 777, on the other hand, grants write access to absolutely everyone, including a malicious script that manages to run on the server.
On an online store, only a handful of folders genuinely need write access for the web server: cache, logs, file uploads and media folders. The rest of the code, particularly configuration files holding the database connection credentials, should never be directly writable by the web server once the installation is finished.
Identifying the right settings
-
List the folders the application actually writes to
On PrestaShop, this covers var/cache, var/logs, img, upload and download in particular. The config folder only needs to be writable during installation: once that is finished, it goes back to read-only for the web server. On WooCommerce, mainly wp-content/uploads and the caches of active plugins.
-
Restrict everything else to read-only
The source code of the CMS, theme and modules or plugins doesn't need to be writable by the web server once deployed: a read-only permission limits the consequences of a potential intrusion.
-
Check the file owner
On shared hosting, files generally belong to the hosting account itself, which simplifies permission management compared with a dedicated server where several system users may be involved.
-
Test after every change
An overly restrictive setting generally shows up as an explicit error (unable to write to a given folder), visible in the logs once debug mode is enabled.
Common mistakes
- Applying 777 across the whole site to quickly fix a permission error, without ever reverting to a stricter setting afterwards.
- Leaving configuration files that hold database credentials writable after installation.
- Forgetting to recheck permissions after an FTP file transfer, which can reset certain permissions depending on the client used.
- Confusing file permissions with application user rights (CMS admin accounts): these are two entirely separate permission systems.
The special case of SSH access with several users
On a VPS or dedicated server where several system accounts can be involved (a developer, an automated deployment tool, the web server itself), file ownership becomes just as important as permissions. A file deployed by one user but that needs to be writable by another (the web server, for instance) requires either a properly configured shared group or a precise ownership adjustment depending on the folder concerned.
This is an important difference from shared hosting, where a single account generally owns all the files and the question of sharing between several system users doesn't arise in the same way.
Frequently asked questions
Why is 777 dangerous even temporarily?
How can I tell if a problem genuinely comes from file permissions?
Are permission settings the same across all hosting providers?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.