HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

Configuring mod_security

mod_security is an "application firewall" which is often installed by Linux-based web hosts.

It's a mixed blessing. By its very nature, it provides limitations on what web systems can do. So in some sense, it breaks standards-based behaviour of web servers. It does this though to raise security, by blocking what it perceives to be malicious server requests, and that's a good thing.

The problem we need to deal with is false-positives – i.e. mod_security thinks something is an attack, when it is in fact normal behaviour.

mod_security v1 could be disabled by a .htaccess file, but mod_security v2 cannot. mod_security is designed for use in enterprise environments, and the makers support it as such – but it is deployed by a lot of web hosts. This leads to an unfortunate problems of responsibility. The mod_security authors think that the people managing the servers have control over what runs on them. The web hosts just want to layer in some extra security, and often have little understanding of how mod_security works, or what systems their customer's will install. Therefore unfortunately users are sometimes stuck in the middle. Your web host has a responsibility to provide the service they advertise, so if ocPortal gets blocked, you have every right to insist that they unblock whatever is stopping it.

ocPortal itself contains its own inbuilt firewall, which also blocks many malicious requests. ocPortal is also built with proper data management APIs and internal layers so that most vulnerabilities aren't possible. This said, as long as mod_security is configured right, it is a good thing to have both.

It is not usually easy to know if mod_security is blocking you. You will usually see some kind of Apache error message, such as the very generic '500 Internal Server Error'/'402 Forbidden' message. mod_security does not explicitly state the problem so that hackers have less clues to why they are blocked. Apache error logs usually contain the full reason, however.

mod_security works by a rule set, and rules are typically given a unique identifying number. There are various rule sets out there. An official one is maintained, but also some organisations maintain their own rule sets for 'value add' within their own firewall products based around mod_security. What follows is an explanation of common false-positives that ocPortal can trigger…

300018 – URLs inside URLs

This rule blocks URLs being passed as parameters within URLs. ocPortal regularly does this when you need to be redirected back to where you were at when performing an action. For example, if you are logging in, it encodes where to redirect you back to via a URL parameter. The recommend page facility also uses it.

This only occurs if short URLs are not enabled, because the rule works by detecting .php, and it won't do this with short URLs.

We could probably work around this problem in ocPortal by encoding the parameter so that it no longer looks like a URL, but this would be messy and have to work across both Javascript and PHP within ocPortal, so the complexity cost is too high.

340007 / 340095 / 340113 / 340118 / 340128 / 340147 / 340148 / 340149 / 340157 / 340159 / 350147 / 350148 / 380006 / 380018 / 390708 / 390727 / 973331 – WYSIWYG editing, template editing and code editor

It is possible to get Javascript code into the WYSIWYG editor. This will then trigger this rule.

To workaround you could manually remove the code from the editor's source view, if the code was not intended to be there.

It is likely that there are rules out there that block the WYSIWYG editor completely, but IDs for these aren't known at this time.

340014 / 390904 – OcCLE

OcCLE has a virtual unix filesystem, and stores the current directory in a cookie. If you enter the "/etc" directory, this rule will think you are trying to hack into the server's real filesystem.

300076 / 340007 / 340011 / 340014 / 340016 / 340017 / 340021 / 340027 / 340029 / 340095 / 340118 / 340128 / 340131 / 340133 / 340144 / 340147 / 340148 / 340157 / 340164 / 350147 / 350148 / 380006 / 380018 / 380019 / 380020 / 380021 / 390709 / 390715 / 390801 / 390810 / 393449 – Code Editor

This occurs when using the code editor to edit php code. If you try and save code changes (by pressing the edit button at the bottom of the code editor) and you do not receive a confirmation pop-up message, then this is the most likely cause. Your browser development tools (network tab) will report this as a 403 or 500 error for http:// .

340016 / 340149 / 350147 / 350148 / 390707 – Translate/re-phrase the software

Using the Translate/re-phrase the software feature.

340095 – XML Import

Importing XML data via Admin Zone Tools XML data management > XML Import.

380800 – PHP Info

Using the Tools PHP Info feature.

340009 – Site options

Saving changes on Admin Zone Configuration Site options page.

950801 – Anything

This rule (not on by default) introduces the assumption that the site is running utf8, so validates lots of text against it. This is a very bad assumption – PHP doesn't even support utf8 by default.

Instead of disabling these rules, most issues can be avoided by the host removing the appropriate line from their configuration.

For hosts using mod_security v1, remove:


SecFilterScanPOST On
For hosts using mod_security v2, remove:


SecRequestBodyAccess On

mod_security has this off by default, but turning it on causes most of the problems because it probes into request data rather than just URLs (basically).

Do you have know additional IDs causing problems? Update this document with them.

There are no pages beneath this page

Expand: Discussion Discussion (2 posts)

CEDI change-log Post