Outdated Mod_Security Rule Set In Cs-Cart Docs?

as per the linked rule set here:

  • mod_security should be disabled; if you don’t want to disable it fully, configure it to work with CS-Cart as described in this file;

the customer rules in the mod_security.txt file seem to be outdated.
when trying to add them to cPanel at

Edit Custom ModSecurityâ„¢ Rules

page on my WHM/cPanel server I get the following error:

Error: The following rule did not have an ID: # Enable XML request body parser. # Initiate XML Processor in case of xml content-type # SecRule REQUEST_HEADERS:Content-Type "text/xml" \ "phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"

I really dislike having to disable this level of security on my site(s) and wonder if there is an updated version of the custom rule set for mod_security

This is the link rule set:

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

Enable ModSecurity, attaching it to every transaction. Use detection

only to start with, because that minimises the chances of post-installation


SecRuleEngine DetectionOnly

– Request body handling ---------------------------------------------------

Allow ModSecurity to access request bodies. If you don’t, ModSecurity

won’t be able to see any POST parameters, which opens a large security

hole for attackers to exploit.

SecRequestBodyAccess On

Enable XML request body parser.

Initiate XML Processor in case of xml content-type

SecRule REQUEST_HEADERS:Content-Type “text/xml”

Maximum request body size we will accept for buffering. If you support

file uploads then the value given on the first line has to be as large

as the largest file you are willing to accept. The second value refers

to the size of data, with files excluded. You want to keep that value as

low as practical.

SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

Store up to 128 KB of request body data in memory. When the multipart

parser reachers this limit, it will start using your hard disk for

storage. That is slow, but unavoidable.

SecRequestBodyInMemoryLimit 131072

What do do if the request body size is above our configured limit.

Keep in mind that this setting will automatically be set to ProcessPartial

when SecRuleEngine is set to DetectionOnly mode in order to minimize

disruptions when initially deploying ModSecurity.

SecRequestBodyLimitAction Reject

Verify that we’ve correctly processed the request body.

As a rule of thumb, when failing to process a request body

you should reject the request (when deployed in blocking mode)

or log a high-severity alert (when deployed in detection-only mode).

SecRule REQBODY_ERROR “!@eq 0”
“phase:2,t:none,log,deny,status:400,msg:‘Failed to parse request body.’,logdata:‘%{reqbody_error_msg}’,severity:2”

By default be strict with what we accept in the multipart/form-data

request body. If the rule below proves to be too strict for your

environment consider changing it to detection-only. You are encouraged

not to remove it altogether.

“phase:2,t:none,log,deny,status:44,msg:‘Multipart request body
failed strict validation:

Did we see anything that might be a boundary?

“phase:2,t:none,log,deny,status:44,msg:‘Multipart parser detected a possible unmatched boundary.’”

PCRE Tuning

We want to avoid a potential RegEx DoS condition

SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

Some internal errors will set flags in TX and we will need to look for these.

All of these are prefixed with “MSC_”. The following flags currently exist:

MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.

SecRule TX^MSC_/ “!@streq 0”
“phase:2,t:none,deny,msg:‘ModSecurity internal error flagged: %{MATCHED_VAR_NAME}’”

– Response body handling --------------------------------------------------

Allow ModSecurity to access response bodies.

You should have this directive enabled in order to identify errors

and data leakage issues.

Do keep in mind that enabling this directive does increases both

memory consumption and response latency.

SecResponseBodyAccess On

Which response MIME types do you want to inspect? You should adjust the

configuration below to catch documents but avoid static files

(e.g., images and archives).

SecResponseBodyMimeType text/plain text/html text/xml

Buffer response bodies of up to 512 KB in length.

SecResponseBodyLimit 524288

What happens when we encounter a response body larger than the configured

limit? By default, we process what we have and let the rest through.

That’s somewhat less secure, but does not break any legitimate pages.

SecResponseBodyLimitAction ProcessPartial

– Filesystem configuration ------------------------------------------------

The location where ModSecurity stores temporary files (for example, when

it needs to handle a file upload that is larger than the configured limit).

This default setting is chosen due to all systems have /tmp available however,

this is less than ideal. It is recommended that you specify a location that’s private.

SecTmpDir /tmp/

The location where ModSecurity will keep its persistent data. This default setting

is chosen due to all systems have /tmp available however, it

too should be updated to a place that other users can’t access.

SecDataDir /tmp/

– File uploads handling configuration -------------------------------------

The location where ModSecurity stores intercepted uploaded files. This

location must be private to ModSecurity. You don’t want other users on

the server to access the files, do you?

#SecUploadDir /opt/modsecurity/var/upload/

By default, only keep the files that were determined to be unusual

in some way (by an external inspection script). For this to work you

will also need at least one file inspection rule.

#SecUploadKeepFiles RelevantOnly

Uploaded files are by default created with permissions that do not allow

any other user to access them. You may need to relax that if you want to

interface ModSecurity to an external program (e.g., an anti-virus).

#SecUploadFileMode 0600

– Debug log configuration -------------------------------------------------

The default debug log configuration is to duplicate the error, warning

and notice messages from the error log.

#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3

– Audit log configuration -------------------------------------------------

Log the transactions that are marked by a rule, as well as those that

trigger a server error (determined by a 5xx or 4xx, excluding 404,

level response status codes).

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus “^(?:5|4(?!04))”

Log everything we know about a transaction.


Use a single file for logging. This is much easier to look at, but

assumes that you will use the audit log only ocassionally.

SecAuditLogType Serial
SecAuditLog /var/log/modsec_audit.log

Specify the path for concurrent audit logging.

#SecAuditLogStorageDir /opt/modsecurity/var/audit/

– Miscellaneous -----------------------------------------------------------

Use the most commonly used application/x-www-form-urlencoded parameter

separator. There’s probably only one application somewhere that uses

something else so don’t expect to change this value.

SecArgumentSeparator &

Settle on version 0 (zero) cookies, as that is what most applications

use. Using an incorrect cookie version may open your installation to

evasion attacks (against the rules that examine named cookies).

SecCookieFormat 0

turning on mod security locks me out of the server and gives a "Store Closed" page on the admin back end

error that triggers csf firewall

Failures: 3 (mod_security)

Interval: 300 seconds

Blocked: Permanent Block [LF_MODSEC]

ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "93"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "www.shop.xxxxxxx.com"] [uri "/xxxxxxx_admin.php"] [unique_id "Yi-MexkjvxreGrxVQoTBIQAAAFA"], referer:https://www.shop.xxxxxxx.com/xxxxxxx_admin.php?dispatch=auth.login_form&return_url=xxxxxxx_admin.php%3Fdispatch%3Dorders.manage

Add your ip to the csf allow list.

Add your ip to the csf allow list.

unfortunately IP changes regularly so this is not a viable or convenient option.
What really needs to happen is CS-Cart update their documentation

here is what I found out from the ModSecurity documentation
Reference Manual (v3.x) · SpiderLabs/ModSecurity Wiki · GitHub

seems we just need to add an id like id:60008, into the rules to bring it up to date.


Description: Assigns a unique ID to the rule or chain in which it appears. Starting with ModSecurity 2.7 this action is mandatory and must be numeric.

Action Group: Meta-data


SecRule &REQUEST_HEADERS:Host "@eq 0" "log,id:60008,severity:2,msg:'Request Missing a Host Header'"

	Note : The id action is required for all SecRule/SecAction directives as of v2.7.0

These are the reserved ranges:

  • 1–99,999: reserved for local (internal) use. Use as you see fit, but do not use this range for rules that are distributed to others

turns out that does not really solve the problem.

What you can do though is all traffic on your admin page or turn it off for that page as well

see here:

apache - how to add mod security exception - Stack Overflow

replace the "wp-admin" part with your actual CS-Cart admin page

this is still not a perfect solution but allows ModSecurity to be enabled on your server everywhere except your secretly renamed admin page

On cPanel/WHM, you can go to WHM > Modsecurity Tools > Rules List > Edit Rules, and paste the above code right into the textarea. Restart Apache to deploy the new rule. It works like a charm

SecRule REQUEST_URI "@beginsWith /YourAdminPageNameHere" "phase:1,id:12345,allow"