DEV Community: Xequent Solution

Can Malicious Bots Increase Your Hosting Costs? A Developer's Guide to Cloudflare Bot Mitigation

Xequent Solution — Sat, 14 Nov 2026 19:53:00 +0000

When a website starts receiving thousands of requests every minute, the problem isn't always a traditional DDoS attack.

Sometimes the traffic comes from automated systems scraping product catalogs, testing login credentials, or repeatedly requesting expensive application endpoints.

The website may remain online, but its CPU usage increases, database queries multiply, and response times become inconsistent.

For websites using consumption-based cloud infrastructure, this additional workload can also have financial consequences.

Let's look at how bot traffic affects application resources and what developers can do about it.

Not All Requests Have the Same Cost

Serving a cached image and processing a WooCommerce checkout request are very different operations.

A static asset may be delivered directly from a content delivery network without contacting the origin server.

A dynamic request may trigger PHP execution, database queries, session handling, or external service calls.

Consider these common WordPress endpoints:

/wp-login.php — authentication processing.
/wp-json/ — REST API requests.
WooCommerce product search and filtering endpoints.
Customer account functionality.
Checkout and payment-related requests.

The cost of processing these requests depends on the application and infrastructure.

A small number of expensive requests can sometimes consume more resources than a much larger number of cacheable requests.

How Automated Traffic Creates Server Load

Imagine a WooCommerce store with thousands of products.

A bot repeatedly requests product search results using different search terms.

Each request may require the application to query the database, generate results, and return an HTTP response.

If the responses are not suitable for caching, much of that processing reaches the origin server.

With enough concurrent requests, the workload can affect legitimate shoppers.

Possible symptoms include slower page responses, higher CPU usage, increased database activity, and request timeouts.

However, these symptoms do not automatically prove malicious bot activity. Poorly optimized queries, legitimate campaigns, and other application problems can produce similar results.

Developers need evidence before choosing a mitigation strategy.

Can This Increase AWS or Cloud Hosting Bills?

Potentially, yes.

The outcome depends on how the application is hosted and billed.

For example, some environments use autoscaling to add computing capacity when demand increases.

If unwanted traffic contributes to increased resource consumption, the infrastructure may scale to handle requests that provide little or no business value.

Other environments use fixed-price resources, where higher traffic may affect performance without immediately changing compute charges.

Data transfer, managed databases, load balancing, and other services may also have separate billing models.

This is why bot traffic should be evaluated against actual infrastructure metrics rather than assumed financial losses.

Start by Identifying Expensive Endpoints

Before creating Cloudflare rules, identify which requests are responsible for unnecessary work.

A useful analysis combines application logs, web-server access logs, database monitoring, and cloud infrastructure metrics.

For a simple Apache-style access log, a developer can begin by reviewing frequently requested paths.

The following Python example counts request paths in a basic combined-log format:

from collections import Counter
from urllib.parse import urlsplit
import re

request_counts = Counter()

pattern = re.compile(
    r'"(?:GET|POST|PUT|DELETE|HEAD) (\S+) HTTP/[\d.]+"'
)

with open("/var/log/apache2/access.log", encoding="utf-8", errors="replace") as log:
    for line in log:
        match = pattern.search(line)

        if match:
            path = urlsplit(match.group(1)).path
            request_counts[path] += 1

for path, count in request_counts.most_common(15):
    print(f"{count:>7} {path}")

This script is intended as a basic investigative example.

It does not determine whether requests are malicious, and it may need adjustment for different log formats.

It also does not measure CPU usage or request-processing cost.

For meaningful analysis, request frequency should be correlated with response time, application behavior, and infrastructure metrics.

Protecting Expensive Endpoints With Cloudflare

Cloudflare offers several controls that may help reduce unwanted traffic before it reaches the origin.

Depending on the account plan and configuration, developers can use managed security rules, custom WAF rules, rate limiting, and bot-related protections.

The appropriate control depends on the traffic pattern.

For example, repeated authentication attempts may justify controls focused on login endpoints.

Excessive automated requests to particular application functions might benefit from targeted rate limiting.

However, the same thresholds should not automatically be applied across every endpoint.

Legitimate users can generate high request volumes, particularly when several people share a public IP address.

Avoid Breaking Legitimate eCommerce Traffic

Bot mitigation creates a difficult tradeoff.

Too little protection may allow unnecessary requests to consume server resources.

Too much protection may interrupt legitimate shoppers or integrations.

A security challenge applied to a customer-facing page might be manageable for a browser visitor.

That same challenge may be unsuitable for a server-to-server request.

For WooCommerce stores, developers should pay special attention to account authentication, checkout behavior, and payment callbacks.

After changing security rules, test the complete purchasing process and inspect Cloudflare Security Events for unexpected restrictions.

Businesses dealing with unwanted automated traffic may benefit from a targeted Cloudflare bot protection assessment.

At Xequent, the focus is on understanding traffic patterns and application requirements before implementing restrictive controls.

Don't Forget About Caching

Caching can reduce the amount of work performed by the origin server.

For static resources and suitable public content, Cloudflare caching may help reduce repeated requests.

However, caching must be configured according to application behavior.

Personalized account pages, shopping carts, and checkout responses often require special handling.

Caching session-specific content incorrectly can create functionality problems and potentially expose information.

Developers should follow WooCommerce-compatible caching practices rather than applying broad cache-everything rules without testing.

Measuring Whether Bot Protection Worked

After implementing mitigation controls, compare relevant metrics before and after the change.

Useful measurements include:

Requests reaching the origin server.
CPU and memory utilization.
Database query activity.
Application response times.
Checkout errors.
Security rule actions.
Relevant hosting charges.

Choose comparable time periods and account for legitimate changes in traffic.

For example, a marketing campaign or seasonal increase in orders can affect both traffic volume and hosting costs.

Avoid claiming financial savings solely because Cloudflare blocked a particular number of requests.

A blocked request does not necessarily correspond to a fixed monetary value.

The Importance of Origin Security

Cloudflare protections apply to eligible traffic routed through its services.

If the origin server is directly accessible through an unprotected route, attackers may bypass some of those protections.

Developers should verify that public DNS, server firewalls, and origin-access settings are consistent with the intended architecture.

Depending on the environment, suitable protections may include authorized proxy IP restrictions, Authenticated Origin Pulls, or Cloudflare Tunnel.

Origin security is an important complement to bot mitigation.

Final Thoughts

Unwanted automated traffic can consume server resources and, in some environments, increase cloud hosting costs.

But the size of the impact depends on which endpoints are targeted, how the application processes requests, and how the infrastructure is billed.

Developers should identify expensive traffic patterns before applying restrictive controls.

Cloudflare can help reduce some unwanted origin requests, but it works best alongside application optimization, appropriate caching, origin security, and ongoing monitoring.

The objective isn't simply to block more bots. It's to keep infrastructure resources available for genuine users and business-critical operations.

About the author: Rana Shahwaiz Aslam is a Certified Ethical Hacker (CEH) and founder of Xequent, specializing in Cloudflare security, WordPress malware removal, and website protection.

Technical reference: Cloudflare Bot Management Documentation

Cloudflare WAF for WooCommerce: 7 Configuration Mistakes Developers Should Avoid

Xequent Solution — Sat, 14 Nov 2026 19:50:00 +0000

A web application firewall is supposed to protect your website.

But what happens when the firewall itself becomes the reason customers cannot complete purchases?

This is a problem developers need to consider when configuring Cloudflare for WooCommerce.

A restrictive WAF policy might successfully block suspicious requests while also challenging payment callbacks, interfering with customer sessions, or affecting legitimate API traffic.

The challenge isn't simply stopping malicious traffic.

It's protecting the application without breaking the functionality that generates revenue.

Here are seven configuration mistakes worth avoiding.

1. Treating Every WooCommerce Endpoint the Same

A WooCommerce website contains different types of requests.

Product pages are mostly intended for browsing.

Customer login endpoints handle authentication.

Shopping carts and checkout pages process session-specific information.

Payment integrations may depend on automated server-to-server communication.

These endpoints have different security requirements.

A challenge that works for an ordinary browser request may be inappropriate for a payment-provider callback.

Before creating a WAF rule, developers should map the application's important endpoints and understand how they are used.

2. Applying Broad Managed Challenges

Cloudflare supports several security actions, including Block, Managed Challenge, and Skip.

Managed Challenge can be useful when suspicious browser traffic needs additional verification.

However, developers should avoid assuming that every legitimate request can complete a browser challenge.

Some API clients, monitoring services, and server-to-server integrations cannot.

For example, applying a challenge broadly to all requests under an application's API path could affect trusted integrations.

Instead, use request characteristics and actual security evidence to narrow the scope.

3. Creating Exceptions That Bypass Too Much

Sometimes a legitimate request is blocked by a managed WAF rule.

The immediate temptation may be to create a Skip rule for the entire affected directory.

That can solve the visible problem while unnecessarily weakening security.

Suppose a payment integration uses a dedicated endpoint.

A safer starting point is identifying the exact security rule responsible for the false positive.

Developers can then evaluate whether an exception should apply to that specific rule and a narrowly defined request pattern.

A hypothetical Cloudflare expression might look like this:

(http.host eq "store.example.com"
 and http.request.uri.path eq "/api/payment-callback"
 and ip.src in {192.0.2.10})

This example uses documentation-only values.

It is not a production-ready payment security policy.

The actual endpoint must still verify legitimate payment notifications using the provider's required authentication or signature validation.

A WAF exception should never replace application-level authentication.

4. Ignoring Cloudflare Rule Execution Order

Cloudflare processes requests through different security phases.

Within relevant rulesets, actions and execution order can determine how a request is handled.

For instance, an earlier rule that blocks a request may prevent later rules from evaluating it.

Similarly, a configured Skip action may bypass selected protections.

If developers don't understand these interactions, they may introduce rules that conflict with existing security policies.

Before deploying changes, review the order and scope of active rules.

Cloudflare's official security features interoperability documentation provides a useful explanation of how its security features interact.

5. Forgetting About Direct Origin Access

Cloudflare can inspect eligible traffic passing through its proxy.

But what if someone can reach the hosting server directly?

An exposed origin may allow traffic to avoid the HTTP-layer WAF controls configured through Cloudflare.

This can happen when the server accepts public connections independently of its Cloudflare configuration.

Developers should review DNS records, server firewall restrictions, and origin-access requirements.

Depending on the architecture, protective options may include restricting inbound web traffic to authorized Cloudflare IP ranges, using Authenticated Origin Pulls, or considering Cloudflare Tunnel.

The correct approach depends on hosting requirements and any services that need direct network connectivity.

6. Relying on Blocked-Request Counts

A large number of blocked requests can look impressive in a dashboard.

However, those numbers don't automatically establish that the WAF is correctly configured.

Consider two situations.

In the first, the WAF blocks repeated malicious requests without interfering with legitimate visitors.

In the second, the WAF blocks malicious requests but also prevents some real customers from completing checkout.

Both configurations might show high blocked-request counts.

Only the first meets the application's operational requirements.

Developers should examine false positives, origin workload, checkout functionality, and error rates alongside security events.

7. Deploying Rules Without Testing Checkout

This may be the most costly mistake for an eCommerce site.

After making significant security changes, developers should test:

Product browsing and search.
Customer registration and login.
Shopping cart updates.
Coupon application.
Guest checkout, where supported.
Payment processing in an appropriate test environment.
Payment-provider callbacks and order creation.
Relevant third-party integrations.

If something fails, review the corresponding Cloudflare Security Events and application logs before changing rules again.

A Cloudflare Ray ID can sometimes help locate the relevant request.

A Better WAF Deployment Workflow

Rather than adding rules reactively, use a controlled process.

Step 1: Establish Normal Traffic Behavior

Review important request paths, legitimate integrations, and existing security events.

Step 2: Identify the Actual Threat

Determine whether the problem involves credential abuse, excessive requests, known exploits, or another attack pattern.

Step 3: Choose an Appropriate Control

Evaluate managed rules, custom WAF conditions, rate limiting, or relevant bot-management features.

Step 4: Test Before Stricter Enforcement

Where the available feature supports it, use logging or a less disruptive approach to understand matching traffic.

Step 5: Validate Application Behavior

Test the legitimate workflows most likely to be affected.

Step 6: Monitor the Results

Compare security actions with actual user experience and origin behavior.

This is the kind of evaluation we focus on at Xequent when working on Cloudflare WAF configuration for WordPress and WooCommerce environments.

Final Thoughts

Cloudflare WAF can provide valuable protection for WooCommerce websites, but its effectiveness depends on configuration.

Broad challenges, unnecessary Skip rules, exposed origins, and poorly understood execution order can create unexpected results.

Developers should aim for targeted protections supported by request-level evidence and careful application testing.

A good WAF configuration doesn't simply block attacks. It also allows the business to keep working.

About the author: Rana Shahwaiz Aslam is a Certified Ethical Hacker (CEH) and founder of Xequent, specializing in Cloudflare WAF, WordPress security, and bot mitigation.

Technical reference: Cloudflare Managed Rules Troubleshooting

Why WordPress Malware Keeps Coming Back After Cleanup (And How to Stop Reinfection)

Xequent Solution — Sat, 14 Nov 2026 19:43:00 +0000

A WordPress website gets infected. Someone runs a malware scanner, deletes several suspicious PHP files, and the website starts working again.

Everything looks normal.

Then, a few hours or days later, the same malicious files reappear.

This is one of the most frustrating problems in WordPress incident response. The malware was removed, but the infection wasn't actually resolved.

The underlying issue is usually that the attacker still has a way into the website or hosting environment.

Let's examine why this happens and how developers can investigate it properly.

Malware Removal and Incident Recovery Are Different

A malware scanner can identify suspicious files, but it may not reveal how the attacker entered the system.

Consider a WordPress website compromised through a vulnerable plugin.

An attacker might use that vulnerability to upload a PHP backdoor. The website owner later removes the backdoor but doesn't update the vulnerable plugin.

The attacker can potentially exploit the same vulnerability again.

Alternatively, the attacker may have created a second backdoor, added an unauthorized administrator, or established a scheduled task that restores malicious files.

A successful cleanup therefore requires identifying both the visible malware and the mechanism that allowed the compromise.

1. Check for Hidden PHP Backdoors

Attackers sometimes disguise malicious code as legitimate WordPress components.

Suspicious files may appear in upload directories, inactive themes, plugin folders, or unexpected subdirectories.

One useful first step is looking for recently modified PHP files.

On a Linux server, an administrator can use:

find /var/www/html -type f -name "*.php" -mtime -7 -print

This lists PHP files modified within the past seven days.

It does not prove that those files are malicious. Legitimate updates and development activity may also modify PHP files.

The results should be compared against known deployment activity and trusted WordPress package files.

Avoid deleting files solely because they appear in this list.

2. Review WordPress Core File Integrity

WordPress provides tools for verifying whether installed core files match official release checksums.

If WP-CLI is available, run:

wp core verify-checksums

This can help identify modified or unexpected core files.

However, checksum verification has limitations.

A successful result doesn't establish that plugins, themes, the database, or other server files are clean.

For supported plugins, checksum verification can provide additional information:

wp plugin verify-checksums --all

Some commercial or custom plugins may not have WordPress.org checksums available.

Unexpected results require investigation rather than immediate deletion.

3. Audit Administrator Accounts

Attackers sometimes create unauthorized WordPress administrator accounts.

A compromised administrator account may allow malicious plugins or scripts to be installed again.

WP-CLI provides a way to review users:

wp user list --role=administrator

Compare the output with the people who should legitimately have administrative access.

Investigate unfamiliar accounts, unexpected privilege changes, and suspicious recent activity.

Potentially compromised credentials should be rotated, and multifactor authentication should be enabled where available.

Don't forget hosting accounts, SFTP credentials, database credentials, and associated email accounts.

4. Investigate Scheduled Tasks

Recurring malware sometimes involves persistence mechanisms that execute code after a cleanup.

WordPress includes WP-Cron, while hosting environments may also support system cron jobs.

Review scheduled tasks for unexpected behavior.

With WP-CLI:

wp cron event list

Look for unfamiliar hooks, unusual schedules, and jobs associated with plugins that are no longer installed.

A scheduled task isn't malicious simply because its name is unfamiliar. Its purpose and implementation should be verified before removal.

System-level scheduled tasks should also be inspected where administrators have appropriate access.

5. Inspect the Database

Not every WordPress infection is stored as a standalone PHP file.

Attackers may inject malicious JavaScript, spam links, altered configuration values, or unauthorized content into the database.

Common places worth investigating include posts, options, and application-specific metadata.

A database review should be conducted carefully.

WordPress and its plugins store structured and serialized information. Removing unfamiliar records without understanding them can break website functionality.

Preserve a backup and document changes before modifying production data.

6. Check Other Websites on Shared Hosting

This step is frequently overlooked.

A hosting account may contain multiple WordPress installations.

If those websites share filesystem permissions or the same system user, a compromise affecting one installation may create risks for others.

Cleaning only the most visibly infected website may leave another compromised installation untouched.

Administrators should review all applications and directories accessible through the affected hosting account.

Where supported, isolating websites under separate system users can reduce the impact of a future compromise.

7. Never Trust a Backup Without Verification

Restoring a clean backup can be an effective recovery method.

However, a backup created after the original compromise may contain the same malware.

Before restoration, evaluate when the infection likely began and inspect the backup where practical.

After restoring, patch the original weakness and rotate compromised credentials.

Otherwise, the same infection may return.

A Practical WordPress Malware Recovery Workflow

A structured investigation generally follows this sequence:

Preserve logs and capture a protected backup of the affected environment.
Contain unauthorized access where practical.
Identify suspicious files, accounts, database changes, and scheduled tasks.
Determine the likely entry point.
Remove malicious components or rebuild from trusted sources.
Patch vulnerable software and rotate affected credentials.
Verify normal website functionality.
Monitor the environment for signs of recurring compromise.

At Xequent, we approach WordPress malware removal as both a cleanup and a root-cause investigation.

The goal is to address the security weakness behind an infection rather than repeatedly deleting its symptoms.

Final Thoughts

Recurring WordPress malware usually requires more investigation than a single scan.

A compromised plugin, hidden backdoor, stolen credential, or infected backup may allow an attacker to regain access after the visible malware disappears.

Developers should approach recovery as an incident-response process that includes evidence preservation, technical investigation, vulnerability remediation, and verification.

Removing malicious code is one step. Preventing the same compromise from returning is the real objective.

About the author: Rana Shahwaiz Aslam is a Certified Ethical Hacker (CEH) and founder of Xequent, a website security company specializing in WordPress security and Cloudflare protection.