About bot attacks

What attackers are trying to do

Most attacks we see on commerce sites are profit-driven, not purely destructive.

Broadly, attackers want to:

• Test stolen payment cards to see which ones are still valid (carding).
• Abuse business logic such as coupons, loyalty points, or free-trial flows.
• Harvest data from product catalogs or customer accounts.

The goal is nearly always to turn someone else’s infrastructure and payment flows into cheap testing infrastructure for stolen data.

---

Carding attacks vs “classic” DDoS

People often worry first about DDoS – trying to knock the site offline. That can happen, but on most commerce sites it’s:

• Less common than carding and fraud automation.
• Less profitable for attackers than quietly testing cards at scale.

In a carding attack, bots:

• Take a list of stolen card numbers.
• Send many small payment attempts against your checkout flow.
• Use your site (and your payment provider) to discover which cards are still “alive”.

From your point of view, this shows up as:

• Spikes in failed transactions.
• Complaints from your payment provider about fraud patterns.
• Higher downstream costs, even when charges are declined.

DDoS is about availability (can users reach the site at all?).
Carding is about abuse of your payment flow (can attackers cheaply test cards through you?).

---

How bots actually behave

Modern carding bots rarely just hammer from a single IP. Common patterns include:

• Distributed traffic using botnets or cloud providers.
• Replay attacks using the same session or cookie across many requests.
• Slow, low-and-slow patterns designed to look like real users.

This is why a simple “N requests per IP per minute” rule is often not enough:

• Attackers can rotate IPs.
• They may keep each IP’s rate just below naïve thresholds.
• The real signal might be “too many attempts per session or per account” over a long window.

---

Where Webscale sits in the flow

Webscale acts as a defensive man-in-the-middle between your users and your origin:

• All traffic flows through the Webscale proxy first.
• The proxy can inspect each request and response.
• It can enforce rules independently of your application code.

This position lets us:

• Enforce global policies consistently across all frontends.
• Apply protections even when your application stack is hard to change.
• Observe and correlate behavior across IPs, sessions, and endpoints.

You can think of this as a smart shield in front of your app: the shield decides what to pass on, what to modify, and what to block.

---

Native protections vs web controls

Webscale has native protections baked into the platform (for example, baseline DDoS protections and traffic shaping) that operate automatically.

On top of that, you can add web controls, which are:

• Customer-defined rules that inspect requests and responses.
• Evaluated top-down, with conditions and actions.
• A way to express your own security and routing policies without code changes.

Some examples of what web controls can express:

• “If the URL matches /checkout/payment and the request has exceeded its rate limit, deny the request.”
• “If the site is in maintenance mode, show a maintenance page to the world but allow this address set to pass through.”
• “Add or enforce CSP headers on responses to specific paths.”

Think of native protections as the platform’s baseline safety net, and web controls as a policy language you use to tune that safety to your application and threat model.

---

Why rate limiting matters for carding

Rate limiting is one of the most effective defenses against carding because it raises the attacker’s cost.

Done well, rate limiting can:

• Cap the number of payment attempts per IP or session over a long window (for example, per day).
• Make large card lists much slower and more expensive to test.
• Leave normal users largely unaffected, because real customers don’t make hundreds of payment attempts.

The key design questions for rate limits are:

• Identity – what are you limiting per what? IP, session ID, account, or some combination.
• Threshold – how many attempts are reasonable for a legitimate user.
• Window – over what period (minutes, hours, days) you measure that threshold.

These details are handled in your rate-limiting web controls. The separate how-to guide walks through implementation; this page just explains why those choices matter.

---

Why CSP at the proxy helps

Content Security Policy (CSP) is a browser feature that limits which domains your pages can load scripts, images, and other resources from.

Enforcing CSP from the Webscale proxy has two big advantages:

1. Central control

   • You don’t need to update templates or code everywhere to change CSP.
   • You can introduce CSP gradually, per path or per site.

2. Visibility into reports

   • You can direct CSP violation reports to Webscale, giving you insight into unexpected behavior.
   • This helps detect malicious injections or unexpected third-party scripts.

CSP doesn’t block carding directly. Instead, it:

• Reduces the surface for injected scripts and malicious widgets.
• Makes it harder for attackers to exfiltrate data from your pages.
• Gives you more observability into unusual client-side behavior.

---

How these pieces fit together

Putting it all together for commerce sites:

• Bot and fraud attacks are predominantly about abusing your legitimate flows.
• Webscale’s position as a proxy lets us observe and control these flows without touching your app code.
• Web controls are your language for expressing protection policies (conditions and actions).
• Rate limiting makes automated testing of cards more expensive and less attractive.
• CSP tightens client-side behavior and gives you visibility into suspicious front-end activity.

Once you’re comfortable with this mental model, you can move on to:

• Setting up rate limits for carding protection (how-to guide).
• Configuring CSP via web controls (how-to guide).
• Looking up specific actions and conditions in the web controls reference.

Feedback

Was this page helpful?

Yes No

Glad to hear it! Have any more feedback? Please share it here.

Sorry to hear that. Have any more feedback? Please share it here.