Edge Threat Radar

Connect your Cloudflare account so the Edge Threat Radar can correlate adversary traffic with your posture. Read-only by default; one Edit scope for the optional approval-gated blocklist.

The Cloudflare integration powers the Edge Threat Radar. WASViking^® reads WAF, Firewall, and Bot signals from your Cloudflare account via the GraphQL API and correlates them with your open findings, amplifying the Risk Score when adversary traffic matches a real exposure.

This page is the canonical setup. It mirrors the WASViking Cloudflare Edge Security Integration Guide v1.2.

What this integration does

• Pulls Cloudflare WAF, Firewall, and Bot events at a 5-minute cadence.
• Correlates events to open Findings and amplifies the Risk Score.
• Enriches IPs with AbuseIPDB and ThreatFox.
• Powers the Edge Threat Radar dashboard, the AI assistant scoped to edge events, and multi-channel alerts.
• Optionally maintains a WASViking-managed dynamic IP blocklist in your Cloudflare account, with one important guardrail: no IP is blocked automatically. Each block is gated on explicit customer approval, per event.

Access posture

• Read-only by default. No traffic is intercepted, no rules are pushed, no DNS is changed.
• One exception: the optional dynamic blocklist needs an Edit scope on Account Filter Lists. It is used only to write IPs the customer has explicitly approved.
• Revocable at any time from the Cloudflare side (delete the API token).

Pre-requisites

Step 1 — Enable the required Cloudflare features

These three features must be on at the zone level. If any is off, the events WASViking reads will be empty.

1.1 WAF

Cloudflare Dashboard → select your domain → Security → WAF.

• WAF must be Enabled.
• Under Managed Rules, enable:
• Cloudflare Managed Rules
• OWASP Core Rule Set

1.2 Firewall Rules

Security → WAF → Firewall Rules.

• Confirm there is at least one active rule. If none exist, create a minimal log-only rule. Empty rule sets produce empty event streams.

1.3 Bot Protection

Security → Bot traffic → Settings.

Enable the best option available on your plan:

Step 2 — Create the API token

WASViking reads data via the Cloudflare API (GraphQL). Create a dedicated Custom Token, read-only except for the optional blocklist.

2.1 Create the token

• Cloudflare → My Profile → API Tokens → Create Token.
• Select Create Custom Token.

2.2 Account permissions

The Edit on Account Filter Lists is the only non-read scope. WASViking uses it solely to execute customer-approved IP blocks. Each block is preceded by an email notification with the event details and an explicit approve step. No IP is added without that.

2.3 Zone permissions

Do not grant any Edit scope you do not need. Least privilege wins.

2.4 Scope the token

Under Resources:

• Include → Specific Account → your account.
• Include → Specific Zones → only the domains you want monitored.

2.5 Create and save the token

• Click Continue to summary → Create Token.
• Copy the token immediately. Cloudflare does not show it again.

Step 3 — Configure on the WASViking side

In the portal:

Settings → Integrations → Cloudflare.

Click Test connection. WASViking verifies the token, the account binding, and each zone. A successful test enables the Edge Threat Radar dashboard within a few minutes.

What WASViking collects

Per Cloudflare event:

• Source IP.
• Country and ASN.
• Attack type.
• WAF rule triggered.
• URL attacked.
• Bot score.
• Action applied by Cloudflare (challenge, block, log).
• Timestamp.

Each event is enriched with AbuseIPDB and ThreatFox reputation, correlated to open Findings, and surfaced on the Edge Threat Radar dashboard.

Optional — Dynamic IP blocklist

This section is only needed if you want WASViking to push approved blocks back into Cloudflare. Skip it for read-only integrations.

4.1 Create the blocklist (Account Filter List)

Cloudflare → Security → Settings → IP Lists → Create List.

Click Create. The list appears with kind = ip and 0 records.

4.2 Create the security rule

Cloudflare → Security → Security Rules → Create rule → Custom rules.

Configure:

Click Deploy.

4.3 Allowlist the WASViking scanner IPs

To prevent accidental blocks during legitimate scans, add the WASViking scanner egress IPs to your WAF allowlist. Find the current list under Settings → Integrations → Cloudflare → Scanner IPs.

4.4 Approval flow (how blocks actually happen)

Edge event detected
        │
        ▼
WASViking risk amplification
        │
        ▼
Notification email to the operator (event details + approve link)
        │
        ▼
Operator approves in the portal
        │
        ▼
WASViking writes the IP to wasviking_edge_blocklist
        │
        ▼
Cloudflare custom rule blocks the IP at the edge

No IP reaches the blocklist without the operator step. The approve / reject decision is captured in the audit log on both sides.

Operating notes

• Cadence. WASViking polls every 5 minutes per zone.
• Backfill. On first connection, WASViking pulls the last 24 hours of events as initial baseline.
• Quota. The Edge module meters per monitored domain. See the Usage tab.
• Multi-zone. One token can carry multiple zones. Add or remove zone IDs in WASViking without re-issuing the token.

Common problems

Revoking the integration

• Soft revoke: in the WASViking portal, Settings → Integrations → Cloudflare → Disconnect. Reads stop; configuration is kept so you can reconnect later.
• Hard revoke: delete the API token in Cloudflare. WASViking shows an error on the next poll and stops trying. No data is retained beyond the configured event retention window.

Compliance posture

• Aligned with the principle of least privilege.
• All-read scopes by default; one optional Edit gated by explicit customer approval per event.
• Compatible with ISO 27001, LGPD, GDPR, NIST, OWASP Top 10 requirements for monitoring and audit.

Where this fits in the platform

• The capability lives at Edge Threat Radar.
• Risk amplification logic is documented under Findings and Risk Score.
• Alert routing is documented under Slack and Teams and Webhooks.