What a free first look can and cannot see

Zoltra's free first look is a measurement, not a verdict. It looks at what a public website exposes and reports what it can prove. Knowing the boundary is what makes the result usable, so we publish it.

What the scan does

The first look makes ordinary, non-invasive requests to a public site and reads what comes back. Every check is observable from outside the application:

• Transport and certificate. Which TLS protocol versions the server offers, and whether the certificate chain is valid and current.
• Response headers. Whether the baseline security headers are present — including Strict-Transport-Security and Content-Security-Policy — and whether cookies carry the flags that keep them out of the wrong hands.
• Publicly exposed material. Whether well-known paths serve files that should never be public, and whether configuration is exposed that should not be.
• Email authentication records. Whether SPF, DMARC and CAA records exist for the domain, since those decide who can send mail as you.
• Search and AI readiness. Whether the site tells crawlers what it wants, and whether it can be read by the tools people now use to find things.
• Page experience. Core Web Vitals measured on a real render.

What the scan cannot see

This is the part that matters most, because a clean first look is easy to misread.

• It cannot see anything behind a login. A scan runs as an anonymous visitor. An application that is entirely authenticated has almost no public surface for us to measure.
• It cannot read your source, your environment, or your database. We do not have them. A leaked credential is only visible to us when it has already become public — for example, when a secret ends up in a client bundle.
• It cannot prove the absence of a vulnerability. Every finding we report is something we observed. The absence of a finding means the checks that ran passed; it does not mean the application is secure.
• It cannot judge business logic. Whether one account should be able to read another account's data is decided by your authorization rules, not by anything visible from outside.
• It cannot keep scanning by itself. A first look is a point-in-time measurement. A site that changes tomorrow needs measuring tomorrow.

How to read a score

The score is a weighted ratio of checks that passed, with the weights fixed per category so the number means the same thing on every site. Two consequences follow from that:

• A high score with a critical finding is still a high score in arithmetic and a bad result in practice. Read the findings, not the number. A missing header and an exposed credential are not the same severity, and the score does not pretend they are.
• A low score on a small site is not a catastrophe. A static marketing page with no login, no database and no user input genuinely has less to get wrong.

What to do with the result

1. Fix the highest-severity finding first, not the easiest one.
2. Re-scan after the fix. A finding is resolved when the live site proves it is resolved, and the dashboard shows that state rather than our intention.
3. Read the explanation, not just the title. Each finding states what was observed and what it means for this site.

Why we publish the limits

A security tool that only advertises what it finds trains people to believe a green result means safety. That belief is the actual risk — it is what stops somebody checking the thing the scan could not see.

We would rather hand you a measurement with a stated boundary than a verdict you cannot audit.