How to secure the wordpress search form?

First of all, SQL Injection is VERY common. Both WordPress programmers and plugin programmers need to be very defensive when formulating SQL requests, especially when parts come from user input or another table’s data. One slip-up on a popular plugin and, because of one-click update, thousands of blogs are vulnerable.

If all your form does is turn the search request into a URL like http://example.com/blog?s=search+term , then there’s nothing more you can do to your form to make it more or less vulnerable.

What happens to the s parameter? WordPress has code built-in to handle the s parameter, and many people inspect and test the WordPress core code for vulnerabilities. (See http://wordpress.org/development/category/security/ .) Indeed they catch some from time to time. C.f. WordPress 2.8.4.

Your favourite plugins don’t have this much attention.

Since WP’s architecture is very open and has dozens of hooks, your WordPress installation is only as secure as its least vulnerable plugin.

And I’m not only talking about search plugins, here, because plugins can say one thing and do another. Any plugin could be fetching the s parameter and be doing a lousy job and thus open you up to SQL injection attacks.

I’ve seen many plugins whose admin screens have absolutely zero defensive programming. I use some of them, actually, because I cross my fingers nobody gains admin access to my blog.

I hope this answers some questions.

After the commercial break, we’ll talk about cross-site scripting.

That, but mostly your site is edited with links so a certain website gets a high Google ranking, many visitors, etc. Perhaps these high-ranking sites have a virus to get to visitor’s computers, etc. It appears that hacking websites can be a profitable income.