What does your website look like from the outside?
Every prospect asks it sooner or later. Now you can answer it in the first meeting, for each client's websites, with the header, status line or certificate field behind every finding. The checks stay inside a deliberately narrow boundary: what any browser can see, and nothing more.
Walk in with evidence, not an opinion.
A client's website is the part of their estate the whole internet can see. Web Exposure turns that into a concrete, evidenced view per site, so the conversation starts from what is actually served rather than from a generic checklist.
Answer it in the room
Add a client's website and run a scan on request. After that it is checked every 24 hours, and you can ask for a fresh scan at most once every 10 minutes.
Evidence in every finding
Each finding quotes the header, status line or certificate field that triggered it and carries its remediation. The technician knows what to change, and the client can see why.
One grade per site
Each website carries a grade from A to F, derived only from its open findings. A summary a client understands, backed by findings a technician can act on.
It checks what any browser sees. Nothing more.
The passive tier is defined by what it will not do. That is what makes it reasonable to run against a site you do not host, and easy to explain to the client who owns it.
Websites are only ever checked once someone adds them. Candidates are suggested from the client's website field, certificate monitors and dark-web domains, and are never added on their own.
TLS and HTTP findings, each with its evidence.
The findings are the ones a web server or CDN configuration actually fixes. Missing security headers arrive as one grouped finding, because they are fixed with one configuration change and five separate risks would bury the register.
- Certificates: expired or expiring within 14 days, a certificate that does not name the host, an untrusted chain, a weak key
- Protocols: legacy TLS still accepted, HTTPS refused while HTTP serves content, no redirect from HTTP to HTTPS
- Security headers: HSTS and its max-age, Content Security Policy, clickjacking protection and nosniff, as one grouped finding
- Cookies set without Secure, and session cookies set without HttpOnly
- Version numbers disclosed in the Server or X-Powered-By header, recorded as an informational note
- Every finding quotes the header, status line or certificate field that triggered it, and says how to fix it
Scored like every other risk. Never muted by hostname.
Each finding above informational becomes a risk with its own source, External scan, keyed to the website and the check so it never duplicates. It is scored like every other risk in the platform, and it reopens if the finding comes back.
No daily flapping
A finding has to be absent from two consecutive scans before it resolves, so a WAF, a maintenance page or a cache miss cannot open and close a risk every day.
Dismissals stay honest
A risk marked false positive stays dismissed unless the finding recurs under a newer version of the check. Sharpening a check re-evaluates the old dismissals.
No hostname allowlist
Nothing is ever suppressed by hostname. A site cannot quietly drop out of view because someone found it noisy once.
Deeper checks, only with proof of control.
Some exposures only show when you ask for a path the site never linked to, such as an exposed .git folder or a forgotten backup. Asking for those is exactly what consent exists for, so this tier is gated twice: the client proves control of the domain, and platform staff switch the probes on for that client. It is off by default.
- Proof of control by a DNS TXT record, which covers every subdomain, or by a file in the site's well-known folder
- Re-checked every 30 days. After two failed re-checks in a row the site drops back to passive checks, and its page says why
- Every verification is audited, together with the method used
- Each probe confirms an exposure by its content, never by a status code. A host that answers every path with 200 is recorded as such rather than flagged
- At most 40 requests per scan, one GET or POST each, and no payloads
- The contents of an exposed file are never stored: only that it was served, its size, and a first line with every value masked
Weak evidence is labelled as weak evidence.
A version banner and a port list are useful context, but neither is as strong as what an agent reads from inside a device. The platform treats them accordingly.
Banner versions, capped at needs review
A version a site discloses in its generator tag, Server or X-Powered-By header is matched to CVEs with the same rules the device engine uses. The match is capped at needs review and never accepted automatically, and capped lower still when the banner names a distribution build whose vendor may have backported the fix.
Exploited CVEs are never hidden
A banner match below the review threshold stays a finding without a risk, unless the CVE is known to be exploited or its EPSS score is high. Those always surface, titled as possibly vulnerable and quoting the banner.
Ports, without a port scan
Each site shows which ports the internet can reach on its address, taken from the Shodan data the threat feed already collects. The platform never port-scans. When the address belongs to a CDN, the page says so and shows no ports, because they would be the CDN's. Without a Shodan key, the card says what to configure.
From one site to the whole portfolio.
The findings do not stay on a scanner page. They reach the reports your clients read and the view you run your portfolio from.
- Risk summary and executive summary reports carry a Web Exposure table: site, grade, tier and open findings by severity
- The partner portfolio has a Web column showing each client's worst grade
- Certificate monitoring defers to the website check for the same hostname, so one expiring certificate is one risk, not two
- Switched on per client. Switching it off stops the scans, and the findings and settings are kept until it is switched on again
Common questions
Is this a penetration test?
No. A penetration test tries to break in, within an agreed scope. Web Exposure checks what any browser or TLS client can already see, and in the verified tier requests a fixed list of paths that should never be public. It never sends a payload, never submits a form and never authenticates.
Will it trip our WAF or put load on the site?
The passive tier makes at most six requests per site per day, waits a second between them and identifies itself. If the site answers 429 or 503, it stops for the day. A WAF or maintenance page cannot make findings flap either, because a finding needs two clean scans in a row to resolve.
Do we need the client's permission?
The passive tier checks only what any browser sees on a hostname the client publishes. The verified tier is different: it requests paths the site never linked to, so it requires proof that the client controls the domain, by DNS record or a file on the site, and platform staff switch it on per client. Agreeing the scope with your client up front is good practice either way.
Which websites are checked?
Only the ones you add. The platform suggests candidates from the client's website field, certificate monitors and dark-web domains, but never adds a site on its own.
Does it replace the agent?
No. The agent sees a device from the inside; Web Exposure sees a client's published websites from the outside. Both feed the same risk register, scored the same way.
How is it licensed?
Web Exposure is included in Standard, with 5 websites per client. Additional websites carry a small monthly fee, listed on the pricing page. It is switched on per client, so you decide which clients it runs for.
Bring the outside view to your next client meeting.
We walk you through Web Exposure live: the boundary, the findings with their evidence, and how they reach client reports and your portfolio.