Blocking spambots from Search form

Question

I have a problem with spambots abusing my site's 'search' function but I suspect they aren't actually visiting my site and manually typing their crap into our search input.

I've not found a great solution yet, but with cobbling together a few things I’m getting closer and could use a little bit of help to see if I can do better.

Currently I'm using the PerishablePress ultimate bot blocking list in my .htaccess file, but I still see a TON of bot traffic in my search logs, it looks like this:

SO I added some javascript to block all special characters, and changed my search query parameter so it's no longer "s" or "search_query" or "search"....but it hasn't worked because those methods rely on the spammer actually using my search form.

Ideally what I would like is to stop ALL external traffic from accessing the search function, so that they MUST be on my site to perform a search, I feel that I can better control the form if they cannot access the function directly but have to come use the input field to do a search.

Is there any way to entirely block any URL that has /?s= or any external access to core WP functions without coming FROM my domain/site? Or any other suggestions I can try? I'm trying to do this without adding a plugin, we already use a ton of plugins and Google keeps telling me to reduce plugins to speed up the site, I'm doing a very delicate balancing act between speed and functionality so I'd prefer a simpler solution than yet another plugin if possible.

Answer 1

You need to modify the code that processes the search to sense and block invalid attempts.

You could do this by looking for a valid session number, or even a session variable that is created by the page that contains the search form. You might also try a hidden field for the search form, although that is not always effective. (There are automated ways to 'read' a form and get the field names and the submit page. And then there are 'headless browsers' that can simulate a browser request.)

I've had some success with some JS code that changes the form's 'action' value after a delay that is initiated with a 'focus' or 'click' event on the search form field. But there are ways for even a 'headless browser' to process JS code.

It takes a bit of effort for a spammer to customize an 'attack' on any form. So some basic precautions as noted above might give you three or four 'nines' (99.9%) protection, although perhaps not foolproof.

Blocking by IP address is not usually effective, as it is easy to use a VPN to change an IP address. And there are add-ins for headless browsers that know about IP blocking lists.

Answer 2

Here is what I wound up doing that seems to be working (for now!), it's a combination of two changes;

1. Adding some code that prevents special characters from being typed into the search form's input field; and
2. Changing the search parameter to something other than the default 's' (which is working at the moment to prevent direct URL access to the WP search function).

Change #1: I added this javascript to my searchform.php template file (it could also go into my Child Theme's functions.php or a custom plugin, this was just the simplest way to add it at the moment, I may move it later):

jQuery(function($){
    //Prevent any special characters in form fields with this CSS class name
    $( '.char-restrict' ).on( 'keypress', function(e){
        var regex = new RegExp("^[0-9a-zA-Z \b]+$");
        var key = String.fromCharCode(!event.charCode ? event.which: event.charCode);
        if (!regex.test(key))
            {
                alert ( "Special characters are not allowed in this field" ); // Put any message here
                event.preventDefault();
                return false;
            }
    });
    //Prevent any paste features in form fields with this CSS class name
    $( '.char-restrict' ).bind( 'copy paste', function (e) {
        var regex = new RegExp( "@" );
        var key = String.fromCharCode(!event.charCode ? event.which : event.charCode);
        if (!regex.test(key)) {
            alert ( "Pasting feature has been disabled for this field" ); // Put any message here
            e.preventDefault();
            return false;
        }
    });
});

NOTE THAT for this to work you need to add the CSS class to the search form's input field, in this case I used .char-restrict, you can make your CSS class whatever you want as long as it matches between the input and your script.

I found the above code at this great tutorial: https://wpforms.com/developers/how-to-restrict-special-characters-from-a-form-field/

Change #2: I added the code below to my Child Theme's functions.php file to change the search parameter as all of the spam searches were accessing search directly using URLs with /?s= in them.....when you change the 's' to be something else, they fail (bwahahahah!).

  // Change search query parameter to try to stop search spambots
add_filter('init', function(){
global $wp;
    if (!is_admin()){
$wp->add_query_var( 'mynewsearch_query' );
$wp->remove_query_var( 's' );
}
} );
add_filter( 'request', function( $request ){
if ( isset( $_REQUEST['mynewsearch_query'] ) ){
    $request['s'] = $_REQUEST['mynewsearch_query'];
}
return $request;
} );

I found this code at this great tutorial: https://searchwp.com/v3/docs/kb/how-to-change-your-search-query-parameter-from-s-to-something-else/

NOTES:

1. I added the "if (!is_admin())" statement so it will not impact back-end Admin searches which I do frequently, my version only impacts front-end and direct access searches.
2. "mynewsearch_query" is not what I used, I don't want to reveal that here because then someone could use that to once again direct access and spam my search, LOL.....make up your own query parameter name and use that or just use my example as is.

SINCE I implemented these two changes I've had ZERO spam searches.

BUT A HUGE thank you to Rick for his answer above, my next step will be to use his suggestion of a session variable that must exist to access the search input field, this will ensure that only site visitors can use my site search (no direct access) - it's a brilliant solution that I look forward to figuring out.