Cloudflare Application Security cheat sheet

Same-origin policy compares scheme, host, and port; any mismatch makes a request cross-origin and subject to CORS preflight or blocking.

CORS response headers Access-Control-Allow-Origin, -Methods, and -Headers govern browser reads; the server, not the browser, decides whether to include them.

TLS terminates at the edge in a proxied setup, so origin traffic can be re-encrypted with Full (strict) mode, which validates the origin certificate chain.

HTTP response headers that reduce attack surface: Content-Security-Policy, X-Content-Type-Options: nosniff, and Strict-Transport-Security with max-age.

Reflected XSS echoes input in the response; stored XSS persists server-side; DOM XSS is caused by client-side sinks such as innerHTML without sanitization.

CSRF exploits ambient cookies; SameSite=Lax or Strict plus a per-session token blocks cross-site form posts that lack the token.

SQL injection arises when input is concatenated into queries; parameterized statements separate code from data and are the primary control.

HTTP request anatomy for inspection: method, path, query string, headers, cookies, and body; WAF rules can match any of these fields.

Volumetric attacks are measured in bits per second, protocol attacks in packets per second, and application-layer attacks in requests per second; each needs a different mitigation.

Anycast spreads an attack across many edge locations so no single datacenter absorbs the full flood; traffic is scrubbed near its source.

SYN flood defense relies on SYN cookies and connection state kept at the edge rather than on the origin server.

DNS amplification abuses open resolvers and spoofed source IPs; response size divided by request size is the amplification factor.

Rate limiting at the edge caps requests per client per interval; it is the main lever against HTTP flood and credential-stuffing bursts.

L3/L4 DDoS protection is always-on and automatic for proxied records; L7 rules are configurable and evaluated per request.

Origin IP leakage defeats edge protection; keeping the origin address hidden and firewalling it to edge ranges preserves mitigation.

Caching static and cacheable responses absorbs repeat requests before they reach the origin, lowering the effective attack surface.

WAF rule phases run in order: managed rules first, then custom rules, then rate limiting; the first terminating action stops evaluation.

Managed rulesets are scored by anomaly detection in OWASP Core Ruleset; a paranoia level raises sensitivity and false positives together.

Actions available to a rule: block, challenge, js_challenge, managed_challenge, log, and skip; skip exempts matching requests from later rules.

A custom rule expression combines fields with and/or/not; example: http.request.uri.path contains "/admin" and ip.src ne 203.0.113.7.

WAF runs after DDoS mitigation and before the origin, so blocked requests never consume origin capacity.

Sensitivity levels for managed rules trade detection for false positives; lowering sensitivity reduces blocks on benign traffic.

Rule preview or log-only mode records matches without blocking, letting you measure impact before enforcement.

Body inspection is bounded by a configurable size limit; content beyond the limit is not evaluated by body-matching rules.

Bot scores range from 1 to 99; lower scores indicate automated traffic, higher scores indicate likely human traffic.

Detection signals include JA3/JA4 TLS fingerprints, HTTP/2 fingerprint, header order, IP reputation, and behavioral analysis.

Verified bots are allowlisted by category; known good crawlers are distinguished from spoofed user agents by validation.

Actions for bot traffic: allow, block, challenge, js_challenge, and managed_challenge; managed challenge picks a challenge the client can pass.

Static resource protection shields cached assets such as images and scripts that would otherwise bypass bot checks.

Bot management is enforced at the edge before origin; unmitigated automated requests can drive credential stuffing and scraping.

JavaScript detections run a small script to distinguish real browsers from headless clients; they are not a substitute for fingerprinting.

Heuristic detection identifies anomalies such as high request rates from one IP or unusual user-agent and header combinations.