Fix Elementor 403 Forbidden and Server Errors When Saving

You hit Update in Elementor, the green button spins for a couple of seconds, and a red “Server Error (403 Forbidden)” banner pops up at the bottom. Your changes aren’t saved, and repeating the click does nothing.

This almost never means your WordPress user lost editor permissions. What actually happens is that Web Application Firewalls (WAFs) like ModSecurity, LiteSpeed WAF, or Cloudflare mistake Elementor’s massive serialized JSON save payload for an SQL injection or XSS attack.

Inspect the Network Tab to Catch the Blocked Request

Before tweaking server configs, find out which exact endpoint is returning the 403. Guessing wastes time because different Elementor widgets post to different handlers.

Open browser DevTools (F12 or Cmd + Option + I), head to the Network tab, filter by Fetch/XHR, and click Update in Elementor again. You’ll see one of two requests fail in red with a 403 status:

• /wp-admin/admin-ajax.php with the action elementor_ajax
• /wp-json/elementor/v1/globals or another WordPress REST API endpoint

Click the failed request and check its Response tab. If ModSecurity or a LiteSpeed WAF killed it, you’ll usually see raw server HTML saying “Access Denied” or “403 Forbidden” instead of a clean JSON response from WordPress core.

If your editor won’t even load in the first place, check out our guide on how to fix Elementor stuck on loading screen in WordPress first.

Disable or Whitelist ModSecurity Rules

In roughly 80% of the cases I run into, Apache’s ModSecurity is the culprit. When you save a complex page with embedded CSS, custom HTML widgets, or iframe embeds, Elementor packs all of it into a stringified JSON blob inside a POST request. The OWASP ModSecurity Core Rule Set sees those tags and flags them as an injection attempt.

If you’re on cPanel, look for ModSecurity under Security and toggle it off temporarily for your domain to verify if the save goes through. On an Ubuntu or Debian VPS, check the audit log via SSH:

grep -i "elementor_ajax" /var/log/apache2/modsec_audit.log | tail -n 20

Look for lines referencing rule IDs like [id "941100"] or [id "949110"]. Once you know the exact ID triggering the false positive, whitelist just that rule in your Apache vhost or .htaccess instead of disabling the firewall completely:

 SecRuleRemoveById 941100 949110 980130

If your web host restricts SecRuleRemoveById inside user .htaccess files, open a ticket with their support team and ask them to whitelist those specific ModSecurity rule IDs for your account.

Fix .htaccess Authorization and REST API Headers

Elementor depends heavily on the WordPress REST API to fetch fonts, store global styles, and handle revisions. If Apache drops the HTTP Authorization header or rewrites REST requests badly, you get slapped with a 403 or 401.

Open the .htaccess file in your WordPress root and make sure the standard rewrite block is there without broken custom redirect rules:

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

The line RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] makes sure PHP-FPM receives auth tokens passed by the Elementor editor during background sync calls.

If you recently switched the site over to HTTPS and are seeing security blocks on mixed content resources, see how to fix SSL mixed content in WordPress so your browser doesn’t drop requests.

Increase PHP Limits and max_input_vars

Elementor submits huge forms on complex pages. If PHP’s input limit truncates the incoming POST array, the data packet gets corrupted and WordPress aborts the save with an error.

Open your php.ini, .user.ini, or your host’s PHP settings panel and set these minimum values:

memory_limit = 512M
max_input_vars = 5000
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300

The parameter max_input_vars = 5000 is the one people usually miss. Default PHP configs set this to 1000. Once your Elementor page has more than 1000 distinct controls and widget settings, PHP silently drops the overflow, causing broken payloads and random 403 or 500 errors.

You can check your active runtime limits inside WordPress under Elementor > System Info. If you’re on shared hosting, check our walk-through to increase PHP memory limit in WordPress across different configs.

Configure Cloudflare WAF Rules for Elementor

If your DNS runs through Cloudflare, its WAF might be blocking admin-ajax.php calls before they ever touch your server. Check your domain’s Security Events dashboard in Cloudflare to see if saves are getting flagged.

Don’t shut off Cloudflare’s WAF entirely. Just add a targeted WAF Custom Rule that skips managed rules for authenticated editor requests:

1. Log into Cloudflare and pick your domain.
2. Go to Security > WAF > Custom Rules and click Create rule.
3. Name it Bypass WAF for Elementor Admin.
4. Set the expression to match your editor calls:

(http.request.uri.path contains "/wp-admin/admin-ajax.php" and http.request.body contains "action=elementor_ajax") or (http.request.uri.path contains "/wp-json/elementor/")

Set the action to Skip and select the security components you want bypassed (Managed Rules, Rate Limiting) when those conditions match your IP or admin session.

Reset File Permissions on wp-admin and wp-content

If your web server user (www-data, apache, or nginx) cannot read wp-admin/admin-ajax.php or write to cache folders, Linux throws a 403 Forbidden instantly.

SSH into your server, cd into your WordPress directory (e.g., /var/www/html), and reset standard permissions:

cd /var/www/html
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chown -R www-data:www-data wp-content wp-includes wp-admin

Never set directory permissions to 777 to get around an error. 755 for directories and 644 for files gives PHP all the access it needs while keeping the filesystem secure.

Isolate Third-Party Plugin and Addon Conflicts

Third-party widget packs and security plugins like Wordfence or Sucuri love to hook into save routines to scan content before it hits the database.

If you’re using Wordfence, switch it to Learning Mode for a quick test:

1. Head to Wordfence > Firewall > Manage Firewall.
2. Change the status to Learning Mode.
3. Go back to Elementor and click Update on the broken page.
4. Switch Wordfence back to Enabled and Protecting.

If you aren’t using Wordfence and want to test addon conflicts without breaking the live site for visitors, test on a staging clone. Follow our tutorial on how to set up a WordPress staging site to safely isolate plugins one by one.

To audit active plugins from your terminal, list them with WP-CLI:

wp plugin list --status=active --field=name

Deactivate third-party Elementor addon packs temporarily to see if the 403 disappears:

wp plugin deactivate essential-addons-for-elementor-lite premium-addons-for-elementor

If the page saves cleanly after disabling them, turn the plugins back on one by one until you find the one triggering the block.

Frequently Asked Questions

Why does the 403 error only happen on one specific page?

That specific page probably has content (like an iframe embed, tracking script, or inline SVG) that matches a strict regex pattern in your firewall. Simpler pages don’t carry those tags, so they slip past ModSecurity without issues.

Does disabling ModSecurity permanently create a security risk?

Yes. Turning off ModSecurity entirely leaves your server exposed to automated exploit scanners and brute force attacks. Always whitelist the specific rule IDs causing false positives instead of killing the whole service.

What is the difference between a 403 Forbidden error and a 500 Server Error in Elementor?

A 403 Forbidden means the server or firewall understood the request but explicitly refused to execute it due to permissions or security rules. A 500 Internal Server Error means the server started executing PHP, but crashed due to memory exhaustion, a fatal syntax error, or a timeout.

Why does clearing browser cache not fix the Elementor 403 save error?

The 403 response comes dynamically from your web server or WAF when it evaluates the save payload you sent. Because it’s a server-side rejection, clearing local browser files won’t change the firewall’s decision.

Next Steps

Once you’ve scoped your ModSecurity exceptions and bumped max_input_vars to 5000, Elementor should save large layouts without hitting 403 walls. If you run into issues where the editor itself won’t load, take a look at our guide on resolving the Elementor loading screen issue to fix underlying admin-ajax bottlenecks.