SOC 2 Cloudflare: WAF, TLS 1.2+, and DDoS Protection

Cloudflare in Your SOC 2 Boundary

Cloudflare sits in front of your web application as a reverse proxy, handling TLS termination, DDoS mitigation, WAF inspection, and bot management before traffic reaches your origin servers. For SOC 2, Cloudflare contributes controls in three areas: boundary protection (CC6.6), transmission protection (CC6.7 — TLS enforcement), and availability (A1.1 — DDoS protection). Cloudflare publishes a SOC 2 Type II report available at cloudflare.com/trust-hub.

Your responsibility is configuring Cloudflare correctly. Many companies proxy their domains through Cloudflare but leave default settings in place — TLS 1.0 still enabled, WAF in log-only mode, rate limiting not configured. These defaults create audit findings. This guide covers the specific settings that need to be changed.

TLS 1.2+ Enforcement (CC6.7)

Navigate to Cloudflare Dashboard → [your zone] → SSL/TLS → Edge Certificates → Minimum TLS Version. Set to TLS 1.2. This prevents clients using TLS 1.0 or 1.1 (which have known vulnerabilities including POODLE and BEAST) from connecting. TLS 1.0 and 1.1 were formally deprecated by the IETF in RFC 8996 (2021). Most SOC 2 auditors expect TLS 1.2 minimum; some newer frameworks require TLS 1.3.

Enable "Always Use HTTPS" under SSL/TLS → Edge Certificates → toggle "Always Use HTTPS". This redirects all HTTP requests to HTTPS automatically. Enable "HSTS" (HTTP Strict Transport Security) under Edge Certificates → HTTP Strict Transport Security (HSTS) → Enable HSTS. Set max-age to 12 months (31536000 seconds), enable "Include subdomains" and "Preload". HSTS prevents SSL stripping attacks and tells browsers to always use HTTPS for your domain.

Configure "Opportunistic Encryption" and "TLS 1.3" — enable both. Navigate to SSL/TLS → Edge Certificates and toggle both on. TLS 1.3 provides improved handshake performance and forward secrecy by default. Check your SSL certificate: navigate to SSL/TLS → Overview and verify your certificate is valid and auto-renewing. Screenshot this page monthly as evidence of certificate management (a C1.1 confidentiality control for data in transit).

WAF Configuration (CC6.6)

Navigate to Security → WAF → Managed rules. Enable the "Cloudflare Managed Ruleset" and the "OWASP Core Ruleset". The OWASP Core Ruleset covers the OWASP Top 10 web application risks: injection, broken authentication, XSS, IDOR, security misconfiguration, and others. Set the OWASP paranoia level to 2 (balanced) — level 1 misses attacks, level 3 generates too many false positives for most applications.

Set the default action for the Cloudflare Managed Ruleset to "Block" and the OWASP ruleset to "Managed Challenge" initially — this presents a challenge to suspected attack traffic rather than blocking outright, allowing you to monitor for false positives before switching to Block. After 30 days of monitoring, review the challenge logs and switch to Block for OWASP rules if false positive rate is acceptable.

Create custom WAF rules for your application. Navigate to Security → WAF → Custom rules → Create rule. Example rules: (1) Rate-limit login: `(http.request.uri.path contains "/api/auth/login") and (ip.geoip.country in {"CN" "RU"})` → Block. (2) Block user-agents associated with scanners: `(http.user_agent contains "sqlmap") or (http.user_agent contains "nikto")` → Block. (3) Require authentication header for API: `(http.request.uri.path contains "/api/v1/") and not (http.request.headers["Authorization"] ne "")` → Block. Document each custom rule in your WAF policy document.

DDoS Protection (A1.1)

Cloudflare's HTTP DDoS attack protection is enabled automatically for all zones and uses Cloudflare's network intelligence to detect and mitigate volumetric DDoS attacks. Navigate to Security → DDoS → HTTP DDoS attack protection → Override. Set the sensitivity to Medium (High may generate false positives for legitimate traffic spikes). Set the action to "Block" for confirmed attacks.

For A1.1 availability evidence, review DDoS event logs under Security → Events → filter by "DDoS mitigation". Export events for your audit period. Even if you had no DDoS events, the absence of events combined with DDoS protection being enabled is evidence that the control was operational. If you did experience DDoS events, the mitigation log shows that the attacks were automatically handled without service interruption.

Configure "Under Attack Mode" as a manual escalation option for severe attacks: Security → Settings → Security Level → I'm Under Attack. This mode presents a JavaScript challenge to all visitors, significantly reducing automated attack traffic. Document in your incident response runbook when and how to activate Under Attack Mode, and the expected customer impact (added latency for legitimate users). This demonstrates a documented availability response procedure for A1.1.

Rate Limiting for Brute Force

Create rate limiting rules for authentication endpoints. Navigate to Security → WAF → Rate limiting rules → Create rule. Rule: match `http.request.uri.path eq "/api/auth/login"`, count unique IPs, threshold: 10 requests per 60 seconds, action: Block for 10 minutes. This prevents brute force and credential stuffing attacks on your login endpoint.

Add a second rule for password reset: `http.request.uri.path eq "/api/auth/reset-password"`, threshold: 5 requests per 60 seconds per IP. Password reset endpoints are commonly abused for account enumeration — rate limiting them prevents automated enumeration. Export the rate limiting analytics monthly as CC7.2 evidence of attack detection and blocking.

Cloudflare Access for Internal Tools

Cloudflare Access (part of Cloudflare Zero Trust) places an identity-aware proxy in front of internal tools: Grafana, Kibana, internal admin panels, and staging environments. Navigate to Zero Trust → Access → Applications → Add an application. Configure your internal tool's hostname, connect your IdP (Okta, Google, Azure AD), and define access policies: only users in the "Engineering" group with a valid SSO session can access Grafana.

This eliminates the need for VPN access to internal tools, which simplifies your network architecture and provides per-application access logs. Cloudflare Access logs every access attempt with user identity, device, and timestamp. Export these logs via the Cloudflare Logpush feature to S3 for long-term retention as CC6.1 access control evidence for internal tools.

Audit Logs and Evidence

Cloudflare Audit Logs record all administrative changes to your Cloudflare account: zone configuration changes, firewall rule changes, user additions. Navigate to Account Home → Audit Log. Filter by date range and export to CSV. Key events to include in your SOC 2 evidence package: WAF rule modifications, TLS configuration changes, firewall rule changes, and user access additions/removals.

Enable Cloudflare Logpush to stream HTTP request logs, firewall events, and audit logs to S3 or your SIEM. Navigate to Analytics → Logpush → Add logpush job. Configure jobs for: Firewall Events (WAF hits, rate limiting events) and Audit Logs. Set destination to S3 with server-side encryption. Retain for 13 months. This automated log streaming provides continuous CC6.6 boundary protection evidence without manual exports.