WordPress Integration Guide

AtomicEdge provides specialized protection for WordPress sites with pre-configured rulesets targeting WordPress-specific attack vectors. This guide covers setup, optimization, and troubleshooting for WordPress installations.

Initial Setup

Adding Your WordPress Site

  1. Log in to the AtomicEdge dashboard
  2. Add a new site with your WordPress domain
  3. Configure backend IP to your WordPress server
  4. Enable SSL/TLS if your origin uses HTTPS
  5. Save configuration and note provided edge endpoint IP

DNS Configuration

Update your domain’s DNS to point to the edge endpoint:

Type: A
Name: @
Value: [provided-edge-ip]
TTL: 300

For WordPress installations using www:

Type: A
Name: www
Value: [provided-edge-ip]
TTL: 300

Allow 5-30 minutes for DNS propagation before testing.

Rule Group Configuration

WordPress-Specific Protection

Enable the WordPress rule group in your site’s WAF settings. This ruleset includes protection against:

  • xmlrpc.php abuse
  • wp-login.php brute force attacks
  • Plugin and theme vulnerability exploits
  • WordPress-specific SQL injection patterns
  • Authentication bypass attempts
  • Sensitive file access (wp-config.php, .htaccess)

OWASP Core Rule Set

Enable OWASP CRS alongside WordPress rules for comprehensive protection:

  • Generic SQL injection detection
  • Cross-site scripting (XSS) prevention
  • Local file inclusion attempts
  • Remote code execution patterns
  • Command injection blocking

Response Configuration

Configure how blocked requests are handled:

  • 403 Forbidden: Standard blocking response (recommended)
  • 404 Not Found: Stealth mode – attackers see “not found” instead of “forbidden”
  • Drop: Silently terminate connection without response

Common False Positives

WordPress Admin Operations

Certain WordPress admin operations may trigger WAF rules. Common scenarios:

Post/Page Editing with HTML

Complex HTML in post content may trigger XSS rules. If legitimate editors are blocked:

  1. Identify the triggered rule ID from security logs
  2. Add the rule ID to disabled rules list
  3. Test that editing works correctly
  4. Verify the rule is still active for other contexts

Plugin/Theme Updates

File upload operations during updates may trigger file inclusion rules. Temporary solutions:

  1. Add admin IP to whitelist during updates
  2. Disable specific rules that block file operations
  3. Re-enable after updates complete

Media Uploads

Large file uploads or specific file types may be blocked. Check security logs for:

  • File size limits
  • Content-type restrictions
  • Upload path validation rules

REST API Requests

WordPress REST API endpoints may trigger rules if they contain complex JSON payloads. Test API functionality:

curl -X POST https://example.com/wp-json/wp/v2/posts \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer [token]" \
  -d '{"title":"Test","content":"Test content"}'

If blocked, identify the rule from logs and evaluate whether to disable it for /wp-json/ paths.

Gutenberg Editor

The block editor sends complex AJAX requests that may trigger rules. Test:

  1. Create a new post with various block types
  2. Add code blocks with HTML/CSS/JS
  3. Test saving and publishing
  4. Check for 403 errors in browser console

If issues occur, review security logs and disable problematic rules.

Access Control

Admin Area Protection

Restrict wp-admin access to specific IPs:

  1. Navigate to site settings
  2. Enable Page Protection feature
  3. Add /wp-admin/ to protected paths
  4. Add authorized IP addresses to whitelist
  5. Test access from allowed and blocked IPs

Example configuration:

Protected Paths:
  /wp-admin/
  /wp-login.php

Whitelist IPs:
  203.0.113.10 (Office)
  198.51.100.25 (Home)

Login Rate Limiting

Prevent brute force attacks against wp-login.php:

  1. Enable Rate Limiting feature
  2. Configure events per minute (recommended: 5)
  3. Apply to /wp-login.php path
  4. Test that legitimate logins work
  5. Test that rapid attempts are blocked

Rate limiting applies per source IP, so legitimate users are not affected by attacks from other IPs.

Geographic Restrictions

Block access from countries with no legitimate users:

  1. Enable Geographic Blocking feature
  2. Select countries to block
  3. Test access from blocked regions (using VPN)
  4. Monitor logs for blocked attempts

This is particularly effective against large-scale botnet attacks.

Bot Protection

Legitimate Bot Handling

WordPress sites need access from legitimate bots:

  • Search engines (Google, Bing)
  • Social media crawlers (Facebook, Twitter)
  • Uptime monitors
  • Analytics services

AtomicEdge bot protection whitelists known legitimate bots. Enable bot protection to block:

  • AI scrapers
  • Content harvesters
  • Unauthorized crawlers
  • Scanner tools

Configure bot protection response:

  • 403: Standard block
  • 404: Hide the fact that site exists
  • Drop: Waste attacker resources

Testing Bot Protection

Verify legitimate bots can still access:

# Simulate Googlebot
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com

# Should return 200 OK

Test that unknown bots are blocked:

# Simulate scraper bot
curl -A "ScrapeBot/1.0" https://example.com

# Should return configured block response

Performance Optimization

Caching Considerations

AtomicEdge acts as a reverse proxy. Consider:

  • WAF operates before caching layer
  • All requests are inspected regardless of cache status
  • Origin server load is reduced by legitimate traffic only
  • Cached content is served faster due to edge proximity

WordPress Caching Plugins

AtomicEdge is compatible with WordPress caching plugins:

  • WP Super Cache
  • W3 Total Cache
  • WP Rocket
  • LiteSpeed Cache

The WAF layer and plugin caching layer work independently. Use both for optimal performance.

Database Query Reduction

WAF protection reduces database load by:

  • Blocking automated scanners before they reach WordPress
  • Preventing malicious query attempts
  • Reducing brute force login database operations

Monitor your database query volume after enabling protection – you should see a reduction in malicious query patterns.

Monitoring and Maintenance

Security Log Review

Check security logs regularly for:

  • Blocked attack patterns
  • False positive indicators (legitimate users blocked)
  • Geographic attack distribution
  • Most triggered rules

Use log filtering to focus on specific attack types:

Filter by Rule ID: 941100 (XSS detection)
Filter by URI: /wp-admin/
Filter by IP: Specific attacker

WordPress Updates

After WordPress core, plugin, or theme updates:

  1. Test site functionality
  2. Check for new false positives
  3. Review security logs for errors
  4. Update disabled rules if needed

Major WordPress version updates may change behavior. Test thoroughly in staging before production.

Plugin Compatibility

Most WordPress plugins work without modification. Issues may occur with:

  • Security plugins with overlapping functionality
  • Plugins that modify HTTP headers
  • Plugins with custom authentication schemes
  • File upload plugins with unusual validation

Test new plugins in staging with WAF protection enabled.

Troubleshooting

Login Issues

If users cannot log in:

  1. Check security logs for blocked /wp-login.php requests
  2. Verify rate limiting is not too aggressive
  3. Check for IP whitelist misconfigurations
  4. Test from different networks

Temporary bypass for testing:

  1. Add user’s IP to access control whitelist
  2. Verify login works
  3. Identify triggered rule from logs
  4. Disable problematic rule or adjust configuration

Admin Area Errors

If wp-admin pages show errors:

  1. Check browser console for 403 errors on AJAX requests
  2. Review security logs for blocked admin-ajax.php calls
  3. Test with different browser (clear cache)
  4. Check for rules blocking POST requests

Media Upload Failures

If file uploads fail:

  1. Verify file size is within WordPress limits
  2. Check security logs for file upload blocks
  3. Test upload of different file types
  4. Review rules related to multipart/form-data

REST API Failures

If REST API requests fail:

  1. Test API directly with curl
  2. Check for JSON payload size limits
  3. Review authentication header handling
  4. Verify Content-Type headers are preserved

Debug API calls:

curl -v https://example.com/wp-json/wp/v2/posts | jq .

Look for HTTP status codes and response headers indicating blocks.

Theme/Plugin Conflicts

If specific themes or plugins misbehave:

  1. Identify specific blocked requests in logs
  2. Correlate blocks with theme/plugin functionality
  3. Test with default WordPress theme
  4. Disable problem plugins temporarily to isolate

Best Practices

Layered Security

AtomicEdge provides perimeter defense. Maintain additional security layers:

  • Keep WordPress core updated
  • Update plugins and themes promptly
  • Use strong passwords and 2FA
  • Regular database backups
  • Malware scanning

WAF protection is not a substitute for secure WordPress configuration.

Whitelist Management

Keep IP whitelists current:

  • Remove old office/employee IPs
  • Document each whitelisted IP
  • Use specific IPs rather than broad ranges
  • Review whitelist quarterly

Rule Tuning

Review disabled rules periodically:

  • Check if disabled rules are still necessary
  • Verify false positives are still occurring
  • Test re-enabling rules in staging
  • Document reason for each disabled rule

Monitoring

Set up monitoring for:

  • Unusual traffic spikes
  • Geographic attack patterns
  • Specific rule trigger frequency
  • False positive rates

Use dashboard analytics to track security metrics over time.

Advanced Configuration

Custom Header Passthrough

If your WordPress site requires custom headers:

  1. Test that headers are preserved
  2. Check security logs for header-related blocks
  3. Configure header whitelist if needed

Multisite Configuration

For WordPress multisite networks:

  1. Configure protection for primary domain
  2. Add each subdomain as separate site, or
  3. Use wildcard configuration for subdomains
  4. Test cross-site requests

Staging Environment

Set up separate protection for staging:

  1. Add staging subdomain as separate site
  2. Use less restrictive rules for testing
  3. Test WordPress updates in staging first
  4. Verify no false positives before production

API Integration

For headless WordPress installations:

  1. Ensure REST API endpoints are accessible
  2. Test authentication methods
  3. Verify JSON payload handling
  4. Check CORS headers if needed

Test headless configuration:

# Test REST API availability
curl https://example.com/wp-json/

# Test authenticated request
curl https://example.com/wp-json/wp/v2/posts \
  -H "Authorization: Bearer [token]"

Migration Checklist

Before migrating WordPress site to AtomicEdge protection:

  • [ ] Back up WordPress database and files
  • [ ] Document current DNS configuration
  • [ ] Test site in staging environment
  • [ ] Configure WAF rules (WordPress + OWASP CRS)
  • [ ] Set up rate limiting for wp-login.php
  • [ ] Configure admin area IP restrictions
  • [ ] Test login and admin functionality
  • [ ] Test plugin and theme operations
  • [ ] Test REST API if used
  • [ ] Update DNS with low TTL
  • [ ] Monitor logs for false positives
  • [ ] Tune rules based on initial traffic
  • [ ] Increase DNS TTL after stable period
  • [ ] Document any disabled rules and reasons