Inline CSS Style Returns 403 Error


I have run into an issue where a 403 error is thrown when a page is edited and includes an inline CSS style such as

or . These CSS rules were written by concrete, not added manually.

403 error Forbidden The page you were looking for: /concretest856/index.php/ccm/system/dialogs/block/edit/submit?ccm_token=1654889136:9e921a8e8e94cc7afda9ed2fbebdf3d5&cID=296&arHandle=Main&bID=680 is not a page you are supposed to be looking at!

Not sure if this just happened or my client just discovered it.

Using Neat theme, with CSS added via concrete, but no code modifications. Tried changing to untouched Elemental theme with same result. Tried downgrading PHP from 7.4 to 7.0 and 5.6, same result.

Can anyone help with this issue?

thank you, Chuck

Environment Information

concrete5 Version

Core Version - 8.5.6
Version Installed - 8.5.6
Database Version - 20210622145600

Database Information

Version: 5.7.38
SQL Mode:

concrete5 Packages

Cloneamental (0.9.3), Neat (0.9.2), oh_love (1.0.0), Replica Theme (1.1.0), Stucco (2.1.6), Supermint Theme (

concrete5 Overrides


concrete5 Cache Settings

Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).

Server Software


Server API


PHP Version


PHP Extensions

bcmath, bz2, calendar, cgi-fcgi, Core, ctype, curl, date, dom, enchant, exif, fileinfo, filter, ftp, gd, gettext, hash, i360, iconv, imagick, imap, intl, ionCube Loader, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_pgsql, pgsql, Phar, posix, pspell, readline, Reflection, session, SimpleXML, snmp, soap, sockets, SPL, standard, tidy, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib

PHP Settings

max_execution_time - 120
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 120
max_input_vars - 1000
memory_limit - 128M
post_max_size - 64M
upload_max_filesize - 64M
ic24.api.max_timeout - 7
mbstring.regex_retry_limit - 1000000
mbstring.regex_stack_limit - 100000
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
pgsql.max_links - Unlimited
pgsql.max_persistent - Unlimited
session.cache_limiter - no value
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
unserialize_max_depth - 4096

This is likely to be a thing called ‘Mod Security’ on your server, blocking what it detects to be a malicious POST to the server, with it being a false positive. Normally Mod Security just works to block obvious/common hacking attempts, but sometimes it’ll block things that you don’t want it to. It’s not really a Concrete issue.

What you would do is contact your host:

  • trigger the error and take note of when you triggered the block
  • contact your host, and ask them to check the Mod Security logs around the time you triggered the block. You can also send them through the URL where it’s returning the 403 response.
  • ask them to whitelist any rules that appear to be triggered

Some cPanel setups have a page where you can turn on and off ModSecurity, but it’s better to leave it on and whitelist specific rules.

Thank you for the reply.
Yes, it is ModSecurity. Unfortunately my web host refuses to whitelist any rules.

I am the only person who has this issue? I would think most everyone using an older version of concrete would have the same issue if it is ModSecurity.

So I have contacted my web host, they said it is ModSecurity and nothing they are willing to do about it. I just updated to v9.1.1 and still have the same issue. Moved the site to another server (same host company) and have the same issue. I am lost. Can anyone help?

Turn it off in your htaccess file with this code

<IfModule mod_security.c>
  SecFilterEngine Off
  SecFilterScanPOST Off

Yes, turning off ModSecurity works, but does not seem to me to be the proper fix for this issue. From what I read, that is not the proper thing to do. Is this what everyone has to do these days?

Your host is in the wrong here. Every good host I’ve worked with will happily whitelist modsec rules if they can tell it’s false positive. I’d say find a better host, there’s no workaround besides turning it off or whitelisting.

We do have a couple of hosting partners here:
Web Hosting for Concrete CMS