wpforms: Error loading block: the response is not a valid JSON response

Home Forums BulletProof Security Free wpforms: Error loading block: the response is not a valid JSON response

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #43341


    I’ve recently noticed that on a couple of client websites where I have Bulletproof Security Free installed, when editing the contact page – this error is displayed in the block where the contact form should be displayed:

    Error loading block: the response is not a valid JSON response

    Checking the security error log reveals this:

    [403 GET Request: December 12, 2023 3:37 pm]
    BPS: 6.9
    WP: 6.4.2
    Event Code: WPADMIN-SBR
    Solution: https://forum.ait-pro.com/forums/topic/security-log-event-codes/
    REMOTE_ADDR: GDPR Compliance On
    Host Name: b0fb6ae1.bb.sky.com
    HTTP_CLIENT_IP: GDPR Compliance On
    HTTP_FORWARDED: GDPR Compliance On
    HTTP_REFERER: https://mydomain.co.uk/wp-admin/post.php?post=153&action=edit
    REQUEST_URI: /wp-json/wp/v2/block-renderer/wpforms/form-selector?context=edit&attributes%5BclientId%5D=&attributes%5BformId%5D=832&attributes%5BdisplayTitle%5D=false&attributes%5BdisplayDesc%5D=false&attributes%5BfieldSize%5D=medium&attributes%5BfieldBorderRadius%5D=3px&attributes%5BfieldBackgroundColor%5D=%23ffffff&attributes%5BfieldBorderColor%5D=rgba(%200%2C%200%2C%200%2C%200.25%20)&attributes%5BfieldTextColor%5D=rgba(%200%2C%200%2C%200%2C%200.7%20)&attributes%5BlabelSize%5D=medium&attributes%5BlabelColor%5D=rgba(%200%2C%200%2C%200%2C%200.85%20)&attributes%5BlabelSublabelColor%5D=rgba(%200%2C%200%2C%200%2C%200.55%20)&attributes%5BlabelErrorColor%5D=%23d63637&attributes%5BbuttonSize%5D=medium&attributes%5BbuttonBorderRadius%5D=3px&attributes%5BbuttonBackgroundColor%5D=%23066aab&attributes%5BbuttonTextColor%5D=%23ffffff&post_id=153&_locale=user
    QUERY_STRING: context=edit&attributes%5BclientId%5D=&attributes%5BformId%5D=832&attributes%5BdisplayTitle%5D=false&attributes%5BdisplayDesc%5D=false&attributes%5BfieldSize%5D=medium&attributes%5BfieldBorderRadius%5D=3px&attributes%5BfieldBackgroundColor%5D=%23ffffff&attributes%5BfieldBorderColor%5D=rgba(%200%2C%200%2C%200%2C%200.25%20)&attributes%5BfieldTextColor%5D=rgba(%200%2C%200%2C%200%2C%200.7%20)&attributes%5BlabelSize%5D=medium&attributes%5BlabelColor%5D=rgba(%200%2C%200%2C%200%2C%200.85%20)&attributes%5BlabelSublabelColor%5D=rgba(%200%2C%200%2C%200%2C%200.55%20)&attributes%5BlabelErrorColor%5D=%23d63637&attributes%5BbuttonSize%5D=medium&attributes%5BbuttonBorderRadius%5D=3px&attributes%5BbuttonBackgroundColor%5D=%23066aab&attributes%5BbuttonTextColor%5D=%23ffffff&post_id=153&_locale=user
    HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0

    The form submission still works on the front end, it appears to just be editing the page when it tries to display the block. It means that no other (wpforms) forms can be added to any pages.

    Can you suggest a fix for this?

    (I’d add that other websites that use Forminator don’t exhibit this behaviour – although I do use BPS Pro on those sites.
    I’d also highlight that he sites with Forminator installed haven’t succumbed to the vast amount of spam received via the wpforms plugin. WPForms is very easy to use and provides an attractive output – although the free version is limited in scope. Perhaps I should change over the other sites at some point to an alternative contact form such as Forminator or Fluent perhaps?)

    Thanking you in advance anyway and wishing you a very Merry Christmas!

    AITpro Admin

    Add this wp-admin Custom Code file skip/bypass rule to this wp-admin Custom Code text box: 3. CUSTOM CODE WPADMIN PLUGIN/FILE SKIP RULES
    Click the Save wp-admin Custom Code button.
    Run the BPS Pre-Installation Wizard and Setup Wizard. If you have BPS free then just run the Setup Wizard.

    # wpforms skip/bypass rule for the admin-ajax.php file and post.php file
    RewriteCond %{REQUEST_URI} (admin-ajax\.php|post\.php) [NC]
    RewriteRule . - [S=2]

    Hi – thanks for the quick response – but this didn’t work I’m afraid.

    I tested and noticed than when I disable the root htaccess file then the issue goes away and the wpforms block in the page edit screen renders? I assume there’s something in there that is restricting this wpforms call?

    Thanks again

    AITpro Admin

    Yes, you are correct.  There are several additional things in that Query String that are being blocked in the Root htaccess file.  Will figure this out later today.


    Hello – you’ve always provided excellent support and clearly nothing has changed.

    I very much appreciate your time and effort – I’m sure that it will help others who are experiencing the same issue also.

    As mentioned, I may abandon WPForms anyway – I’ve never experienced as many spam form entries as I do with this plugin. But until I transition those client sites away, a fix will be welcome.

    Thank again for your time.

    AITpro Admin

    I would do this now, but running late this morning for my day job. Will get to this around 5pm today.

    AITpro Admin

    Here is the fix for the Root htaccess file. You will also still need to use the wp-admin htaccess file fix.

    1. Copy the modified BPS Query String Exploits below to this BPS Root Custom Code text box: 12. CUSTOM CODE BPSQSE BPS QUERY STRING EXPLOITS
    2. Click the Save Root Custom Code button.
    3. Go to the BPS Pro Setup Wizard page and run the Pre-Installation Wizard and Setup Wizard again.

    # The libwww-perl User Agent is forbidden - Many bad bots use libwww-perl modules, but some good bots use it too.
    # Good sites such as W3C use it for their W3C-LinkChecker. 
    # Use BPS Custom Code to add or remove user agents temporarily or permanently from the 
    # User Agent filters directly below or to modify/edit/change any of the other security code rules below.
    RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
    RewriteCond %{THE_REQUEST} (\?|\*|%2a)+(%20+|\\s+|%20+\\s+|\\s+%20+|\\s+%20+\\s+)(http|https)(:/|/) [NC,OR]
    RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
    RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]
    RewriteCond %{THE_REQUEST} (%0A|%0D|\\r|\\n) [NC,OR]
    RewriteCond %{REQUEST_URI} owssvr\.dll [NC,OR]
    RewriteCond %{HTTP_REFERER} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
    RewriteCond %{HTTP_REFERER} \.opendirviewer\. [NC,OR]
    RewriteCond %{HTTP_REFERER} users\.skynet\.be.* [NC,OR]
    RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(http|https):// [NC,OR]
    RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [NC,OR]
    RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]
    RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]
    RewriteCond %{QUERY_STRING} (\.\./|%2e%2e%2f|%2e%2e/|\.\.%2f|%2e\.%2f|%2e\./|\.%2e%2f|\.%2e/) [NC,OR]
    RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
    RewriteCond %{QUERY_STRING} (http|https)\: [NC,OR] 
    RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
    RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
    RewriteCond %{QUERY_STRING} ^(.*)cPath=(http|https)://(.*)$ [NC,OR]
    RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
    RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
    RewriteCond %{QUERY_STRING} (\<|%3C).*embed.*(\>|%3E) [NC,OR]
    RewriteCond %{QUERY_STRING} (<|%3C)([^e]*e)+mbed.*(>|%3E) [NC,OR]
    RewriteCond %{QUERY_STRING} (\<|%3C).*object.*(\>|%3E) [NC,OR]
    RewriteCond %{QUERY_STRING} (<|%3C)([^o]*o)+bject.*(>|%3E) [NC,OR]
    RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
    RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR] 
    RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
    RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]
    RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
    RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
    #RewriteCond %{QUERY_STRING} ^.*(\(|\)|<|>|%3c|%3e).* [NC,OR]
    RewriteCond %{QUERY_STRING} ^.*(\x00|\x04|\x08|\x0d|\x1b|\x20|\x3c|\x3e|\x7f).* [NC,OR]
    RewriteCond %{QUERY_STRING} (\.{1,}/)+(motd|etc|bin) [NC,OR]
    RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
    RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
    RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
    RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
    RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]
    RewriteCond %{QUERY_STRING} \-[sdcr].*(allow_url_include|allow_url_fopen|safe_mode|disable_functions|auto_prepend_file) [NC,OR]
    RewriteCond %{QUERY_STRING} (;|<|>|'|"|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]
    RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
    RewriteRule ^(.*)$ - [F]


    That’s great – I can confirm that this fix has worked on both client sites running BPS Free and the form now displays in the edit page as expected.

    Thank you again for your efforts – and best wishes to you and your family for Christmas and the New year.


    Hello again

    Sorry to have to re-visit this issue, however, I’ve discovered that whilst the WPForms contact form now shows up in the edit page window…if the view/edit mode is changed to tablet or mobile then the same error occurs –

    Error loading block: the response is not a valid JSON response

    Just when you thought that you’d seen the back of that…sorry

    AITpro Admin

    I would need to see a Security Log entry for that.  In general, the BPS htaccess code would not block JSON responses.  What is being blocked are the unsafe code characters used in the Query string. Also this could be a cache problem if you are using JS minification in a caching plugin, which is a very common problem that is known to break JavaScript. Or maybe wpforms uses different code for mobile and tablets?

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.