Normally, when visitors post a comment to your site, specific types of client data are associated with the request. Commonly, a client will provide a user agent, a referrer, and a host header. When any of these variables is absent, there is good reason to suspect foul play. For example, virtually all browsers provide some sort of user-agent name to identify themselves. Conversely, malicious scripts directly posting spam and other payloads to your site frequently operate without specifying a user agent. In the Ultimate User-Agent Blacklist, we account for the “no-user-agent” case in the very first directive, preventing a host of anonymous visitors from hitting the site.

In addition to empty user-agent strings, malicious requests for site content frequently fail to provide any referrer information. Unless special privacy software is being used, the web page from which a visitor has arrived at your site will be specified in the header information for that request. Likewise, when a visitor posts a comment at your site, the referrer string for that post request will be the URL of that particular page. Thus, as with blank user-agent requests, no-referrer requests are frequently indicative of spam and other malicious behavior.

Another important piece of information provided by all legitimate clients is the host request header. The host header specifies the Internet host and port number of the requested resource. This information is required for all clients making HTTP/1.1 requests. Thus, requiring the host request-header field for all posts to your site safely eliminates illicit requests from hitting your server.

By targeting these three circumstances — blank user agents, empty referrers, and missing host headers — we can greatly improve the overall security of our WordPress-powered sites. Our weapon of choice to forge this server-side strategy is custom set of HTAccess (or httpd.conf) directives:

# WORDPRESS POST SECURITY
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{REQUEST_METHOD}  POST
 RewriteCond %{HTTP_REFERER}    !.*perishablepress\.com [NC]
 RewriteCond %{REQUEST_URI}     !.*(wp\-login|wp\-admin|wp\-content|wp\-includes|wp\-trackback).* [NC]
 RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR]
 RewriteCond %{HTTP_REFERER}    ^-?$ [OR]
 RewriteCond %{HTTP_HOST}       ^-?$
 RewriteRule ^(.*)$ - [F,L]
</IfModule>

To implement this HTAccess strategy, replace the domain from “perishablepress.com” to the name of the domain on which these directives operate. To allow multiple domains, replicate the second directive as follows:

RewriteCond %{HTTP_REFERER} !.*domain-01\.tld [NC]
RewriteCond %{HTTP_REFERER} !.*domain-02\.tld [NC]
RewriteCond %{HTTP_REFERER} !.*domain-03\.tld [NC]

After specifying the correct domain information, simply place the code into your site’s root HTAccess file and test for proper functionality. The code itself should be clear, but if something needs explained, please drop a comment and I will do my best to break it on down. And finally, a few obligatory disclaimers:

• This code works on my server. I can’t guarantee that it will work on yours.
• Blocking blank user agents may prevent a small percentage of legitimate posts.
• Blocking empty referrers may prevent a small percentage of legitimate posts.

While this security technique won’t stop all of the bad guys, it will certainly help keep out some of the more obvious offenders. Protecting your site against malicious post requests is an important part of any serious security strategy. Thanks to the magical powers of Apache’s HTAccess directives, we now have a method to secure visitor posting to your WordPress-powered site.

Related articles

• Block Spam by Denying Access to No-Referrer Requests
• Protect WordPress Against Malicious URL Requests
• Controlling Proxy Access with HTAccess
• 4G Series: The Ultimate Referrer Blacklist, Featuring Over 8000 Banned Referrers
• Perishable Press HTAccess Spring Cleaning, Part 2
• Eight Ways to Blacklist with Apache’s mod_rewrite
• Invite Only: Visitor Exclusivity via the Opt-In Method