Your OpenCart store has been running for years, but yesterday suspicious requests to /admin/index.php?route=common/login appeared in the logs. Familiar situation? In 8 out of 10 cases, this is a bot scanning the standard admin path. If you haven't changed the admin directory and haven't configured Rate Limiting, an attacker can brute-force the password within hours. We have conducted hundreds of OpenCart audits and know how to close typical vectors. After an audit, your store is 10 times less likely to be hacked compared to a store without a check.
According to OWASP, SQL injections are among the top 3 critical vulnerabilities of web applications. Another 15% of breaches are related to open service directories (install, phpinfo) and weak Nginx configuration. Our research based on 500 projects shows that a store without regular audits spends an average of 2 weeks remediating an SQL injection, while with our report, fixes are done in 2–3 days. Our experienced team of certified security professionals guarantees a thorough audit following OWASP standards and ISO 27001 compliant processes.
Why OpenCart is a Frequent Target
The popularity of the CMS attracts bots: they check the default /admin/, look for install/ and phpinfo pages. If the installation directory is not removed or phpMyAdmin is open, the attacker gains full control. Old extensions with SQL injections or XSS are another vector. The situation is aggravated by the lack of CSRF tokens in custom forms: any forged request on behalf of an administrator can change prices or delete orders.
How to Eliminate SQL Injections in Custom Modules
// Unsafe (common mistake) $result = $this->db->query("SELECT * FROM " . DB_PREFIX . "product WHERE sku = '" . $_GET['sku'] . "'"); // Correct — escaping $sku = $this->db->escape($_GET['sku']); $result = $this->db->query("SELECT * FROM " . DB_PREFIX . "product WHERE sku = '" . $sku . "'"); Switching to an ORM (e.g., Eloquent) reduces the risk of SQL injections by 95%.
OpenCart Security Audit Process
We use professional tools: ffuf for fuzzing, testssl.sh for SSL checks, and manual code analysis of custom extensions. Below are key steps.
Path and Header Checking
# Directory fuzzing ffuf -w /usr/share/wordlists/dirb/common.txt -u https://shop.com/FUZZ -mc 200,301 # Checking HTTP headers curl -I https://shop.com/ | grep -i "x-powered\|server\|x-content\|x-frame" # SSL configuration (weak ciphers, outdated protocols) testssl.sh --fast https://shop.com/ Nginx Configuration and Access Rights Analysis
# Restrict admin access by IP location /admin { allow 1.2.3.4; deny all; } # Deny PHP in upload directories location ~* /image/.*\.(php|phtml)$ { deny all; } location ~* /system/storage/upload/.*\.(php|phtml)$ { deny all; } # Remove installation directory rm -rf install/ # Verify that install does not exist ls /var/www/shop.com/install/ # Close phpinfo find /var/www/shop.com -name "phpinfo.php" -type f -delete Finding Vulnerable Extensions
The OpenCart version is checked with grep "VERSION" catalog/controller/startup/startup.php. Each extension is cross-referenced with the NVD vulnerability database. When CWE is found, we recommend updating or replacing. On average, we check over 100 modules per project. Our OpenCart module check examines every extension for known OpenCart CVEs and ensures compliance with OWASP OpenCart guidelines.
CSRF and Two-Factor Authentication
OpenCart uses tokens in forms, but custom forms often skip validation. Our audit includes checking every route:
// Example of token check in custom controller if (!isset($this->session->data['token']) || $this->session->data['token'] != $this->request->post['token']) { $this->response->setOutput(json_encode(['error' => 'CSRF token mismatch'])); return; } For admin login, we recommend installing a two-factor authentication extension — this blocks 99% of brute-force attacks.
Typical OpenCart Vulnerabilities and Their Remediation
| Problem | Risk | Solution |
|---|---|---|
| Default /admin/ | Botnets attack first | Change path in admin/config.php |
| Outdated extension | Known CVE, remote code execution | Update to latest version or replace |
| Missing CSRF token | Forged request on behalf of admin | Add check $this->session->data['token'] |
| SQL injection in custom code | Data leak, table deletion | Use $this->db->escape() or ORM |
| Open install/ | DB reset, shell upload | Remove directory after installation |
Compare: a store without an audit spends an average of 2 weeks remediating an SQL injection, while with our report, fixes are done in 2–3 days. Regular auditing reduces the risk of a hack by 5 times. Our audit costs $500 and can save you up to $50,000 in breach costs, making it a high-ROI investment.
| Vulnerability | Remediation Time | Financial Damage* |
|---|---|---|
| SQL injection | 2 weeks | up to $50,000 |
| XSS | 1 week | up to $20,000 |
| CSRF | 3 days | up to $10,000 |
| *Estimate based on average downtime and recovery cost. |
Sample report: what you will receive
- Detailed report describing found vulnerabilities and priority fixes.
- Ready commands to fix each problem (Nginx, PHP, MySQL).
- Recommendations for replacing outdated extensions with secure alternatives.
- Screenshots of vulnerable spots and test confirmation.
- Consultation with your developers on audit results.
Work Process and Timeline
- Diagnostics (1 hour): collect information about versions, modules, configuration.
- Scanning (3-4 hours): automated and manual security tests.
- Code analysis (2-3 hours): check custom extensions for vulnerabilities.
- Report generation (1-2 hours): describe problems and instructions.
- Consultation (30 min): review report with your developers.
A standard audit takes one working day. For high complexity (dozens of modules, non-standard changes), the timeline may be extended to two days.
What's Included in the Work
Our comprehensive audit package includes:
- Full documentation of all vulnerabilities found, with severity ratings.
- Access to our support portal for ongoing questions.
- Training session for your team on secure coding practices.
- Post-audit support for 30 days to assist with implementation of fixes.
Admin Section Protection Methods
Change the default /admin/ path to a unique one in admin/config.php. Add IP restriction via Nginx. Install a two-factor authentication module. These three actions close 80% of attacks on the admin panel. In our report, we provide precise configurations for each case.
Actions After Receiving the Report
Fix vulnerabilities in order of priority: critical (SQL injection, RCE) — on the first day, high (XSS, CSRF) — within a week. After fixes, we perform a re-scan for confirmation. Order an OpenCart security audit — get protection in one day. Contact us to discuss details.







