operate
Live Posture Scan on Your Deployed URL
External header, TLS, cookie, and DNS checks against the running site.
What you get
Checks the running system, not just the code
A code scan cannot see a missing HSTS header, an expiring certificate, a soft SPF record, or a dangling DNS record that invites subdomain takeover. ZipLoom checks the live, deployed URL — the surface an attacker actually sees.
Header, TLS, cookie, DNS and email coverage
Security headers (HSTS, CSP, clickjacking, Referrer-Policy, COOP/COEP), TLS cipher grade and certificate expiry, cookie Secure/HttpOnly/SameSite flags, DNSSEC/CAA, subdomain-takeover exposure, and SPF/DKIM/DMARC — all passive and read-only.
Gate and auto-rollback on drift
The posture scan runs inside the deploy and monitor loop, so a critical drift (like an expired certificate) can gate the deploy or trigger automatic rollback. Findings you have already accepted never block.
How the posture scan runs
- 1
You deploy a project through ZipLoom.
- 2
After the deploy, ZipLoom runs external read-only checks against the live URL.
- 3
Findings are recorded against your project's posture history.
- 4
If a critical finding appears and is not already dispositioned, the deploy can roll back.
- 5
Ongoing monitoring re-checks posture and flags drift over time.
What this check inspects
The deployed application as a stranger sees it — not the repository, the running site.
Response headers, TLS, and cookie flags as actually served in production.
Publicly reachable endpoints, including debug and admin paths that were never meant to be exposed.
Whether error responses leak stack traces, framework versions, or internal paths.
What it means when this fails
Code can be clean while the deployment is not. Posture failures mean the gap is in what you shipped rather than what you wrote — a debug flag left on, a header the platform didn't set, an endpoint reachable without a session.
Questions
- Why scan the live app if the code already passed?
- Because the runtime differs from the repository: platform defaults, environment variables, and build settings all change what a visitor can reach.
- Is this an attack on my own site?
- It's a read-only posture check — it inspects what your app publicly returns. It does not attempt exploitation or modify data.
- Can I run it on a site not deployed by ZipLoom?
- Yes, the public scan works against any URL you control.
What it replaces
Checkly Starter
Synthetic API and Playwright browser checks. Team plan $64/mo for all regions.
Better Stack Uptime
Uptime monitoring, on-call and status pages. Tells you it broke; doesn't roll the release back.
Snyk Team
Per contributing developer, 5-seat minimum (~$1,500/yr entry). Code + dependency scanning; does not deploy your app.
ZipLoom Solo — all 28 features included
Deploy, security scan, and monitoring in one flat price. Guild $40/mo · Studio $70/mo · Business $299/mo.
Related features