Loading…
Loading…
Webflow sites
Webflow handles hosting reliably, but it does not set HSTS, CSP, or most security headers by default, those gaps live at the edge layer and are invisible inside Designer. Sites that look finished in the preview can still score poorly on the headers browsers actually enforce.
Paste your production hostname, custom domain or webflow.io subdomain, and Scorifya checks HTTPS/TLS, security headers (HSTS, CSP, X-Frame-Options, and more), passive SPF/DMARC/MX signals, cookie attributes, and hygiene cues. No Designer access needed. Results in under 30 seconds.
This page is written for people searching for Webflow security check, same tool as the homepage, with context for that query.
How we differ from deep TLS graders, browser-focused posture tools, and header-only checkers: read the comparison.
Illustrative snapshots of what a report can look like. Paste your URL above for a live score on your site.
Example A, marketing site after embed-heavy launch
Animations and third-party scripts load, but CSP and framing controls often trail feature velocity, costing header points.
Content-Security-Policy missing
Marketing stacks with many embeds postpone CSP. Scorifya flags the gap so you can stage report-only policies early.
Strict-Transport-Security absent
HTTPS may work while first-visit downgrade windows remain until HSTS is served consistently on the apex and subdomains you use.
Mixed mail authentication
Brands often publish sites before SPF/DMARC catch up with newsletter tools, passive DNS highlights the mismatch.
Example B, tuned edge after iterative deploys
Redirects, TLS, and core headers match what production traffic should see; remaining work is tightening allowances or finishing mail DNS.
CSP still allows broad script hosts
A policy exists but whitelists large CDNs. Iterate as you consolidate vendors.
Optional transport reporting for mail
When MX exists, MTA-STS and TLS reporting are additive. Scorifya notes their absence when relevant.
Add HSTS via a CDN in front of Webflow
Webflow doesn't send Strict-Transport-Security natively. Route traffic through Cloudflare or another CDN and add the header there. A one-year max-age with includeSubDomains is a solid starting point.
Inventory your embeds before writing a CSP
Webflow sites typically load scripts from Webflow's CDN, Google Fonts, and any form or analytics tools you've added. List every source first, then write the CSP policy at your proxy layer to allow exactly those origins.
Set up SPF and DMARC before you send any email
If your Webflow domain also sends transactional or marketing email, publish SPF and DMARC records before launch. A missing DMARC record lets anyone spoof your domain in email.
Scan your custom domain, not the webflow.io preview
TLS certificates, DNS records, and any proxy headers only exist on your production domain. Preview subdomains reflect Webflow's defaults, not your edge configuration.
Re-scan after every DNS or proxy change
Header configuration lives at the edge layer, so changes take effect immediately. Run a new scan after any CDN rule or DNS update to confirm it landed correctly.
For weights and penalties behind each category, see How Scorifya works.
Webflow's hosting infrastructure is reliable and handles TLS certificates automatically. However, Webflow does not set most browser security headers (HSTS, CSP, X-Frame-Options, Permissions-Policy) by default. Those must be added at a proxy or CDN layer in front of your site. A Webflow site can be made secure, but it requires configuration beyond what Designer provides out of the box.
Not natively. Webflow serves HTTPS but does not send a Strict-Transport-Security header by default. To add HSTS to a Webflow site you need to front it with a proxy or CDN (such as Cloudflare) that injects the header on every response. Without it, browsers cannot enforce HTTPS-only connections on return visits.
Webflow does not expose a way to set arbitrary response headers inside Designer. The most reliable approach is to proxy the site through a CDN or edge layer that adds the CSP header. Note that Webflow embeds third-party scripts for interactions and forms, so any CSP policy needs to allow those sources.
The most common findings are: missing HSTS header, no Content-Security-Policy, absent X-Frame-Options (clickjacking risk), incomplete SPF/DMARC records when the domain sends email, and verbose server banners. These are edge-layer gaps, not Webflow platform vulnerabilities. They're fixable with a proxy or CDN in front of the site.
No. Only the public URL is requested. Anything behind authentication remains invisible to passive checks.
Whichever hostname your audience loads in production. TLS and DNS records differ, so scan both if you operate both publicly.
Scorifya requests the exact URL you paste. Other paths or subdomains may send different headers until you normalize them upstream.
More detail on limits and billing: FAQ.
TLS, HTTPS & redirects
Valid certificates, modern TLS, and clean HTTP→HTTPS upgrades. We also probe whether legacy TLS 1.0/1.1 are still accepted.
Security headers
CSP, HSTS, and related headers reduce common browser-side attack surfaces and clickjacking risk.
DNS & email (passive)
SPF, DMARC, a few DKIM selectors, MX, and whether common subdomains resolve publicly, without port scanning.
Hygiene signals
Verbose server banners and risky defaults can raise your attack surface and erode trust.
Not a vulnerability scan
Scorifya checks public configuration signals; it does not attempt exploitation, port scans, or authenticated crawling.
If you're iterating on config or deploying changes, you'll likely run multiple checks as you tighten things up. When you're ready, Scorifya Pro removes scan limits and unlocks JSON/CSV/PDF exports.