Anyone running an online shop has long stopped dealing with human visitors alone. A significant share of today's traffic comes from automated programs -- from harmless search-engine crawlers through aggressive price scrapers to attack bots that brute-force logins or probe for weaknesses. According to the Imperva Bad Bot Report, bad bots accounted for around 32 percent of all internet traffic in 2023, while the share of human users fell to 50.4 percent (Imperva Bad Bot Report 2024). A Web Application Firewall (WAF) and well-considered bot management are therefore no longer optional extras but a fixed part of responsible shop operation. This guide shows how WAF and bot protection work in live operation, which attacks they absorb and why caring for this layer belongs in ongoing maintenance.
Why Bots Now Make Up the Majority
Automated traffic is no fringe phenomenon but now drives a large share of requests to a shop. In its State of Application Security Report 2024, Cloudflare attributed around 31.2 percent of all application traffic to bots -- a figure that stayed close to 30 percent over three years (Cloudflare State of Application Security 2024). Since then the situation has sharpened: with the rise of autonomous AI agents, Cloudflare stated in June 2026 that automated systems now account for 57.5 percent of all HTTP requests to web content (Cloudflare 2026).
For German shops the situation is particularly tense. In the Imperva Bad Bot Report 2024, the share of malicious bot traffic in Germany stood at 67.5 percent, among the highest worldwide, just behind Ireland at 71 percent (Imperva Bad Bot Report 2024). These figures make it clear: a shop without an active filter often sees more machines than humans in its analytics -- with distorted statistics, needless server load and a constantly open gateway for attacks. Telling real traffic from noise is also a central topic in log monitoring and alerting.
There is also an economic dimension that is often underestimated. Every automated request consumes compute time, database connections and bandwidth -- resources meant for paying customers. A shop that spends a large part of its load on scrapers and attack attempts is paying for infrastructure that produces no revenue, and risks slower response times for real visitors during peak periods. An upstream filter that catches part of this noise therefore relieves not only security but also performance and ongoing operating costs.
WAF and bot management are two layers
What a Web Application Firewall Does
A WAF sits in front of the shop application itself and inspects every incoming HTTP request before it reaches the code. It works at the application layer (Layer 7) and detects attack patterns that a classic network firewall does not see. The OWASP ModSecurity Core Rule Set (CRS), an open-source collection of generic detection rules against the most common attack classes, serves as a proven rule base (OWASP CRS). The rules cover injection attempts, path traversal and the exploitation of known weaknesses, among others.
The need is measurable: the OWASP project Automated Threats to Web Applications catalogues 21 distinct bot attack types against web applications, from credential stuffing through scraping to abusing business logic (OWASP Automated Threats). A WAF alone fixes no weakness in the code, but it buys time and filters out a large part of the automated noise -- as an additional layer above a cleanly hardened server configuration.
Signature-based filters
Known attack patterns such as SQL injection or XSS are detected and blocked using rule sets like the OWASP CRS before they reach the application.
Anomaly detection
Unusual request patterns -- such as sudden spikes on individual endpoints -- stand out and can be throttled or reviewed in a targeted way.
Virtual patching
Until a code update is available, a WAF rule can temporarily shield a freshly disclosed gap and bridge the window.
Geo and IP filters
Requests from suspicious networks or regions with no business relevance can be scrutinized more strictly or given extra hurdles.
Rate limiting
Too many requests per time unit from one source point to automation and are limited -- an effective measure against brute force.
Logging
Every blocked and allowed request is logged and provides the basis for evaluation, fine-tuning and incident analysis.
Bot Management: Separating Good Bots from Bad
Not every bot is an adversary. Search-engine crawlers create visibility, monitoring services check availability, and AI crawlers evaluate content. The art of bot management lies in allowing these desired automations while detecting harmful bots. Cloudflare, for example, uses a bot score that classifies requests by behaviour and characteristics -- a value near the lower bound is considered definitively automated (Cloudflare Bot Management documentation).
The distinction is becoming harder because attackers refine their tools. According to the Kasada Account Takeover Report, 65 percent of analyzed takeover attacks relied on advanced automation such as CAPTCHA-bypass services and residential proxies, and 85 percent of targeted companies already had bot detection in place -- yet some attacks still succeeded (Kasada Account Takeover Report 2025). Good bot management is therefore not a one-time checkbox but a continuously refined layer.
| Bot type | Example | Sensible handling |
|---|---|---|
| Desired bots | search-engine crawlers, monitoring | allow, confirm via verified lists where possible |
| Grey-area bots | AI crawlers, price comparison | weigh up, throttle or steer via robots.txt |
| Scrapers | content and price theft | limit, offer a challenge, block patterns |
| Attack bots | credential stuffing, vulnerability scans | block consistently and log |
| Spam bots | fake registrations, form spam | catch via rate limiting and challenges |
Fake traffic distorts every decision
The Most Common Automated Attacks on Shops
Online shops are a particularly rewarding target because behind the customer accounts lie payment data, stored addresses and loyalty points. Account takeover attacks rose sharply in 2024 -- one report recorded an increase of around 250 percent over the course of the year, fuelled by seasonal spikes and credential-stuffing campaigns (Kasada Account Takeover Report 2025). In credential stuffing, bots test stolen credentials en masse against the login form, hoping that users reuse passwords.
At the same time, the number of overload attacks is rising. The worldwide number of DDoS attacks nearly doubled in 2024, growing by around 108 percent over the previous year (StormWall 2024). Retail was among the most heavily affected sectors, accounting for roughly 12 percent of all recorded attacks (StormWall 2024). The German BSI also observes a growing share of high-volume DDoS attacks, whose share rose to around 13 percent in 2024 -- more than double the long-term average (BSI report 2024).
- Credential stuffing and account takeover -- automated testing of stolen credentials against the login form.
- Scraping -- systematic harvesting of product data, prices and content, often by competitors or aggregators.
- Carding and fake orders -- testing stolen card data through the checkout in rapid succession.
- Spam registrations -- automated creation of fake accounts that bloat databases and trigger mailings.
- Vulnerability scans -- bots search for known gaps in extensions, admin paths and outdated components.
- DDoS and load spikes -- targeted overload, often commercially motivated and timed to promotional phases.
Many of these attacks target the login and the API endpoints of the shop -- exactly the places where a WAF with rate limiting and a bot filter with behavioural analysis have the greatest leverage. Vulnerability scans are particularly delicate: bots probe known paths automatically, search for outdated extensions and try to plant injected malicious code. If such an attempt succeeds, a quiet compromise often begins that only surfaces weeks later -- which is why ongoing malware scanning and cleanup sensibly complements WAF protection. Anyone who still fails to catch an incident early enough should keep an emergency plan for hacked websites at hand.
Maintaining WAF and Bot Protection in Live Operation
A WAF is not a device you switch on once and forget. Rule sets must be kept current, thresholds adjusted and false positives cleaned up. Configured too strictly, a WAF blocks real customers and legitimate orders; too loosely, it misses its purpose. This balance arises only through ongoing observation of the logs and gradual refinement -- ideally starting in an observation mode that reports hits without blocking immediately.
Activate observation mode
New rules first run in pure report mode. This shows which requests they would hit without blocking real customers -- the basis of any serious rollout.
# Protect login endpoint against brute force and credential stuffing
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /account/login {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
# forward to the application
proxy_pass http://shop_backend;
}
# Pace API endpoints more tightly than regular pages
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m;
location /api/ {
limit_req zone=api burst=10 nodelay;
proxy_pass http://shop_backend;
}Protection complements hardening, it does not replace it
Avoiding False Positives: Not Locking Out Real Customers
The biggest challenge in live operation is not the attackers but the false alarms. A WAF that is too aggressive -- blocking a legitimate checkout or mistaking a major customer with many rapid requests for a bot -- costs revenue immediately. Every protection concept therefore includes a deliberate stance on what happens when a rule hits a borderline case. A hard-blocked customer, in the best case, sees an error page and tries again -- in the worst case, they move to a competitor and do not return. That is exactly why the response to a suspected case is carefully graduated rather than rejecting every anomaly outright.
The right setting depends heavily on the specific shop. A marketplace with many simultaneous users tolerates different thresholds than a niche shop with few but large orders. The structure of the customer base also matters: business customers accessing through central corporate networks generate many requests from a single address and must not be reflexively classified as a bot. These nuances cannot be derived from a standard rule set but emerge from observing real traffic over several weeks -- another reason why WAF care belongs in live operation rather than in a one-time setup.
Challenge instead of block
In doubt, the request is not blocked hard but offered a low-threshold check. Real humans pass it, simple bots fail.
Maintain allowlists
Known good sources -- payment providers, monitoring, own systems -- are placed on exception lists so they are not flagged by mistake.
Evaluate logs
Regular review of blocked requests uncovers false positives early and provides the basis for targeted exceptions.
Graduated response
Instead of a hard yes/no there are gradations: log, throttle, challenge, block -- depending on the level of suspicion.
Plan for seasons
Promotional phases and sale days create legitimate load spikes. Thresholds are adjusted in advance so that real demand is not treated as an attack.
Review regularly
What fits today may be outdated after the next shop update. A recurring review keeps the filter accurate.
Good protection does not draw attention -- it lets the real customers pass undisturbed and keeps the noise quiet in the background. You only notice it when it is missing.
Protection, monitoring and maintenance interlock
Anyone who has set up WAF and bot management cleanly once and folded them into the maintenance rhythm gains twice over: fewer successful attacks and cleaner data as a basis for decisions. The setup, fine-tuning and ongoing care of this layer is handled by our managed service support -- so that protection does not quietly decay after the first day but grows with the shop. An assessment for your specific shop comes from a personal conversation.