Tainacan batch file uploads fail with 403 Forbidden

I’m running WordPress 6.8 with the latest Tainacan. When I drag & drop files into a Tainacan collection, the item record is created but the actual file upload always fails:

  • A POST is sent to
    https://…/wp-json/wp/v2/media/?post=<ID>
  • The response is 403 Forbidden.
  • A draft item is created in Tainacan (the POST succeeds in creating a draft), but the files never attach.
  • Note: Uploading the same files via Media → Add New works fine.

There are no related entries in wp-content/debug.log and my .htaccess contains only the default WordPress rules. How can I allow Tainacan’s uploader to successfully POST without triggering a 403?

Hi @sergi welcome to our forum!

I’m afraid this will be something related to your server settings. My first attempt would be to check if file upload permissions are ok in a more generic way. Try reaching to the WordPress Media Gallery and upload the same files. Are they being accepted or is there any limitation (file size or format, for example). But I’ve seen situations where the file upload via REST API (which is what the Batch upload screen does) being blocked… would you have any security plugin that might block that?

Hi @mateus.m.luna, thanks for the quick reply.

I just tested uploading the exact same files via **Media ** in the WordPress gallery, and they all upload perfectly—no size or format issues.

I’ve also attached a screenshot of my Tainacan → System Diagnostics page.

For completeness: I did have Wordfence installed, but I’ve completely uninstalled it and wiped its data; the 403 error when posting to /wp-json/wp/v2/media/ still persists.

At this point it really feels like a server-level block on the REST endpoint. Do you have any pointers for how to whitelist or debug that on server side (or similar)? Thanks!

@sergi then we would need to investigate more… I’m not an expert on this but my first request would be to take a look at the request POST headers… can you see the content in the ‘X-WP-Nonce’ header attribute? And maybe ‘Content-disposition’? Do you notice any difference of behavior between browsers? Have tried uploading not multiple files but only one (also via the bulk edition form, but only one file).

Hi @mateus.m.luna, thanks for the follow-up.

I’ve actually pinpointed the cause: ModSecurity’s SQL-Injection rules are flagging the binary payloads as attacks (rules 942100 and 949110). I attempted to disable those rules via my .htaccess, but that change causes an Internal Server Error—apparently SecRuleRemoveById isn’t allowed in per-directory files on my host.

Do you have any suggestions for how to proceed? Thanks again!

Thanks for pinpointing that… it is actually very hard to understand the origin of this sort of error due to the variety of server settings out there.

Are you allowed to perform changes in your Apache (or nGinx) settings other than via .htaccess? I was hoping that maybe we can whitelist that rule only for the WordPress media endpoint…

If not it might really be something that you won’t be able to achieve without reaching directly to your host provider.

From our side I’ve read that we could try sending the file in other ways, maybe converting to base64 but that would imply using an alternative endpoint instead of the WP default one and it is not something we have plans by now.

An alternative path for you in particular could be to upload your files to an FTP or any other online public storage and perform a CSV import flow… I know it is not ideal but should work without any restrictions.