KNOWLEDGE BASE
How do you review e-commerce security and administrator permissions?
Table of Contents — English
How do you define the scope of the review?
List the admin panel, customer account, API, file upload areas and external service access. For each area, determine which data is read or modified. Payment information, customer addresses and price changes may not carry the same level of risk; the impact of each action should be assessed.
The OWASP API Security Top 10 2023 classifies API risks such as object-level authorization, authentication and resource consumption. This list is a starting reference; it does not mean the application has been fully audited or has received a security certification.
How do you define admin roles?
1. List the business tasks: editing products, adjusting stock, viewing orders, changing prices and issuing refunds, for example.
2. Link each task to the roles that need it. A support employee may not need permission to change all prices in order to answer a customer question. Start with a least-privilege approach.
3. Use personal accounts. A shared account makes it hard to identify who performed an action and to revoke access. Apply multi-factor authentication wherever it is supported.
4. Revoke departing staff's access in all connected systems. The scope should include not only the store panel but also cloud accounts and integration tools.
Is permission checked only in the interface?
No. Hiding a button does not protect the server-side action. When a user sends an API request directly, the role and the authorization to access the relevant record must still be checked. For example, a customer should not be able to reach another customer's record by changing the order ID in the address bar.
How do you manage secret keys and audit logs?
Keep API keys in a secure configuration with restricted access. Separate test and live environment keys. Record which service, with what permissions and under which owner each key is tied. There should be a path to rotate a key and update connected systems if a leak is suspected.
Audit logs should show who made critical changes. However, passwords, card data or unnecessary personal data must not be written to logs. Access to the logs and their retention period should also be controlled. Keeping excessive logs does not automatically make operations more secure.
Which tests verify the controls?
Send a request directly for an admin action using a low-privilege account; the action should be rejected. Try another customer's order ID; no data should be exposed. Verify that no critical action can be performed with an expired session and that a disabled account cannot start a new session. These tests should be run only in an authorized test environment.
Check that backup files are not publicly accessible, that restore access is restricted and that critical audit records can be retrieved. Track findings by risk, affected action, owner of the fix and retest result. This guide provides a baseline control framework; for high-risk systems it does not replace a comprehensive expert review.
What are the frequently asked questions?
What is the next step?
List your admin roles and critical access points, and assess the scope of the security review with PROJX Digital.
