Support

You forgot the delimiters in your regular expressions.

Query Parameter: #^(id|catid|Itemid)$#

Query Content: #^-?[\d]+$#

That said, id is a VERY generic parameter which should not be restricted to just a plain integer. There are many valid cases where it has to be an array (cannot be expressed as a regular expression), or it might be a string etc. Please remember that Joomla components use input validation, so the URL examples you showed have zero chance of success. Not to mention that they are not even valid SQL Injection attempts, which is why the SQLiShield filter didn't stop them.

In short, I am telling you that if you set up a rule like this you will probably break what is not currently broken. Please don't come back asking why something doesn't work on your site if you've put such a generic rule in place. There's a reason we have never implemented such a feature in our software.

I am pretty sure you were typing something wrong. This does exactly what you asked me for:

It also does have side-effects which I already told you about: it blocks more than you bargained for, including Smart Search.

The reason you don't see it blocking you is either because the SEF extension you are using kicks in first and redirects to the canonical URL before Admin Tools has the chance to do anything with the request, or your IP is in one of the allow lists, or both.

Again, I very strongly recommend AGAINST using this kind of rule. This is trying to kill a mosquito by burning down your house with you in it.

You are pretty insistent on asking me how to shoot your feet, so I am telling you how to shoot your feet right off. Don't come crying later that you did shoot your feet off following my instructions – it's the expected outcome.

You can use a ! in front of the regex to negate its meaning.

Itemid can be numeric or empty. The RegEx will block a request with an empty Itemid which will cause a lot of issues.

limit, and start are supposed to be numeric for core Joomla! components and components using the Joomla! MVC to display a paginated view. Other components may have different interpretation of either or both request parameters.

You can't really have a rule like that with no side-effects. We looked into that. If it was possible, it would have been a feature of Admin Tools. That's what I keep repeating.

Also keep in mind that since you're using a SEF extension which kicks in before Admin Tools the rule you are creating will not take effect. I know which one you're using, and it has its own workaround for this kind of requests in core components (and some third party components which have an integration plugin, as far as I can understand). So, even if you have a working rule you might see no change to what that extension reports.