Protecting your site from fuzzing: They break you while you sleep

Imagine a villain approaching your front door. Silently and deliberately, or with the speed of a machine gun, he begins inserting thousands of different keys, master keys, pieces of wire, matches, and other debris into the lock, pouring solutions of various acids and salts into the keyhole. He’s not angry, he’s not tired. He’s a robot. He’s simply looking for something that will make the lock give in, whether it’s a clever master key or sulfuric acid.

On the web, this is called fuzzing. Right now, thousands of bots are crawling your site, trying to find a forgotten site_old.zip archive, a .git folder, or an .env file with database passwords, or trying to inject an SQL query into one of your forms. For a hacker, this is the cheapest and most effective way to find a “backdoor entrance.” If you’re a website administrator and don’t have “god” rights over the server, and your goal is to make sure this bot breaks its iron teeth on your site, then this article is for you.

What is fuzzing? (We explain it in simple terms)

Fuzzing is a method of automated chaos. A fuzzer program (such as ffuf or dirsearch) takes a huge dictionary (tens of thousands of words) and starts inserting them into your website’s address bar, whether it’s a simple URL or a form address.

• «”Does it have an /admin folder?” — No.
• “What about /backup?” — No.
• “What about /wp-content/uploads/2023/db.sql?” — Yep, it does!

As soon as the fuzzer receives a response other than “404 Not Found,” the hacker pops the champagne. They’ve found something you didn’t intend to show them.

How your website is being hacked using fuzzing

Hackers use three main tactics:

1. Content Discovery (Meat Search): Iterates through file names. They search for backups, configuration files, error logs, and test scripts (test.php) that you or a developer left running.

Table 1: Examples of URLs the bot tries to find on the site

2. Parameter Fuzzing (Searching for holes in logic): Hidden commands are inserted into the address bar.

Table 2: Examples of query parameters that bots use to request your site.

3. Payload Fuzzing (via forms): The bot injects quotes, brackets, and code snippets into your input fields, hoping to trigger adatabase exceptionand force averbose errorthat leaks technical metadata.

Table 3: Form-Based Fuzzing (Anomalous Data Input)

Log Significance: Your “CCTV Camera”

It is worth noting that at the first line of defense — the server level — most fuzzing attacks are filtered out, and in 90% of cases, site administrators pay no attention to fuzzing at all. This is a task for system administrators and hosting support. Smart sysadmins monitor Apache and Nginx logs to track spikes in activity and nip them in the bud. The few remnants that do manage to penetrate the site are usually blocked by various security plugins that admins handle on a “set it and forget it” basis. However, malicious hackers never sleep, constantly devising new algorithms for their bots; relying solely on hosting support or something like Akismet is unwise. A site administrator must also take part in anti-fuzzing defense because, slowly but surely, a site can indeed be breached. What can a site admin do? While they may lack access to the server’s “black boxes,” they do have CMS logs and a hosting control panel, which also contains access logs and error logs.

Mitigation Methods: On-Site Defense

You cannot stop internet traffic from bad bots; they will bang on your doors and poke at every crack anyway, but you can make your site “unappetizing” for them.

• Hygiene is everything:Never, do you hear, never store site archives in root folders. Made a backup — downloaded it to your computer — deleted it from the server.
• Admin Masking:Change the standard login URL (e.g., /wp-admin) to something unique. 90% of fuzzers will simply fly right past, failing to find the standard “door.”
• Generic Errors:Configure your CMS to display simple errors. Instead of “SQL error on line 154 in file /var/www/user/db.php,” the user (and the hacker) should simply see: “Something went wrong.”
• Smart Plugins:Install security modules (Wordfence, iThemes). They can automatically ban IPs that request non-existent files too frequently.

Fuzzing Protection: Cloudflare — Your Front-Door Bouncer

If hosting and sysadmins are the police patrol cleaning up the consequences inside, thenCloudflare is a massive bouncer at the club entrance. It is your first line of defense. Its main beauty is that it catches fuzzers by the scruff of the neck while they are still on the street, not even letting them touch your server’s door. To prevent fuzzing from becoming a headache, your bouncer should use the full arsenal:

• WAF (Web Application Firewall):This is the “blacklist” of repeat offenders. Cloudflare knows the “handwriting” and faces of popular fuzzers. If a bot tries to slip typical exploit code for popular CMSs into a request, the bouncer simply turns them away without explanation.
• Rate Limiting (Entry Counter): A real fuzzer is often a machine gun firing thousands of requests per minute. Set a limit: if the same “visitor” knocks on the door more than 10-20 times a minute, the bouncer sends them to the ban list. This instantly cools the ardor of automated scripts trying to brute-force passwords or find hidden folders.
• Custom Firewall Rules (Personal APBs): Here you give the bouncer clear instructions on who not to let in under any circumstances. Create rules to block requests for sensitive files: if someone looks for .env, .git, .sql, or old backups like config.php.bak — an instant ban follows. A regular user has no business there.
• Security Level “High” and Managed Challenge: This is a sanity check. Suspicious characters are forced to solve a captcha or pass an invisible JavaScript test. Fuzzers are dumb bots; they don’t know how to solve logical tasks on the fly, so their attack simply chokes at the doorstep.
• Bot Fight Mode: The “robot hunting” mode. Cloudflare analyzes behavior: a human won’t check for /admin/, /backup/, and /dev/ folders in a single second. If a guest behaves like a robot — the bouncer puts up a concrete wall in front of them.
• IP Firewall and Geo-Blocking: Why let people into the club whom you didn’t invite? If your business is local and you see an attack from a country where you have no customers — just block that region. With one click, you cut off entire botnets.
• Origin Protection (Bolted Back Door): This is critically important. All of Cloudflare is useless if a hacker finds out your server’s “real” IP and bypasses the bouncer directly. To prevent this, configure your server (via .htaccess or Nginx config) to accept requests only from Cloudflare IP addresses. For everyone else, the server should play dead. This way, you guarantee that no fuzzer crawls through a window while the bouncer stands at the main entrance. Don’t forget, however, to whitelist yourself, as well as all content managers and editors of your site, otherwise the bouncer will toss you out by the scruff of your neck too.

Let’s say that most of these methods should be applied cautiously, as they affect traffic or site indexing. For example, you can set Rate Limiting so that Cloudflare kicks out Google bots responsible for indexing, and then you’ll be wondering why no one is visiting the site.

If the Site is NOT behind a CDN: One-on-One with the Threat

If your site faces the world with a “naked” IP address:

• Honeypots:Create a file named secret_passwords.txtand do not link to it anywhere. Anyone who attempts to open it is a 100% bot. Use plugins that will ban them for this instantly.
• Disable Directory Listing:Ensure that when accessing paths like:

/uploads/
/wp-content/uploads/
/images/
/pdf/

a list of files is not displayed.

• The.htaccessfile: This is your final frontier. Add rules to it that deny access to configuration files and backups.

Example of an .htaccess file with protection against common fuzzing threats

# 1. Disable directory listing
Options -Indexes
# 2. Limit query string length (protection against excessive parameters)
RewriteEngine On
RewriteCond %{QUERY_STRING} ^.{512,}$ [OR]
RewriteCond %{REQUEST_URI} ^.{512,}$
RewriteRule .* - [F,L]
# 3. Deny access to hidden system points (.git, .env, etc.)
RewriteRule "(^|/)\." - [F,L]
# 4. Global filter for backups, archives, and configs
<FilesMatch "\.(bak|sql|sql\.gz|tar|zip|gz|7z|rar|env|ini|log|conf|config|old|save|swp|dist|git|sh|bat|bin|phtml|asp|aspx|jsp|cgi|pl|py|bak[0-9]|temp|tmp)$">
    Order allow,deny
    Deny from all
</FilesMatch>
# 5. Individual ban for high-risk filenames
<FilesMatch "^(wp-config\.php|configuration\.php|settings\.php|db_backup\.sql|dump\.sql|phpinfo\.php|info\.php|test\.php|1\.php|cmd\.php|shell\.php)$">
    Order allow,deny
    Deny from all
</FilesMatch>

Hi-tech.ua Case Study: Real-World Attack Mitigation Experience

The author of this material is the administrator of the website https://hi-tech.ua. The site is protected by the Cloudflare CDN. Everything is configured according to the checklist and protocols. Just a few days ago, on February 25, 2026, the entire server hosting the site went down. It crashed close to midnight. HTTP access was lost. Our “police officers”—the sysadmins—brought the server back up. As the site admin, I took a quick glance at the access and error logs. The logs weren’t bloated as they usually are; there were traces of fuzzing and some background-level DDoS activity, but nothing unusual—such scripts break through constantly in small numbers. Cloudflare logs were also clean, showing only baseline noise. There was nothing to indicate that our site specifically caused the server crash. Well, anything can happen at a data center. However, the next day, February 26, the server went down again. It was brought back up once more. This time, I decided to dig deeper into the logs. The access logs were five times larger than usual, while the error logs remained almost empty. At first glance, it looked like a DDoS attack. But how did Cloudflare, our bouncer, miss this? The bots bypassed it and got bogged down in the second line of defense. And why didn’t the logs bloat on the first day?

A more detailed analysis of the logs from that day and previous ones revealed that the site was subjected to combined fuzzing (Payload Fuzzing via the search form with SQL injection) from a large number (over 1,000) of IP addresses across completely different regions—from Ukraine to the USA, and from China to Burkina Faso. The bots masked themselves as AmazonBot, YandexBot, ChatBot, and others. There were plenty of lines like this in the access log:

GET /search/%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525253bassert%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252528base64_decode%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252528%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252527cHJpbnQobWQ1KDMxMzM3KSk7%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252527%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252529%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252529%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525253b/ HTTP/1.1" 200 15130 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"

Moreover,each IP made unique, non-identical requests at a frequency of no more than 5 per minute. As a result, both Cloudflare’s filters and our own internal security plugins let them through. The problem was that the form returned a200 OK status for these requests. The site wasn’t breached—they couldn’t find any direct holes, and the SQL injections failed because the site’s code treated them as plain text. However, they overloaded the database with heavy queries and strained the server with repeated decoding. The site was being quietly hammered by bots from a small number of IPs (up to 50) throughout the day, which the server and the second line of defense managed to handle. But then, at a certain point, a significantly larger number of IPs joined the attack. That’s when the overload occurred.
I had to add several security rules to Cloudflare and the site’s.htaccesssimultaneously, causing tens of thousands of “bot corpses” to pile up in the logs while the server finally started breathing freely again.

Conclusion

It is difficult to cover all fuzzing techniques and mitigation strategies in a single article. If you are interested in a step-by-step breakdown of how exactly we resolved our issue, let us know in the comments, and we will certainly cover it in future materials.
Remember, fuzzing is an endurance game. A hacker hopes you’ll be lazy and leave a “trail” behind—an old backup or a debug file. Your task is to maintain perfect hygiene. Organized files and a properly configuredCloudflaremake fuzzing your site a waste of time. Time is a resource, and it’s the only thing truly expensive for an attacker. It’s much easier for them to move on and look for someone else—someone who isn’t as “pro” as you.