Note: The configurations shown are based on real-world production implementations but have been generalized for educational purposes. Adapt these to your specific requirements and always test in a staging environment first.

When you're running a high-traffic WordPress multisite serving millions of users, security isn't just a checkbox—it's a critical foundation of your infrastructure.

In this post, I'll walk you through a complete security implementation, from basic nginx configurations to advanced attack prevention. Whether you're running a WordPress site or any web application, you'll find practical security measures you can implement today.

The Challenge

Consider a WordPress multisite serving content in multiple languages:

• Main site (English): /
• Secondary language: /lang1
• Tertiary language: /lang2

Each site needs its own security considerations while maintaining consistent protection across the platform. High-traffic sites typically face these challenges:

1. High-Value Target: Popular sites are constantly targeted by:

   • Automated vulnerability scanners
   • Malicious bots and crawlers
   • SQL injection attempts
   • Brute force login attacks

2. Performance Impact: Security scanning tools cause:

   • High server CPU usage from repeated scanning
   • Increased bandwidth consumption
   • Slower response times for legitimate users
   • Occasional server timeouts during peak scan periods

3. Multilingual Complexity: Managing security across multiple sites means:

   • More entry points to protect
   • Complex URL patterns to secure
   • Different content types requiring varied security rules
   • Maintaining consistent security across all language variants

4. WordPress-Specific Vulnerabilities: Being on WordPress means dealing with:

   • Plugin security vulnerabilities
   • Theme security issues
   • Core WordPress exploits
   • File upload vulnerabilities

Let's dive into how to tackle this!

Security Implementation

Request Flow Through Security Layers

Every incoming request passes through these security layers in order:

If not static: Request proceeds to Apache/PHP Handler (WordPress Core)

1. Security Headers

First, implement essential security headers to protect against common web vulnerabilities:

# Prevent version disclosure
server_tokens off;

# HSTS for enforcing HTTPS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Prevent clickjacking attacks
add_header X-Frame-Options SAMEORIGIN always;

# Disable content-type sniffing
add_header X-Content-Type-Options nosniff always;

# Content Security Policy - the modern replacement for X-XSS-Protection
# Customize based on your site's requirements
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; frame-ancestors 'self';" always;

# Note: X-XSS-Protection is deprecated - Chrome removed XSS Auditor in 2019
# Modern browsers ignore this header. Use Content-Security-Policy instead.

These headers form our first line of defense against various attack vectors.

Important: Always add always to add_header directives to ensure headers are sent even on error responses.

2. Basic Security Measures

Implement several fundamental security measures:

# Prevent directory listing
autoindex off;

# Block double slash in URLs
location ~* //wp-content {
    return 403;
}

# Block hidden files (like .git, .htaccess)
location ~ /\. { deny all; }

# Handle favicon and robots.txt efficiently
location = /favicon.ico {
    log_not_found off;
    access_log off;
}

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
    try_files $uri /index.php?$args;
}

3. WordPress Core Protection

Implement strict access controls for WordPress core files and functionality:

# Block XML-RPC access
location ~* "xmlrpc.php" { deny all; }
location ~* "readme.txt" { deny all; }

# Protect sensitive WordPress directories
location ~* wp-admin/includes { deny all; }
location ~* wp-includes/theme-compat/ { deny all; }
location ~* wp-includes/js/tinymce/langs/.*\.php { deny all; }

# Block access to configuration files
location ~ /(\.|wp-config.php|readme.html|license.txt) { deny all; }

# Block temp files
location ~ ~$ { access_log off; log_not_found off; deny all; }

# Block archive files
location ~* ^/(wp-content)/(.*?)\.(text|txt|zip|gz|tar|bzip2|7z)$ { deny all; }

4. Upload Directory Security

Comprehensive protection for upload directories:

# Block backup directories
location ~ ^/wp-content/uploads/sucuri { deny all; }
location ~ ^/wp-content/updraft { deny all; }

# Protect plugin/theme documentation
location ~* ^/wp-content/plugins/.+\.(txt|log|md)$ {
    deny all;
    error_page 403 =404 / ;
}

# Secure multisite uploads
location ~* ^/wp-content/uploads/sites/\d+/ {
    try_files $uri $uri/ /index.php?$args;
    location ~ \.php$ {
        deny all;
    }
}

# Block PHP execution in uploads
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

# Block restricted file types in uploads
location ~* ^/wp-content/uploads/.*.(html|htm|shtml|php|js|swf|css)$ {
    add_header X-Block-Reason "Restricted Upload File Type" always;
    deny all;
    error_page 403 =404 / ;
}

5. Attack Prevention

SQL Injection Protection

Caveat: Regex-based SQL injection detection at the nginx level is a defense-in-depth measure, not a primary protection. It can produce false positives (blocking legitimate content containing words like "select" or "union") and is easily bypassed with encoding tricks. Always use parameterized queries/prepared statements as your primary defense.

# Block obvious SQL injection attempts
# Note: This catches common automated attacks but is NOT a substitute for
# proper input validation and parameterized queries in your application
location ~* "(\%27|\')(\%20|\s)*(or|and|union|select|insert|drop|delete|update|exec|execute)(\%20|\s)" {
    add_header X-Block-Reason "SQL Injection Attempt" always;
    deny all;
}

Path Traversal Prevention

# Block path traversal attempts
location ~ "(\\|\.\.\.|\.\./|~|`|<|>|\|)" {
    add_header X-Block-Reason "Path Traversal" always;
    deny all;
}

File Inclusion & CGI Protection

# Block sensitive file extensions
location ~* \.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$ {
    add_header X-Block-Reason "Sensitive File Extension" always;
    return 444;
}

# Block CGI execution
location ~* \.(pl|cgi|py|sh|lua)$ {
    add_header X-Block-Reason "CGI/Script Execution Not Allowed" always;
    return 444;
}

Documentation & Backup Protection

# Block access to documentation files
location ~* "/(^$|readme|license|example|README|LEGALNOTICE|INSTALLATION|CHANGELOG)\.(txt|html|md)" {
    add_header X-Block-Reason "Documentation File Protected" always;
    deny all;
}

# Block access to backup files
location ~* "\.(old|orig|original|php#|php~|php_bak|save|swo|aspx?|tpl|sh|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rdf)$" {
    add_header X-Block-Reason "Backup/Log File Protected" always;
    deny all;
}

XSS & Command Injection Protection

Important: Content-Security-Policy headers (configured above) are your primary XSS defense. These nginx rules are supplementary blocking for obvious attack patterns.

# Block script tag injection attempts
# Catches common XSS patterns with URL encoding variations
location ~* "(<|%3C)\s*script.*?(>|%3E)" {
    add_header X-Block-Reason "XSS Attempt" always;
    deny all;
}

# Block obvious event handler injection (onerror, onload, etc.)
location ~* "(\%20|\s)(on\w+)\s*=" {
    add_header X-Block-Reason "XSS Attempt" always;
    deny all;
}

Note on command injection: Blocking shell metacharacters in nginx location blocks is generally not recommended as it can break legitimate URLs containing common characters like : (ports, protocols), % (URL encoding), or ; (query parameters). Implement command injection protection in your application layer with proper input validation and avoid shell execution where possible.

Performance Optimization

While security was our primary focus, we also implemented performance optimizations to ensure fast content delivery.

1. Direct Static File Serving

Instead of proxying to Apache, serve static files directly through nginx for better performance:

# Multilingual static asset handling
location ~* ^/(bn|np)?/.*\.(jpg|jpeg|png|gif|ico|css|js|svg|woff2)$ {
    access_log off;
    expires max;
    add_header Cache-Control "public, no-transform";
    add_header X-Static-File "true";
    try_files $uri $uri/ =404;
}

This configuration:

• Handles files for all language variants
• Implements aggressive caching
• Bypasses Apache completely for static content
• Reduces server load significantly

2. WordPress Content Optimization

Apply similar optimizations to WordPress content:

# WordPress content handling
location ~* ^/(bn|np)?/wp-content/ {
    access_log off;
    expires max;
    add_header Cache-Control "public, no-transform";
    add_header X-Static-File "true";
    try_files $uri $uri/ =404;
}

Dealing with Bounty Hunters and Security Scanners

One of the biggest challenges for high-traffic sites is the constant load from bounty hunters and automated security scanners. Popular websites are frequent targets for:

• Bug bounty hunters running automated scans
• Security researchers testing for vulnerabilities
• Automated vulnerability scanners and bots
• Penetration testing tools running continuous scans

These activities can create significant server load and occasionally impact site performance. The security implementations above help in several ways:

1. Early Request Filtering: By blocking malicious patterns at the nginx level, these requests never reach the application server
2. Reduced Server Load: Security scanners often make thousands of requests testing for vulnerabilities - these rules block them at the edge
3. Resource Protection: Rules preventing access to sensitive paths and files mean fewer server resources wasted on handling these requests
4. Improved Response Times: By blocking known attack patterns early in the request cycle, you maintain better response times for real users

The implementation effectively creates a robust shield, allowing legitimate traffic through while filtering out potentially harmful automated scans.

Expected Results

After implementing these security measures, you should see:

1. Reduced Attack Surface: Blocking common attack vectors before they reach your application
2. Better Performance: Security layers help improve site speed by blocking malicious requests early
3. Lower Server Load: Blocking bad bots and attacks at the nginx level reduces unnecessary load on application servers
4. Improved SEO: Search engines favor secure sites, and proper security headers can help rankings

These security measures are battle-tested in production environments serving thousands of users daily.

Rate Limiting

To protect against abuse and DDoS attacks, implement comprehensive rate limiting:

# Define memory zones and rates for different request types
# Format: limit_req_zone $identifier zone=name:size rate=r/time_unit;

# General API requests
limit_req_zone $binary_remote_addr zone=general_api:10m rate=60r/m;

# Resource-intensive operations
limit_req_zone $binary_remote_addr zone=intensive_ops:10m rate=10r/m;

# Static file access
limit_req_zone $request_uri zone=static_files:10m rate=60r/s;

# Frontend requests
limit_req_zone $binary_remote_addr zone=frontend:10m rate=150r/m;

# Admin area requests
limit_req_zone $binary_remote_addr zone=admin:10m rate=600r/m;

This configuration demonstrates a tiered rate limiting approach:

• Low rate (10r/m) for resource-intensive operations
• Medium rate (60r/m) for general API endpoints
• High rate (150r/m) for frontend requests
• Very high rate (600r/m) for admin operations
• URI-based limiting (60r/s) for static resources

Apply these limits in your location blocks:

# Example: Applying rate limits to different endpoints

# Resource-intensive endpoint
location /api/resource-heavy {
    limit_req zone=intensive_ops burst=5 nodelay;
    # ... rest of your configuration
}

# General API endpoint
location /api/ {
    limit_req zone=general_api burst=10 nodelay;
    # ... rest of your configuration
}

# Admin area
location /wp-admin/ {
    limit_req zone=admin burst=20 nodelay;
    # ... rest of your configuration
}

Testing and Verification

Here's a template for testing your security implementation:

1. Basic Access Testing:

   # Test homepage access
   curl -I https://your-domain.com/
   
   # Test subsite access (if using multisite)
   curl -I https://your-domain.com/site1/
   curl -I https://your-domain.com/site2/
   

2. Security Rule Testing:

   # Test file execution protection
   curl -I "https://your-domain.com/wp-content/uploads/test.php"
   curl -I "https://your-domain.com/wp-content/themes/test.php"
   
   # Test SQL injection protection
   curl "https://your-domain.com/?id=1%27%20or%201=1"
   curl "https://your-domain.com/?user=admin%27%20union%20select"
   
   # Test path traversal protection
   curl -I "https://your-domain.com/wp-content/plugins/../../../etc/passwd"
   
   # Test sensitive file protection
   curl -I "https://your-domain.com/wp-config.php"
   curl -I "https://your-domain.com/.env"
   

3. Rate Limit Testing:

   # Function to test rate limits
   test_rate_limit() {
       local endpoint=$1
       local requests=$2
       local delay=${3:-0}
   
       echo "Testing rate limit for $endpoint"
       for i in $(seq 1 $requests); do
           curl -I "$endpoint" &>/dev/null
           echo -n "."
           sleep $delay
       done
       echo "Done!"
   
       # Final request to check if rate limit is triggered
       curl -I "$endpoint"
   }
   
   # Example usage:
   # test_rate_limit "https://your-domain.com/api/" 100 0.1
   # test_rate_limit "https://your-domain.com/wp-admin/" 50 0.2
   

4. Bot Detection Testing:

   # Test with different User-Agents
   curl -I -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://your-domain.com/
   curl -I -A "facebookexternalhit/1.1" https://your-domain.com/
   curl -I -A "Mozilla/5.0 (compatible; Bingbot/2.0)" https://your-domain.com/
   

Remember to:

• Replace your-domain.com with your actual domain
• Adjust request numbers and delays based on your rate limits
• Test from different IP addresses to verify IP-based limits
• Run tests in a staging environment first
• Monitor logs while testing to verify proper blocking

Maintenance Best Practices

To keep your security implementation effective:

1. Monitor Logs: Regularly check nginx error logs for blocked attempts
2. Update Rules: Keep security rules current with new threat patterns
3. Test After Updates: Verify security measures after WordPress core/plugin updates
4. Review Rate Limits: Adjust rate limiting based on traffic patterns
5. Audit Bot Access: Monitor and update bot detection patterns

Defense-in-Depth Model

Security layers between attacker and WordPress application:

Outcomes:

• Malicious requests → Blocked or Blocked/Logged
• Legitimate requests → Protected App

These security measures have proven effective in production environments. Remember to adapt these configurations to your specific needs and regularly test their effectiveness.