Employee profiles and permissions in the PrestaShop back office

Open the employee list in your back office and count how many are super administrators. In many shops the answer is «all of them»: the owner, the logistics person, the customer service person, the agency that built the theme years ago and an account called «shop» whose password half the team knows. It works until the day someone makes a mistake, leaves on bad terms or has their password stolen.

How PrestaShop organises access

Access is managed in Advanced Parameters → Team, with three pieces:

• Employees: each person with their email, their password and an assigned profile.
• Profiles: groups of permissions. PrestaShop ships with some (SuperAdmin, Logistician, Translator, Salesman) and you can create your own.
• Permissions: for each profile, what it can view, add, edit and delete in each section of the menu, and which modules it can configure.

The SuperAdmin profile cannot be restricted: it has access to everything, including employees, payment method settings, module installation and the webservice. That is why it is the profile to hand out most carefully.

The principle of least privilege

Each person should only have the permissions they need for their daily work. It is not about distrust: it limits what can go wrong with a stolen password or a wrong click. A reasonable starting point:

There should be two super administrators at most: the person in charge of the shop and whoever maintains it technically. If your agency needs to log in now and then, give it its own account that you enable when needed and disable when the work is done.

Why not to share accounts

A shared account is convenient and has three serious problems:

1. You do not know who did what. If a price is wrong or an order changes status, the history says «shop», not a person.
2. You cannot remove one person without disrupting everyone. When someone leaves, you either change the password and tell the others, or you leave it as it is. It is almost always left as it is.
3. The password gets passed around. It ends up in a WhatsApp message, on a sticky note or in the password manager of a personal laptop.

One account per person, always, even if there are only two people and one of them logs in once a month.

When someone leaves the company

This is the moment that gets neglected most. A list of steps that fits on a note:

1. Disable the account the same day; do not delete it. Disabled, it cannot log in, and you keep its trail in orders, messages and histories.
2. Check what other access they had: FTP, hosting control panel, the shop's email, payment gateway accounts, Google, social media, suppliers. The back office is only one of them.
3. Change the passwords they knew, even if they were shared «just for a moment».
4. Review any webservice keys they created. An API key does not depend on the employee's account and keeps working even if you disable them.
5. Review the modules they installed in their last few weeks.

Accounts nobody remembers

Besides departures, review the whole list every few months:

• Employees who have not logged in for a long time.
• Email addresses on domains that are neither yours nor your current agency's.
• Test accounts created during an installation or a migration.
• More super administrators than you remember creating.

A common case

A sports equipment shop changes agency. The previous agency had two super administrator accounts, one of them created for an intern who was there for one summer. Nobody disables them because «they don't log in any more». Months later, one of those passwords appears in a leak from another service where it had been reused, and someone logs into the back office with it. No vulnerability was needed: an account that no longer had an owner was enough.

A forgotten account with a weak password is a door nobody is watching. And if super administrators appear that nobody created, it is not an oversight: it is the typical trace of an SQL injection in a module, and it must be treated as an incident.

Passwords and access

• Long, unique passwords for each employee, stored in a password manager.
• A back-office folder with its own name, not the installation default.
• HTTPS across the whole back office, without exceptions.
• Two-factor authentication if your version or a module allows it, starting with the super administrators.
• PrestaShop and modules up to date: permissions are useless if a bug in a module lets someone create an administrator without going through the form.

Customer support without granting more permissions

A frequent reason for handing out super administrator accounts is that customer service «needs to see what the customer sees». The usual workaround is to ask the customer for their password or to create test accounts, and both are bad ideas. It is better to have a controlled way to log in as the customer, limited to the profiles you choose and with every access logged.

How to solve it in PrestaShop

RKR Security Alert keeps a snapshot of employees and webservice accounts and alerts you via Telegram about every creation, change or removal, highlighting super administrator accounts and promotions to that profile, even when they are made by direct SQL. It also warns you when an employee logs into the back office from an IP address that is new for them, and its audit flags inactive administrator accounts. RKR Acceso maestro takes care of support: it lets you log into a customer's account from their record, their order or the lists, with a single-use link, only for the employee profiles you choose (by default, SuperAdmin only) and with a log of which employee logged in as which customer, when and from which IP.