Loading…
Loading…
Squarespace sites
Squarespace handles HTTPS certificates automatically, but it does not expose controls for browser security headers like HSTS, CSP, or X-Frame-Options. Those must be added at a CDN layer in front of your connected domain. They are invisible from inside the Squarespace editor. Sites that look polished in preview can still score poorly on the headers browsers actually enforce.
Paste your live site URL, primary domain or connected hostname. Scorifya summarizes HTTPS posture and redirects, headers returned with your HTML edge response, passive SPF/DMARC/MX lookups for your domain, and hygiene cues, without signing into your site builder. Results in under 30 seconds.
This page is written for people searching for Squarespace 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 domain sends mail but DNS lags
Visitors see TLS working, yet passive mail authentication signals remain incomplete, a frequent gap after launching newsletters.
DMARC record missing
SPF might exist while DMARC stays unpublished, spoofed mail using your domain remains harder to detect for receivers.
Legacy TLS accepted
Older TLS versions sometimes linger at shared edges; retiring them improves posture for visitors on modern browsers.
Framing protections absent
If embed-heavy landing pages rely on partner iframes, confirm anti-framing headers still match how your templates behave.
Example B, tighter DNS plus stronger headers
HTTPS and headers align with visitor expectations while mail DNS catches up, remaining notes tend to be hygiene polish.
DMARC still monitoring-only
Policies starting at 'none' are normal, advance toward enforcement once legitimate mail streams authenticate cleanly.
Verbose fingerprint hints
Small hygiene deductions remind teams to strip noisy banners during periodic reviews, not usually urgent.
Add HSTS via Cloudflare in front of your connected domain
Squarespace does not send Strict-Transport-Security natively. Route your custom domain through Cloudflare and add the HSTS header there. A one-year max-age with includeSubDomains is a good baseline.
Set CSP at your CDN, not inside Squarespace
Squarespace offers no way to set arbitrary response headers in its editor. Add Content-Security-Policy at a proxy layer. Squarespace loads scripts from its own CDN and any embedded widgets, list those sources before writing the policy.
Verify DNS where Squarespace points mail
After connecting domains or third-party mailers for newsletters, SPF and DMARC must reflect actual sending sources. A missing DMARC record lets anyone spoof your domain in email.
Scan your connected domain, not the .squarespace.com preview
TLS certificates and DNS records only exist on your connected custom domain. Preview subdomains reflect Squarespace's defaults, not your edge or DNS configuration.
Rescan after every DNS or domain change
Squarespace DNS edits propagate unevenly; rerun the scanner once TTLs expire so TLS and MX snapshots match reality.
For weights and penalties behind each category, see How Scorifya works.
Squarespace's hosting infrastructure is reliable and handles TLS certificates automatically. However, Squarespace does not give users control over browser security headers like HSTS, CSP, or X-Frame-Options. Those must be added at a CDN or proxy layer in front of your connected domain. A Squarespace site can be made secure, but it requires configuration outside the Squarespace editor.
Not natively. Squarespace serves HTTPS but does not send a Strict-Transport-Security header by default. To add HSTS you need to front your connected domain with a CDN like Cloudflare that injects the header on every response. Without it, browsers cannot enforce HTTPS-only connections on return visits.
Squarespace does not expose a way to set arbitrary response headers inside its editor. The most reliable approach is to proxy your site through a CDN that adds the CSP header. Squarespace embeds third-party scripts for analytics and widgets, 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, incomplete SPF/DMARC records when the domain sends newsletters, and legacy TLS versions at shared hosting edges. These are edge-layer gaps, not Squarespace platform vulnerabilities. They're fixable with a CDN proxy in front of your connected domain.
No. We fetch only your public URL and passive DNS contexts documented on our methodology page, never authenticated dashboard views.
Only if the URL is reachable without credentials. Password-protected or staging URLs stay out of scope.
Certificates, redirects, and headers can diverge between hostnames even when pages look identical. Scan both when unsure.
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.