DDoS protection

Defense-in-depth, before traffic reaches your origin.

Watch attacks get absorbed at each Cloudflare layer.

AnycastHTTP DDoSRate LimitWAF / BotORIGINPROTECTEDAttack traffic incoming

Defense layer

Anycast Network

Cloudflare's global Anycast network absorbs volumetric L3/L4 floods at the edge. Attack traffic is distributed across hundreds of data centers — no single PoP becomes the bottleneck.

  • Hundreds of Gbps absorbed at edge
  • No origin egress consumed
  • No customer config required
Plan DDoS protection View DDoS readiness checklist
On this page
AI summary Machine-readable context is available at /ai-index.json

Nanosek provides Cloudflare DDoS protection services for organizations that need to protect web applications, APIs, DNS, and infrastructure from volumetric attacks, HTTP floods, API floods, bot-driven request floods, DNS attacks, and origin exhaustion. The service includes discovery, traffic baseline analysis, Cloudflare architecture design, DDoS and WAF policy tuning, origin hardening, emergency onboarding planning, monitoring and alerting, incident response runbooks, post-attack review, and managed Cloudflare operations.

cloudflareddos protectionlayer 7 ddoshttp floodapi flooddns protectionorigin protectionwaf

Who this is for

Security, infrastructure, platform, application, API, SaaS, and e-commerce teams responsible for public-facing services.
Organizations that need to reduce DDoS risk across web applications, APIs, DNS, network services, and enterprise infrastructure.
Teams that need Cloudflare architecture, origin hardening, monitoring, escalation, emergency response workflows, and managed operations.

What Cloudflare DDoS Protection helps defend

Volumetric Layer 3/4 attacks

High-volume floods can saturate network capacity. Cloudflare network-layer DDoS controls, Magic Transit, or Spectrum may apply depending on architecture.

HTTP floods

Layer 7 request floods target expensive web paths. Cloudflare HTTP DDoS rules, WAF, cache strategy, bot signals, and rate limits help reduce application load.

API floods

Automated API traffic can exhaust backend capacity. API Shield, mTLS, schema validation, WAF rules, and endpoint-specific rate limits create a separate control model.

DNS attacks

DNS query floods can disrupt availability before application traffic arrives. Cloudflare authoritative DNS and DNS DDoS protection improve resilience.

Bot-driven request floods

Automated clients can look similar to real users. Bot Management, WAF custom rules, managed challenges, and rate limiting help classify and control risk.

Credential stuffing spikes

Attack traffic on login endpoints can combine DDoS pressure with account takeover risk. Bot controls, Turnstile, rate limits, and WAF rules protect the flow.

Search and catalog abuse

Expensive search or catalog paths can be abused at high volume. Cache strategy, bot score thresholds, and path-specific rate controls reduce load.

Origin exhaustion

Even with edge protection, exposed or poorly cached origins can fail. Origin lockdown, cache tuning, and origin rules reduce direct and indirect exhaustion.

Slow application attacks

Low-rate attacks against expensive operations can evade simple volumetric assumptions. Baselining and application-aware controls are needed.

Attack traffic targeting uncached paths

Attackers often target bypassed or dynamic paths. Nanosek identifies expensive uncached paths and designs controls around them.

Multi-vector attacks

DDoS events can combine DNS, HTTP, API, bot, and origin-bypass tactics. Cloudflare controls need to be layered and monitored together.

Emergency attack onboarding

During active incidents, rapid stabilization requires DNS, certificates, origins, WAF, rate limits, monitoring, and rollback decisions under pressure.

Why DDoS protection is more than automatic mitigation

Cloudflare provides strong automated DDoS protection, but real operational resilience depends on architecture and preparation. If the origin remains exposed, if cache rules are weak, if APIs are unprotected, if logging is missing, or if escalation paths are unclear, an attack can still cause business disruption.

DDoS protection is not only bandwidth absorptionLayer 7 attacks often look like real trafficOrigin exposure can bypass edge protectionAPI endpoints need separate controlsFalse positives must be managed carefullyResponse workflows matter during an active attackPost-attack tuning improves future resilience

Our Cloudflare DDoS protection approach

Phase 1

Exposure and traffic discovery

  • Review public hostnames, DNS records, origin IP exposure, CDN onboarding model, APIs, DNS zones, critical paths, login, checkout, search, file upload, and high-risk services.
  • Identify attack history, current monitoring, current CDN/WAF posture, and emergency response ownership.
Phase 2

Traffic baseline and risk mapping

  • Establish normal traffic patterns by hostname, path, method, country, ASN, user agent, bot score, response code, request rate, cache ratio, and origin load.
  • Identify paths that are expensive, uncached, authentication-heavy, or vulnerable to request floods.
Phase 3

Cloudflare architecture hardening

  • Review Cloudflare DNS, proxy status, SSL/TLS mode, cache strategy, origin rules, WAF, Bot Management, Rate Limiting, API Shield, Load Balancing, and Logpush.
  • Lock down origins so direct-to-origin traffic cannot bypass Cloudflare.
Phase 4

Policy design and tuning

  • Design HTTP DDoS, WAF, bot, and rate limiting controls around application behavior.
  • Create separate strategies for static content, login, checkout, APIs, file uploads, admin paths, and partner integrations.
Phase 5

Monitoring and response readiness

  • Configure dashboards, alerts, Logpush, security analytics, GraphQL reporting, escalation contacts, and attack response runbooks.
  • Define when to challenge, rate limit, block, bypass, or escalate.
Phase 6

Incident response and active attack support

  • During an attack, review traffic patterns, tune rules, apply emergency controls, protect origin capacity, and coordinate stakeholder updates.
  • Use temporary controls carefully and document every change.
Phase 7

Post-attack review and optimization

  • Review attack timeline, impact, blocked traffic, allowed traffic, false positives, origin load, cache behavior, and rule effectiveness.
  • Convert emergency rules into durable policies where appropriate.

Architecture

Public hostname, DNS, proxy status, certificate, cache, API, and origin exposure model across applications and infrastructure.
Layer 3/4, Layer 7, DNS, HTTP, API, bot, WAF, and rate limiting controls aligned to actual attack surfaces.
Origin hardening with firewall allowlisting, Authenticated Origin Pulls, removal of direct DNS exposure, origin rules, load balancing, and health checks.
Security Analytics, Logpush, GraphQL Analytics, dashboards, alerts, escalation contacts, runbooks, and post-attack review workflow.

Cloudflare controls we use

Cloudflare DNS

Used for resilient authoritative DNS, proxy readiness, TTL control, and emergency routing changes.

Cloudflare DDoS Protection

Used as the core automated protection layer for attacks across Cloudflare-proxied services.

HTTP DDoS Managed Rules

Used to detect and mitigate Layer 7 HTTP floods while preserving legitimate application traffic.

Network-layer DDoS protection

Used for Layer 3/4 flood mitigation where Cloudflare is protecting network paths.

Magic Transit

Used where enterprise network ranges need routed network-layer DDoS protection.

Spectrum

Used where non-HTTP TCP or UDP services need Cloudflare protection.

WAF Managed Rules

Used to reduce application exploit traffic that may accompany DDoS events.

WAF Custom Rules

Used for path, method, ASN, country, header, URI, and application-specific emergency controls.

Rate Limiting

Used for login, APIs, search, forms, and expensive paths vulnerable to request floods.

Bot Management

Used to distinguish automated request floods from likely human traffic.

Super Bot Fight Mode

Used where applicable for simpler bot mitigation needs on eligible plans.

API Shield

Used for API inventory, schema validation, mTLS, and API-specific protection.

mTLS

Used to authenticate trusted API clients, partner systems, and service-to-service traffic.

Turnstile

Used to add low-friction verification on suspicious login, form, or signup flows.

Cache Rules

Used to increase cache eligibility and reduce origin load during traffic spikes.

Tiered Cache

Used to reduce origin fetches and improve cache efficiency under load.

Origin Rules

Used to control origin routing, Host headers, SNI, ports, and backend selection.

Load Balancing

Used to steer traffic across origin pools and reduce single-origin failure risk.

Health Checks

Used to detect origin degradation and trigger failover workflows.

Waiting Room

Used where legitimate surges need controlled queuing rather than blocking.

Logpush

Used to send HTTP, WAF, bot, and security events to SIEM or data platforms.

Security Analytics

Used for live event review and post-attack analysis.

GraphQL Analytics

Used for reporting, trend analysis, cache review, and operational dashboards.

Cloudflare Workers

Used for advanced emergency logic when native rules are not enough.

Terraform/API automation

Used to keep protection policy reviewable, repeatable, and change-controlled.

Protection by attack surface

Public websites

Common risk

HTTP floods and request spikes

Cloudflare approach

DDoS protection, WAF, cache rules, bot controls, rate limits

APIs

Common risk

Request floods and expensive backend calls

Cloudflare approach

API Shield, mTLS, rate limiting, WAF custom rules, schema validation

Login pages

Common risk

Credential stuffing and account takeover spikes

Cloudflare approach

Bot Management, rate limiting, Turnstile, WAF rules

Checkout flows

Common risk

Availability risk and false-positive sensitivity

Cloudflare approach

Conservative challenge strategy, monitoring, path-specific rules

DNS

Common risk

DNS query floods and availability risk

Cloudflare approach

Cloudflare authoritative DNS and DNS DDoS protection

Origin infrastructure

Common risk

Direct-to-origin bypass and exhaustion

Cloudflare approach

Origin lockdown, authenticated origin pulls, firewall allowlisting

Static content

Common risk

Bandwidth spikes and cache misses

Cloudflare approach

Cache rules, tiered cache, cache reserve, origin shielding behavior

Admin portals

Common risk

Targeted abuse and brute force

Cloudflare approach

Access, WAF rules, IP restrictions, identity-aware controls

Network services

Common risk

L3/L4 floods

Cloudflare approach

Magic Transit or Spectrum depending on architecture

High-traffic campaigns

Common risk

Legitimate surge looks like attack

Cloudflare approach

Baselining, caching, Waiting Room, rate controls

Deployment steps

  1. 01 Inventory public hostnames, DNS, origin exposure, APIs, critical paths, attack history, and response ownership.
  2. 02 Baseline normal traffic by hostname, path, method, country, ASN, bot score, response code, request rate, cache ratio, and origin load.
  3. 03 Harden Cloudflare architecture across DNS, proxy status, SSL/TLS, cache, origins, WAF, bot controls, rate limiting, API Shield, and Logpush.
  4. 04 Design path-specific HTTP DDoS, WAF, bot, rate limiting, and API controls with rollback and exception handling.
  5. 05 Configure dashboards, alerts, analytics, escalation contacts, and incident response runbooks.
  6. 06 Support active incidents with traffic review, temporary controls, origin protection, stakeholder updates, and documented changes.
  7. 07 Run post-attack review and convert useful emergency controls into durable policies.

Risks and mitigations

Risk

Origin remains exposed.

Mitigation

Lock down origin access to Cloudflare IPs, use Authenticated Origin Pulls, and remove direct DNS exposure.

Risk

Layer 7 attack looks like real users.

Mitigation

Use path-specific baselines, WAF, bot signals, rate limits, and managed challenges.

Risk

API floods overload backend.

Mitigation

Use API Shield, rate limiting, mTLS, schema validation, and endpoint-specific controls.

Risk

False positives during attack.

Mitigation

Start with targeted controls, monitor events, and avoid broad blocking on sensitive paths.

Risk

Cache miss spike overloads origin.

Mitigation

Improve cache rules, monitor cache ratio, and protect expensive uncached paths.

Risk

DNS misconfiguration.

Mitigation

Review authoritative DNS, TTLs, proxy status, and emergency change process.

Risk

Missing visibility.

Mitigation

Configure Security Analytics, Logpush, dashboards, and alerting before an incident.

Risk

Emergency rules become permanent risk.

Mitigation

Review and convert temporary rules into scoped durable policies after the incident.

Risk

Partner traffic blocked.

Mitigation

Document partner integrations and create scoped allow or authentication policies.

Risk

No response ownership.

Mitigation

Create an incident runbook with owners, escalation paths, and decision criteria.

DDoS readiness checklist

  • Public hostnames inventoried
  • DNS records reviewed
  • Cloudflare proxy status confirmed
  • Origin IP exposure reviewed
  • Origin firewall allowlisting configured
  • Authenticated Origin Pulls considered
  • SSL/TLS mode validated
  • Critical paths mapped
  • API endpoints mapped
  • Login and checkout flows reviewed
  • Cache behavior reviewed
  • Uncached expensive paths identified
  • WAF and HTTP DDoS events reviewed
  • Bot score distribution reviewed
  • Rate limits designed safely
  • Logpush or analytics configured
  • Alerting and escalation contacts defined
  • Emergency rules prepared
  • Rollback procedure documented
  • Incident response runbook approved

Deliverables

  • DDoS exposure assessment
  • Public hostname and origin inventory
  • Origin hardening plan
  • Cloudflare DDoS protection architecture
  • HTTP DDoS and WAF policy review
  • API protection plan
  • Bot and rate limiting strategy
  • Cache and origin resilience recommendations
  • Monitoring and alerting setup
  • Emergency response runbook
  • DDoS readiness checklist
  • Post-attack review template
  • Managed operations handover

Emergency DDoS support and rapid stabilization

When an attack is already in progress, Nanosek can help prioritize stabilization: onboarding traffic to Cloudflare, protecting exposed origins, reviewing attack patterns, applying temporary WAF or rate limiting controls, validating DNS and certificates, monitoring user impact, and preparing post-incident tuning.

Emergency response support
Traffic review and control tuning
Origin protection and exposure reduction
Temporary WAF, bot, and rate limiting controls
DNS, certificate, and onboarding validation
Coordinated response and post-incident recommendations

When Nanosek should help

You are already using Cloudflare but are unsure if DDoS protection is configured correctly.
Your origin IPs may still be exposed.
You need to protect APIs, login, checkout, or high-cost endpoints.
You experienced a DDoS or HTTP flood and need post-incident hardening.
You need emergency onboarding to Cloudflare.
You need dashboards, alerts, escalation, and response runbooks.
You need managed Cloudflare security operations.

Frequently asked questions

What does Cloudflare DDoS Protection cover?
Cloudflare provides DDoS protection across different layers depending on the service and architecture, including web applications, DNS, HTTP traffic, network services, and infrastructure use cases. Nanosek helps design the surrounding configuration, origin protection, monitoring, and response process.
Is Cloudflare DDoS protection automatic?
Cloudflare includes automated DDoS protection, but operational resilience still depends on correct onboarding, origin hardening, cache strategy, API protection, logging, alerting, and incident response workflows.
What is the difference between Layer 3/4 and Layer 7 DDoS attacks?
Layer 3/4 attacks target network capacity and protocols, while Layer 7 attacks target application endpoints such as HTTP pages, APIs, login flows, search, or checkout. Layer 7 attacks often require more application-aware controls.
How do we stop attackers from bypassing Cloudflare?
Origins should be locked down so they only accept expected traffic through Cloudflare. This may include firewall allowlisting, Authenticated Origin Pulls, removing direct DNS exposure, and reviewing leaked origin IPs.
Can DDoS controls block real users?
Yes, especially during Layer 7 attacks or aggressive emergency rules. Nanosek uses scoped controls, monitoring, bot signals, rate limits, and gradual enforcement to reduce false positives.
Can Cloudflare protect APIs from DDoS attacks?
Yes. API protection often combines Cloudflare DDoS protection, WAF custom rules, rate limiting, API Shield, mTLS, schema validation, and endpoint-specific policies.
What should we prepare before an attack?
You should inventory public hostnames, lock down origins, validate DNS and certificates, map critical paths, configure logs and alerts, define emergency contacts, and prepare an incident runbook.
Can Nanosek help during an active attack?
Yes. Nanosek can help with rapid stabilization, traffic review, Cloudflare rule tuning, origin protection, emergency controls, monitoring, and post-incident recommendations.
Can Nanosek manage DDoS protection after deployment?
Yes. Nanosek provides managed Cloudflare operations, including DDoS readiness reviews, rule tuning, monitoring, incident support, reporting, and post-attack optimization.

Build DDoS resilience on Cloudflare

Nanosek helps you prepare, harden, monitor, and respond so Cloudflare DDoS protection is backed by the right architecture and operating model.

Talk to Nanosek View Cloudflare services
Ready to talk?

Deliver Cloudflare without surprises.

Whether you're migrating, hardening, or operating Cloudflare — Nanosek brings authorized MSP & ASDP delivery, rollback-ready cutovers, and managed operations after launch.

Talk to Nanosek Run readiness assessment