Wordfence blocks wp-graphql API calls when using JWT auth

Hi @skarck, thank-you for your detailed message and steps you’ve taken so far to track down the issue.

I do feel this may be down to a false-positive, and it’s to my understanding (not having a headless test environment myself) that a headless WordPress installation will still leave our admin interface available to you?

If so, Learning Mode could help allow any blocked actions and retain that information for allowing the operations seamlessly in future. From the Wordfence Dashboard click on Manage WAF. Then you will see Basic Firewall Options > Web Application Firewall Status. Change the option to Learning Mode. Now trigger the actions/pages that were causing issues. This will help Wordfence learn that these actions are normal and it will allow them in the future. After you have finished performing the actions, switch the WAF from Learning Mode back to Enabled and Protecting. Now test to see if these actions work correctly.

If that doesn’t work, I would expect these blocks and the reason for them to show in your Live Traffic feed. You could try checking this immediately after seeing the mesage in your screenshot, just to see whether you’re able to click on the Live Traffic entry to expand it, and select the “ADD PARAM TO FIREWALL ALLOWLIST” button.

Let me know if I’ve made any incorrect assumptions or those don’t seem to work for you.

Peter.

@wfpeter Thank you for getting back!

I tried the steps you suggested and set the firewall into learning mode.
The interesting thing is that, watching the live traffic, both API calls with and without JWT header show up with a status code of 200 in the Wordfence UI. Meaning that there is no UI to add the calls to the allowlist.

However, in curl / axios / insomnia api client the calls with the JWT header come back with a status code of 403 (but with the correct body).

So it seems that one part of WF thinks the request is fine (handing the call to wp-graphql which return the body) but another part is flagging it as malicious and adding the 403 status code.

Again, disabling Wordfence completely solves the issue so it doesn’t seem to be an issue with the server env, cdn or proxy.

• This reply was modified 1 year, 11 months ago by skarck.
• This reply was modified 1 year, 11 months ago by skarck.

Hi @skarck, thanks for the extra information.

It looks like it’s definitely not a WAF rule as disabling the firewall doesn’t fix the problem. It may be required to grab some error/debug logs as it’s unusual to see a 403 error, but not a Wordfence-branded block page body as the returned content.

Without the block page or Live Traffic confirmation of Wordfence’s involvement, those logs of Wordfence intervening or causing errors would be important to confirm the problem doesn’t originate from another plugin or another step in the journey obtaining the data.

Thanks again,
Peter.

Thanks again @wfpeter !

I tried to debug this further with no luck. No errors show up in my error logs.

I also just recreated the setup in a simple php-apache based docker environment locally. Only plugins are the ones stated above + ACF 6.0.6. As soon as I activate the Wordfence plugin the queries start return with a 403.

Also tried to disable basically all Wordfence features and removed the “extended protection” but the problem persists.

Let me know if I can help you reproduce the issue!

Hi @skarck, thanks for performing the extra tests and I’m sorry to see the problems are still occurring.

I would ideally require PHP/server error log files to be sent to wftest @ wordfence . com so that our developers could potentially spot a problem in Wordfence or elsewhere in your configuration that might be causing the 403s. Please include your forum username in the subject line so they’re easy to find and let me know here afterwards so I can take a look.

Thanks again,
Peter.

Hi @wfpeter, we are facing the same issue :/
Only disabling the plugin seems to make it works.
Any update on this?

Have a nice day