#36837 closed defect (bug) (invalid)
<script> tags in Admin Options page input field triggering mod_security
Reported by: | maddogprod | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.5.2 |
Component: | Administration | Keywords: | |
Focuses: | administration | Cc: |
Description
I have a site with a custom admin Options page. There are three fields and it's a simple form that submits to options.php. One of the inputs is to include Google AdWords Conversion code. For at least a year it's worked fine on 100+ mini-sites. With the latest updates to 4.5x we ran into a problem. When we submitted this options page we went to a 404 Error saying "options.php can not be found."
The site host found that it triggered mod_security beause it includes <script> tags. They disabled that mod_security rule and it works fine.
The problem is there are over 100 sites using this theme or variations that include this. Testing them, if I get rid of the <script> tags in that field it updates and works fine. Add the Conversion Code (or even one <script> tag) and it triggers mod_security with the same problem.
The site host swears the mod_security rules haven't changed in years. So it appears that one of the WP 4.5x updates probably affected it. I can't pinpoint which one since they were updated to 4.5.2 before the problem was discovered.
In searching I can't find any mention of this problem from other people but again, it worked for a year and suddenly doesn't on any of the sites.
Hey @maddogprod,
Unfortunately there really isn't anything we can do about this - and it certainly isn't something we should attempt to work around in WordPress.
mod_security
rules are often trigger-happy, as they are in this case, and it sounds like it's probably being triggered by the presence of<script>
in any data sent to the server.Although the host says nothing has changed, very little has changed in WordPress as well - and definitely nothing of substance that would cause us to suddenly start triggering such a rule.
The only suggestion I can offer you, is to use a plugin/shortcode instead to add the tracking data, so that you aren't required to add the
<script>
tags in the input, and only have to specify a tracking ID.