Modsecurity.conf default rule requires missing JSON support

Keywords: WordPress - AWS - Technical issue - Other
I’m running Wordpress (bitnami-wordpress-5.6-0-linux-debian-10-x86_64-hvm-ebs) and I’ve followed the instructions to enable mod_security2 at

I also switched “SecRuleEngine” to “On” (from “DetectionOnly”), but now I’ve observed that some requests with JSON payloads are blocked:

Message: JSON support was not enabled
Message: Access denied with code 400 (phase 2). Match of "eq 0" against "REQBODY_ERROR" required. [file "/opt/bitnami/apache2/conf/modsecurity.conf"] [line "60"] [id "200002"] [msg "Failed to parse request body."] [data ""] [severity "CRITICAL"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client] ModSecurity: JSON support was not enabled [hostname ""] [uri "/wp-json/wp/v2/users/me"] [unique_id "YErTXwMN2m@ksfmR6tA7mAAATBI"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client] ModSecurity: Access denied with code 400 (phase 2). Match of "eq 0" against "REQBODY_ERROR" required. [file "/opt/bitnami/apache2/conf/modsecurity.conf"] [line "60"] [id "200002"] [msg "Failed to parse request body."] [data ""] [severity "CRITICAL"] [hostname ""] [uri "/wp-json/wp/v2/users/me"] [unique_id "YErTXwMN2m@ksfmR6tA7mAAATBI"]

The rule that is causing this was provided by the Bitnami installation:

# Enable JSON request body parser.
# Initiate JSON Processor in case of JSON content-type; change accordingly
# if your application does not use 'application/json'
SecRule REQUEST_HEADERS:Content-Type "application/json" \

I’ve found another issue that indicates:

I’m sorry but we do not build mod_security with the “with-yajl” option to enable json support.

If that’s still true (and it appears to be), then it’s strange that the default configuration has a rule that requires this support to be compiled in.

Hi @etetech,

Thanks for using Bitnami. Can you give us more information to try to reproduce your issue? Can you provide us with some more context to better understand it?


Hi @gongomgra, sure!

  1. Launch EC2 instance using “WordPress Certified by Bitnami and Automattic” image (currently “5.7-2 on Debian 10”).
  2. Enable mod_security2 using the official instructions (“Approach B”).
  3. Also, edit /opt/bitnami/apache2/conf/modsecurity.conf to contain SecRuleEngine On and restart Apache.
  4. Enable the JavaScript REST API client as described in the official instructions, and make some API request that sends JSON in the request body. I use the Code Snippets plugin:
add_action( 'wp_head', function () {
	wp_enqueue_script( 'wp-api' );
	wp_add_inline_script( 'wp-api', 'wp.api.loadPromise.done( function() { new wp.api.models.UsersMe().save({name: "Test User"}); } )' );
} );
  1. Load the above page, and observe that:
  2. The request fails with 400 Bad Request.
  3. /opt/bitnami/apache2/logs/error_log contains:
[Sun Apr 25 17:38:45.257292 2021] [:error] [pid 9785:tid 140290945971968] [client] [client] ModSecurity: JSON support was not enabled [hostname ""] [uri "/wp-json/wp/v2/users/me"] [unique_id "YIWpJRpdVCd3VCZaXqJsFQAAABU"], referer:
[Sun Apr 25 17:38:45.257344 2021] [:error] [pid 9785:tid 140290945971968] [client] [client] ModSecurity: Access denied with code 400 (phase 2). Match of "eq 0" against "REQBODY_ERROR" required. [file "/opt/bitnami/apache2/conf/modsecurity.conf"] [line "60"] [id "200002"] [msg "Failed to parse request body."] [data ""] [severity "CRITICAL"] [hostname ""] [uri "/wp-json/wp/v2/users/me"] [unique_id "YIWpJRpdVCd3VCZaXqJsFQAAABU"], referer:
  1. The request is also logged in /var/log/modsec_audit.log.

Hi @etetech,

Thanks for the info. I have a more clear understanding on this issue. You are right, and we are not building modsecurity with the JSON support enabled, but we are using the modsecurity-recommend.conf file from upstream, where this option must be present. I think you would need to build it as explained in the official docs linked in the other thread to be able to use them.

Is it possible to make the default modsecurity configuration supplied by Bitnami consistent by either:

  1. Build with JSON support, or
  2. Remove/comment the offending rule.

This would be nice for users like me who are adding modsecurity to an existing Bitnami Wordpress site that has plugins/code using the REST API.

Hi @etetech,

I think the default configuration is correct for most of the use cases, in which JSON support is not needed. According to the config file, the DetectionOnly default value is a good starting point in most of the scenarios

# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
SecRuleEngine DetectionOnly

Unfortunately, at this moment you would need to build modsecurity with JSON support. We will evaluate adding it to our builds, but we can’t ensure you if it will be added or not, not how much time we may need to do so.

In the meantime, you would need to build modsecurity on your side.

Hi gongomgra and thank you for the explanation!

Are there any plans to add json support for mod security to the bitnami stack? If not, do you happen to have a documentation page that explains the recommended way of doing it?


Hi @mickey3,

Thanks for your message. Unfortunately not, we haven’t added the json support to modsecurity yet. You will need to follow the official ModSecurity guide to manually build it on your server

Got you. Hopefully you’ll be able to support it soon – anyone using WP headless, or any other bitnami stack as a REST server will need it.

Anyways, thanks for the quick reply :+1:

Hi @mickey3,

Thanks for the info. We will post any update we have.


I’m now seeing that the bitnami-wordpress-5.7.2-8-r02-linux-debian-10-x86_64-hvm-ebs-nami-7d426cb7-9522-4dd7-a56b-55dd8cc1c8d0 image ships with mod_security3, which apparently includes JSON support, so the original issue I reported is resolved.

However, I was surprised to learn the Apache connector for ModSecurity 3 has its own bugs / feature gags, and is declared to be still be unstable. From #77:

The reason why this project was not yet released is because it is still missing code. It does not work as expected, yet.

See also #80 - Future plans? and from #81:

Apache version for 3.0 is not yet ready for production. Please use the version 2.x

So, now we have to build ModSecurity 2.x ourselves to use the officially supported version?

Hi @etetech,

Thanks for your message. Our engineering team is evaluating this thread and we will post more information when we have any update.

In the meantime, please build ModSecurity 2.x manually.

Best regards,