Securing a Cloudflare Pages site is mostly about reducing exposure at every layer: DNS, access, build pipeline, headers, and secrets.
This guide shows the most effective controls and why they matter, including a few Cloudflare-specific settings that are easy to miss.
Why Cloudflare Pages security deserves a layered approach
Cloudflare Pages is a static site and JAMstack platform, but “static” does not mean “safe by default.” Your site can still leak data through misconfigured routes, exposed environment variables, weak custom domain settings, insecure third-party scripts, or a compromised Git provider.
The right model is defense in depth.
Treat the public site, the deployment pipeline, and the developer workflow as separate attack surfaces.
If one layer fails, the others should limit damage.
Lock down access to the Pages project
Start with the project itself.
Only people who need to deploy or manage the site should have access to the Cloudflare account and the connected Git repository.
- Use Cloudflare account roles with least privilege.
- Protect GitHub, GitLab, or Bitbucket accounts with multi-factor authentication.
- Restrict repository access to approved maintainers.
- Review connected integrations and remove unused OAuth apps or service accounts.
If you use deployment previews, remember that preview URLs are publicly reachable unless you add controls.
Do not assume a preview environment is private just because it is not linked from the main navigation.
Use custom domains carefully
A Cloudflare Pages site often becomes more secure once it is placed behind a properly managed custom domain.
This lets you enforce HTTPS, control DNS, and standardize security policy with Cloudflare features such as WAF, SSL/TLS settings, and security headers.
Keep these practices in place:
- Enable HTTPS for all traffic.
- Redirect HTTP to HTTPS.
- Use Cloudflare DNS rather than exposing origin records directly.
- Remove unused subdomains that could be taken over later.
- Audit CNAME and A records for stale entries.
Subdomain takeover risk is especially important if your domain has many old services, test sites, or abandoned marketing pages.
Any record that points to a deprovisioned host should be cleaned up.
What is the best way to protect preview deployments?
Preview deployments are convenient for QA, content review, and collaboration, but they can also expose unfinished content or internal notes.
The best way to secure them is to treat them as semi-public unless you add explicit access restrictions.
Common options include:
- Use Cloudflare Access to require identity-based login.
- Put previews behind a separate authenticated environment.
- Use obscure but not secret URLs only as an additional layer, not the main control.
- Limit what data is rendered in preview builds.
If your workflow publishes sensitive drafts, test files, or temporary API responses, make sure those paths are excluded from preview builds and never shipped to the browser.
Harden your build and deployment pipeline
The Git-to-deploy chain is one of the most important parts of how to secure a Cloudflare Pages site.
A compromised repository, build script, or dependency can inject malicious code into every deployment.
Focus on these controls:
- Require pull requests and branch protection on the main branch.
- Enforce code review for production changes.
- Pin dependency versions where practical.
- Audit package-lock.json, yarn.lock, or pnpm-lock.yaml changes.
- Review build scripts for unsafe shell commands.
Static site generators, frontend frameworks, and bundlers frequently run install hooks and postinstall scripts.
These are useful, but they also expand your attack surface.
Keep dependencies minimal and remove packages that are no longer needed.
Manage secrets so they never reach the browser
Secrets management is a major part of securing Cloudflare Pages because frontend projects often mix public configuration with private credentials.
Anything bundled into client-side JavaScript should be assumed public.
Follow a strict rule: only non-sensitive values belong in client-visible variables.
API keys, database credentials, private tokens, and signing secrets should stay server-side or in protected build-time settings only when the vendor explicitly supports that use case.
- Store secrets in Cloudflare Pages environment variables, not in source code.
- Separate production, preview, and development values.
- Rotate any secret that has been committed to a repository.
- Use short-lived tokens when available.
- Scan repositories for leaked credentials before every release.
Also review your framework conventions.
Some tools expose variables with prefixes such as PUBLIC_, VITE_, or NEXT_PUBLIC_.
Those prefixes usually indicate browser exposure, so do not place sensitive values there.
Set security headers on every response
Security headers reduce browser-side risk and are one of the easiest wins for a static site.
They help prevent MIME sniffing, clickjacking, and some forms of cross-site scripting impact.
At minimum, consider these headers:
- Content-Security-Policy
- Strict-Transport-Security
- X-Content-Type-Options
- X-Frame-Options or frame-ancestors in CSP
- Referrer-Policy
- Permissions-Policy
Of these, Content-Security-Policy is often the most important and the most nuanced.
A strong CSP can restrict scripts, images, fonts, connections, and frames to trusted sources.
Start with a report-only policy if your site has many third-party assets, then tighten it once you verify that nothing breaks.
For HSTS, use it only after you are sure every subdomain should be served over HTTPS.
Once enabled with a long max-age, it is sticky in browsers.
Reduce third-party risk
Many Cloudflare Pages sites depend on analytics, chat widgets, CDNs, fonts, maps, or payment scripts.
Every external dependency is a trust decision.
If one vendor is compromised, your site can become compromised too.
Minimize risk by doing the following:
- Self-host assets when practical.
- Load only essential third-party scripts.
- Use Subresource Integrity for static external files when possible.
- Review vendor privacy and security posture.
- Remove inactive tags from analytics or tag managers.
If you use a tag manager, remember it can become a high-risk insertion point.
Limit who can edit it and audit changes regularly.
Use Cloudflare access controls for private areas
If your Pages site contains internal documentation, staging content, or partner-only pages, Cloudflare Access can add identity-aware protection in front of the site.
This is stronger than relying on obscurity or a shared password.
Access policies can require login with an identity provider such as Google Workspace, Microsoft Entra ID, Okta, or another supported source.
You can scope access by email address, group, device posture, or other rules depending on your setup.
This is especially useful for:
- Admin panels
- Staging documentation
- Customer portals
- Internal design reviews
- Private release notes
Monitor for changes and anomalies
Security is not a one-time setup.
Once the site is live, monitor for changes in DNS records, access policies, deployment history, and repository activity.
Small changes often reveal larger problems early.
Watch for:
- Unexpected deployments
- New collaborators or API tokens
- Changes to DNS or proxy settings
- Repeated failed login attempts
- Traffic spikes to preview URLs
- Script changes in the compiled output
If your site handles user input through forms or API endpoints, review logs for abuse patterns, spam submissions, or unusual referrer traffic.
Even simple static sites can become attack targets once they accept data.
Sanity-check your site before every release
A repeatable release checklist is one of the best ways to secure a Cloudflare Pages site over time.
It prevents “temporary” shortcuts from becoming permanent weaknesses.
- Confirm the correct branch is deployed.
- Verify all secrets are still valid and not exposed.
- Check that security headers are present.
- Test HTTPS and redirect behavior.
- Review preview access rules.
- Scan dependencies for known vulnerabilities.
- Confirm third-party scripts are still necessary.
For teams with frequent releases, automate as much of this as possible.
Linting headers, scanning dependencies, and checking environment variable usage in CI can catch issues before they reach production.
Common mistakes to avoid
Most security problems on Cloudflare Pages come from a few repeatable mistakes.
Avoid these and you will eliminate a large share of preventable risk.
- Storing secrets in client-side code
- Leaving preview deployments open to everyone
- Ignoring dependency warnings
- Using weak or missing security headers
- Forgetting to protect Git accounts with MFA
- Leaving abandoned DNS records active
- Loading unnecessary third-party scripts
Strong security on Pages is less about complex infrastructure and more about disciplined defaults.
If you control access, protect secrets, harden headers, and review deployment changes, the platform is very secure for most static and frontend workloads.