---
title: Firewall or WAF blocking GravityKit imports and exports
url: "https://www.gravitykit.com/docs/general-help/firewall-waf-blocking-imports-exports/"
updated: "2026-08-10"
category: General Help
---

# Firewall or WAF blocking GravityKit imports and exports

If an import or export fails part-way through — or never starts — your site’s firewall may be blocking the request before it reaches WordPress. This article shows you how to confirm that, and how to fix it in Cloudflare, in a host-level firewall, and in security plugins like Wordfence.

## What you’ll see

The symptoms depend on which firewall is in the way, but they all look like the plugin failing for no reason:

- A **403 Forbidden** error when starting or running an export or import.
- A Cloudflare block or challenge page instead of a response. The response has a `cf-mitigated: challenge` header.
- **“Server returned an empty response”**.
- The progress bar sits at 0%, or stops part-way and never resumes.
- Your browser’s Network tab shows a failed `POST` to `admin-ajax.php`, or a failed request to a `/wp-json/` URL.

## Why it happens

Imports and exports move your form and entry data between the browser and the server: an upload carrying a whole export file, or a run of requests carrying form definitions, settings and progress state. That data is ordinary content — but to a generic security rule it can look like an attack.

Firewalls ship with SQL-injection rules that match words and characters common in real form data and in Gravity Forms settings: `SELECT`, `UNION`, `CONCAT`, quotes, parentheses, and so on. When one of those rules matches, the firewall blocks the request. WordPress never sees it, so the plugin has nothing to report beyond a 403 or an empty response.

Nothing is wrong with your site or with the plugin. The request just needs to be allowed through.

## Step 1: Confirm the firewall is the cause

1. **Open your browser’s Network tab** (F12 → Network), then start the export or import again. Look for a request that returns 403 or fails.
2. **Check the response headers.** A `cf-mitigated` header, or a Cloudflare block or challenge page in place of the response, means Cloudflare stopped it. A `cf-ray` header on its own does *not* — Cloudflare puts a Ray ID on every request it proxies, including successful ones. Use the Ray ID to look the request up, not as proof of a block.
3. **Check your logs.** In Cloudflare, open your zone’s security events log and search by Ray ID to see exactly which rule fired. On other hosts, ask for your ModSecurity or firewall log for the time of the failure.
4. **Test with the firewall paused.** If the export succeeds with the firewall off and fails with it on, you’ve confirmed it.

**If the Network tab shows no failing request at all**, and an import simply stalls, this article is probably not your problem. A stalled background import usually means the site cannot make a *loopback* request to its own domain — background processing works by the server calling its own `admin-ajax.php`, and a firewall that blocks the server from reaching its own hostname stalls the run with nothing failing in your browser at all. Ask your host to allow the server to reach its own hostname, or set up a real system cron.

## Step 2: Know which requests to allow

Allow these specific requests, rather than opening up `admin-ajax.php` or the REST API as a whole:

 ProductRequestGravityMigrate — running an export or import`POST` to `/wp-admin/admin-ajax.php` with `action=gk_foundation_do_ajax`. (This one action covers the `gk_exporter`, `gk_importer` and `settings` routers that the migration screens use.)GravityMigrate — uploading the import file`POST` and `DELETE` to `/wp-json/gk-foundation/v1/process-upload`. **Easy to miss:** the entire export ZIP is sent in one `POST`, so this is the request a size or payload rule is most likely to kill.GravityImport — file upload and field mapping`POST` to `/wp-admin/admin-ajax.php` with `action=gv_import_entries_csv_upload`, `gv_import_entries_form_data`, or `gv_import_entries_add_form_field`GravityImport — processing rows`/wp-json/gravityview/import/v1/` and everything under itGravityBoard`/wp-json/gravityboard/v1/` and everything under it — see [Troubleshooting 403 errors in GravityBoard](https://www.gravitykit.com/docs/gravityboard/403-errors-in-gravityboard/)

### What you are actually allowing

These endpoints are not all protected the same way, so allow only the rows for the product you are troubleshooting:

- **GravityMigrate, running an export or import** — requires a logged-in user and a valid WordPress nonce. The nonce is issued to the logged-in user on the migration screen, so this is not reachable anonymously.
- **GravityMigrate, uploading the import file** — additionally requires the `manage_options` capability, so administrators only.
- **GravityImport** — requires the `gravityforms_edit_entries` capability. That is a Gravity Forms capability, which can be granted to non-administrator roles, and it is filterable.
- **GravityBoard** — **not an admin-only surface.** Boards render on the front end, and each board’s own “who can view / add / edit” settings decide who may call these endpoints. A board set to *Everyone (Including Logged-Out Users)* is reachable by anonymous visitors with no nonce and no capability. Allowing these paths through your firewall exposes exactly whatever the board is already configured to expose — check the board’s settings before you allow it.

## Step 3: Fix it

### Cloudflare

Cloudflare’s Managed Ruleset is the usual culprit. Rather than turning rules off site-wide, add an **exception** (a skip rule) scoped as tightly as you can.

**Do not scope the exception on the `Referer` header.** Anyone can set that header to any value, so a rule keyed on it would let a stranger skip your SQL-injection protection on `admin-ajax.php` just by sending the right string. Scope on your own IP address instead, and remove the exception when the migration is finished.

1. In the Cloudflare dashboard, open your zone’s WAF managed rules (recent dashboards put this under **Security**; the exact menu labels have changed between dashboard versions).
2. Find the blocked request in your zone’s security events log and note which rules fired. In one customer report these were three SQLi rules — *SQLi – MultiLevel Function* and two *SQLi – String Function* rules. Yours may differ, so read your own event log rather than copying these.
3. Look up your current IP address (search “what is my IP”), then click **Add exception** and use an expression scoped to that address:

```
http.host eq "www.example.com"
and ip.src eq 203.0.113.45
and http.request.method eq "POST"
and (
  http.request.uri.path eq "/wp-admin/admin-ajax.php"
  or http.request.uri.path contains "/wp-json/gk-foundation/v1/process-upload"
)
```

1. Set the exception to skip **only** the specific rules you identified in step 2 — not the whole ruleset.
2. Save, then run the export or import again.
3. **Delete the exception once the migration is done.** It is meant to be temporary.

Replace **example.com** with your own domain and **203.0.113.45** with your own IP address. If your IP changes (many home connections rotate daily), you will need to update the rule.

For GravityImport, swap the `process-upload` path for `/wp-json/gravityview/import/v1/`.

If a fixed IP is not workable — a whole office behind changing addresses, for example — then do not build a rule around a header instead. Disable the specific rule IDs that fired for the length of the migration and turn them back on immediately afterwards.

Which managed rulesets you get depends on your Cloudflare plan, so the rule names in your Security Events may not match the examples above. Whatever plan you are on, add a narrowly scoped exception rather than switching a ruleset off — turning off the Managed Ruleset removes protection for every visitor to your site, not just for your migration.

### Host-level firewalls (ModSecurity and similar)

You usually can’t change these yourself. Contact your hosting provider and give them:

- The **date and time** of the failure, and **your own IP address**.
- The **URL** that was blocked (`/wp-admin/admin-ajax.php`, or the `/wp-json/` path from the table above).
- A request to **allowlist that path for your IP address**, or to disable the specific rule IDs their log shows firing — and to revert the change once your migration is finished.

Ask for the exception to be scoped to your IP, not to “logged-in administrators”. At the firewall layer there is no way to tell a real administrator from anyone who sends a WordPress-looking cookie, so a login-based rule is not the protection it sounds like.

Most hosts can find the blocked request in their logs from the timestamp alone and will make a targeted rule change.

### Security plugins (Wordfence, NinjaFirewall, Sucuri, MalCare)

Security plugins that inspect POST data can reject these requests for the same reason a WAF does. Check the plugin’s blocked-traffic log first to confirm it is the one blocking you, then either:

- **Allowlist the URL and action** from the table above, using the plugin’s own allowlist setting. This is the targeted option and the one to prefer.
- **Or run the firewall in learning mode** for a single import or export run. Be aware this stops the firewall blocking anything, for every visitor, for as long as it is on — which on a large migration can be hours. Switch it back to fully enabled the moment the run finishes.

See your plugin’s own documentation for where these settings live — [Wordfence’s firewall documentation](https://www.wordfence.com/help/firewall/) covers allowlisting and learning mode.

One note on Wordfence: with Extended Protection enabled, the firewall inspects requests before WordPress loads, so it can block something a WordPress-level rule would have allowed. Allowlisting is still done in the Wordfence dashboard as normal — you only need your host if Extended Protection itself has to be installed or removed.

## Step 4: Confirm it worked

Run the export or import again and watch the Network tab. The request that previously returned 403 should now go through. Don’t stop at the status code — a 200 only means the firewall let the request past, and our plugins can still return an error message inside a 200 response. Confirm the export or import actually reaches completion in the UI. Once the migration is finished, remove the exception you added.

## Still stuck?

[Contact GravityKit support](https://www.gravitykit.com/support/) and include:

- Which product and version you’re using.
- The exact error message or a screenshot.
- Your Cloudflare Ray ID, or the firewall log entry for the blocked request.
- The name of your host and any security plugins you have active.

## Related articles

- [Troubleshooting 403 errors in GravityBoard](https://www.gravitykit.com/docs/gravityboard/403-errors-in-gravityboard/)
- [Allowing GravityKit license checks through your firewall](https://www.gravitykit.com/docs/general-help/allowing-gravitykit-license-checks-through-your-firewall/) — for the opposite problem, where your server can’t reach GravityKit
- [Best practices to follow when moving data using GravityMigrate](https://www.gravitykit.com/docs/gravitymigrate/best-practices-for-moving-data-using-gravitymigrate/)
- [Error: Server returned an empty response](https://www.gravitykit.com/docs/gravityimport/error-server-returned-an-empty-response/)