MODX Security Audit: Configuration, Access, Vulnerabilities

Recently we received a request from a client: their MODX site suddenly started redirecting visitors to phishing pages. During diagnostics we found that in a custom snippet $_GET['id'] was not escaped, allowing an attacker to inject SQL. Standard MODX protection (tokens, hashes) didn't help – the vulnerability was in the application layer. Such cases are not rare: according to OWASP, 70% of CMS hacks occur due to errors in custom code. Outdated extras (e.g., FormLister), incorrect permissions on core/, open /manager/ without IP restrictions – typical issues we find in nearly every third project. The total damage from a hack for small businesses can be significant, including data recovery and reputation. Manual audit detects 2–3 times more vulnerabilities than automated scanners and provides context for proper fixes. Get a MODX security audit to avoid such situations.

We have been conducting MODX site audits for over 5 years. During this time we have analyzed more than 120 projects – from small landing pages to large corporate portals. We guarantee that after our check you will receive a concrete list of vulnerabilities and recommendations for their elimination. On average, we find 12–15 vulnerabilities of varying criticality per project, with 80% related to outdated components. Fixing critical vulnerabilities typically saves significant costs on post-hack recovery. Comparison with automated scanners: manual analysis is 3 times more effective for detecting business logic vulnerabilities.

Why Outdated Extras Threaten Security?

Outdated plugins are one of the main causes of hacks. For example, FormLister (versions before 0.8.3) contains a vulnerability that allows arbitrary code execution. Replacing it with FormIt reduces the probability of RCE attacks by 70% – we observe this improvement in 90% of projects after an audit.

How to Protect Custom Code from SQL Injections?

We scan all snippets, plugins, and modules for direct SQL queries without escaping. We use grep and static analysis. According to Wikipedia, SQL injection is one of the most common vulnerabilities, and all database queries should be executed through $modx->query() or $modx->newQuery().

The key rule: never pass unescaped $_GET or $_POST into a query. Example vulnerability:

// Bad: SQL Injection
$id = $_GET['id'];
$result = $modx->query("SELECT * FROM modx_site_content WHERE id = $id");

// Good: escaping
$id = (int)$_GET['id'];
$result = $modx->getObject('modResource', $id);

Additionally, we check if $modx->db->query() is used directly – this error occurs in 60% of custom snippets. We recommend always using getObject or newQuery with parameter binding.

How to Protect the MODX Manager Panel?

Restrict /manager/ by IP – the most reliable method. If not possible, enable two-factor authentication (MODX supports TOTP via extra). Also mandatory:

• session_cookie_secure = 1 (HTTPS only)
• session_cookie_httponly = 1
• session_cookie_samesite = Strict
• Limit failed login attempts: failed_login_attempts = 5, blocked_minutes = 60

Example Nginx configuration:

location /manager/ {
    allow 192.168.1.0/24;
    deny all;
}

According to our statistics, 70% of MODX hacks occur through password guessing on /manager/. Setting a limit on attempts reduces the risk of brute force by 10 times.

How We Conduct the Audit: Stack and Process

We use both automated scanners and manual analysis. Main tools:

• Scanning: Nikto, ffuf (for hidden files), WPScan (adapted for MODX)
• Configuration analysis: file permissions, MODX system settings, HTTP headers
• Code audit: grep for $_GET, $_POST, $db->query() in custom components
• Version check: match Extra list against vulnerability database (CVE)

Process steps:

1. Diagnostics (1 hour): gather information about MODX version, installed Extras, PHP version, server settings.
2. Scanning (2 hours): automated search for common vulnerabilities, directory scanning.
3. In-depth analysis (4 hours): manual check of custom code, configuration files, access rights.
4. Report (2 hours): document each found vulnerability with criticality level, step-by-step recommendations for fixing.

Total time: 1 to 3 days depending on the amount of custom code.

What Is Included in the Result

Upon completion you receive:

• A report with detailed description of found vulnerabilities (screenshots, evidence)
• Recommendations for fixing with priorities
• Fixing of critical issues (upon agreement)
• Documentation for hardening Nginx/Apache and MODX configuration
• Secure development checklist for your team
• Re-scan after vulnerability remediation (on request)

Contact us for a preliminary assessment of your project – we will provide exact timelines and cost after a quick free diagnostics.

Deadlines and Cost

An audit takes from 1 day (standard) to 3 days (comprehensive with custom code). Cost is calculated individually, depends on the volume of Extras checked and the number of lines of code in custom modules. Fixing identified vulnerabilities takes from 4 to 16 hours depending on complexity. Get a consultation on the security audit of your MODX site.

Checklist for Self-Check (Typical Mistakes)

• The core folder must not be in the web-root.
• config.core.php must not be accessible via browser.
• The setup/ folder must be removed.
• All Extras are up to date.
• Permissions on assets/ folder – no PHP execution.
• session_cookie_secure and httponly enabled.
• Access to /manager/ restricted.
• Custom code checked for SQL injections.

Order a MODX security audit today and protect your site from hacking.

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.