OpenCart Security Audit: Vulnerability Testing & Hacking Protection

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

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.

Work Process and Timeline

1. Diagnostics (1 hour): collect information about versions, modules, configuration.
2. Scanning (3-4 hours): automated and manual security tests.
3. Code analysis (2-3 hours): check custom extensions for vulnerabilities.
4. Report generation (1-2 hours): describe problems and instructions.
5. 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.

Web Application Security: HTTPS, CSP, XSS, CSRF, WAF, DDoS Protection

A website breach rarely looks like in movies. More often it's: a bot finds an unprotected /admin/export endpoint, downloads the customer database, and closes the connection. Or: through an outdated WordPress plugin, a web shell is uploaded, and the server starts sending spam. Or quieter: an XSS in a comment field allows stealing admin session cookies, unnoticed for months. We have analyzed dozens of such cases — each vulnerability could have been fixed at the development or audit stage.

Web application security is not a single setting. It's layers of protection, each closing a separate class of attacks. Order an audit — we'll assess the project and deliver a turnkey plan within 2–4 weeks.

How do we ensure comprehensive web application security?

HTTPS and Proper TLS Configuration

HTTPS is the minimum mandatory level. But having an SSL certificate and having a properly configured TLS are different things.

In Nginx/Apache configuration we check:

• Protocols: only TLS 1.2 and TLS 1.3, SSLv3 and TLS 1.0/1.1 are disabled
• Cipher suites: prefer ECDHE (Forward Secrecy), remove NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — browser will never make insecure requests
• OCSP Stapling — speeds up certificate revocation check
• Redirect 301 from HTTP to HTTPS — both in server config and code (double redirect causes SEO weight loss)

Check: SSL Labs (ssllabs.com/ssltest) should show A or A+. If B, the configuration is weak.

Let's Encrypt + Certbot for production is standard. Automatic renewal via certbot renew in cron. Wildcard certificates for subdomains via DNS-01 challenge.

Content Security Policy: The Most Powerful and Complex Protection

CSP is an HTTP header that tells the browser which sources are allowed to load resources. A properly configured CSP completely blocks most XSS attacks, even if the vulnerability exists in the code.

The problem: breaking the site with an incorrect CSP is easy. default-src 'none' — and fonts, images, JS stop working. So we start with Content-Security-Policy-Report-Only — CSP logs violations but does not block anything. We monitor reports for 2–4 weeks, refine the policy, then switch to enforcement mode.

Example of a real policy for a site with Google Analytics, Google Fonts, and Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — a random string generated server-side per request. Inline scripts with the correct nonce are allowed; without nonce, they are blocked. This completely breaks XSS via <script>alert(1)</script>.

'unsafe-inline' in style-src is a compromise for inline styles. It's better to remove it by moving all styles to CSS files, but that requires refactoring.

Why XSS Remains the Most Common Vulnerability?

XSS (Cross-Site Scripting) — injection of JS code through user input. According to OWASP, XSS is in the top 3 web application vulnerabilities. Three types:

Protection: never insert user input into HTML without escaping. In PHP — htmlspecialchars() with ENT_QUOTES. In Laravel Blade templates — {{ $var }} is safe, {!! $var !!} is dangerous. In React — {variable} is safe, dangerouslySetInnerHTML is dangerous. For Rich Text — use htmlpurifier on PHP or DOMPurify in the browser.

CSRF: Protecting Forms and APIs

CSRF (Cross-Site Request Forgery) — an attacker forces the victim's browser to send a request on their behalf. Example: a user is logged into a bank, opens a malicious page, which makes fetch('https://bank.ru/transfer?to=evil&amount=50000') — if the bank is unprotected, money is transferred.

CSRF tokens — standard protection for forms: the server generates a random token, stores it in the session, and inserts it as a hidden field in the form. On POST request, the token is verified. The attacker does not know the token. Laravel does this automatically with @csrf.

SameSite cookies — modern protection: SameSite=Strict or SameSite=Lax prevents the browser from sending cookies in cross-site requests. Works in all modern browsers.

API without sessions (JWT, Bearer tokens) — CSRF is irrelevant if the token is not stored in a cookie (but in the Authorization header or localStorage). However, localStorage is vulnerable to XSS — so for sensitive data, HttpOnly cookies with SameSite are preferable.

WAF and DDoS Protection

WAF (Web Application Firewall) filters HTTP traffic for attacks: SQL injection, XSS, path traversal, known exploit patterns. Options:

• Cloudflare WAF — cloud-based, OWASP Top 10 rules out of the box, custom rules via expressions. Managed Rules automatically block new threats.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Flexible but requires tuning and monitoring of false positives.
• AWS WAF — for infrastructure on AWS, integrates with CloudFront and ALB.

DDoS protection. Cloudflare at L3/L4/L7 is the de facto standard for most sites. Automatic mitigation of volumetric attacks, Under Attack Mode during active attacks. For critical infrastructure — Cloudflare Magic Transit or specialized solutions (Qrator, StormWall for the Russian market).

Rate Limiting at the application level — an additional layer. Laravel ThrottleRequests middleware: 60 requests per minute per IP for general endpoints, 5 for /login and /password/reset. Redis as a counter store — mandatory for horizontally scalable systems (otherwise limits are not synchronized between servers).

Other Mandatory Measures

Security headers. Besides CSP: X-Frame-Options: DENY (clickjacking protection), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (restrict browser API access: camera, microphone, geolocation).

SQL injection. Prepared statements everywhere. No concatenation of user input into SQL strings. ORM (Eloquent, Doctrine) protects by default. $wpdb->prepare() in WordPress is mandatory.

Dependency updates. composer audit and npm audit in CI/CD pipeline. Dependabot or Renovate for automatic PRs with updates. Critical CVEs — patch within 24 hours.

Secrets and configuration. .env — never in Git. Secrets in production — via CI/CD environment variables (GitHub Secrets, GitLab CI Variables) or HashiCorp Vault. Leak detection: git-secrets, truffleHog in pre-commit hooks.

How We Work

1. Audit — code scanning, configuration review, dependency analysis, manual business logic verification.
2. Planning — vulnerability remediation plan, stack selection (CSP, WAF, rate limiting).
3. Implementation — TLS setup, CSP configuration, headers, Rate Limiting, WAF.
4. Testing — re-penetration test, load testing, false positive check.
5. Deployment and Monitoring — enable production CSP, set up alerts, train the team.

What's Included

• Report with found vulnerabilities and recommendations (PDF + code snippets)
• Ready TLS configuration (Nginx/Apache)
• CSP policy with Report-Only and production versions
• WAF and Rate Limiting setup
• Dependency update plan
• Access to monitoring tools (Sentry, Datadog)
• 30 days of post-audit support (consultations, fixes)

Timeline and Cost

The budget is calculated individually — contact us for a project evaluation.