Vulnerability management
Turn a scanner finding into an owned remediation task. Check asset attribution, vendor evidence, business impact and the result of a suitable retest.
Explore vulnerability managementPractical cyber security for UK businesses.
https://cyberscan.me.uk
A website security check is useful when it answers a defined question. Start with the hostname, the response observed and the control being checked. Use the result to decide who should investigate, which change is appropriate and how to verify it. A successful public check is evidence about its stated tests at that time.
PUBLISHED
CyberScan’s public check requires sign-in, permission confirmation and proof of control of the exact hostname. It observes public DNS, HTTPS connectivity, the initial HTTP redirect and selected security headers, alongside email-related DNS records. It does not inspect application code, sign in to the target, test exploits or ports, check malware, or provide complete certificate and TLS analysis.
Compare the assessment routes and their coverage, or read how the current application handles data.
HTTPS protects the connection between a browser and the endpoint it reaches. A successful request does not establish the security of every connection behind that endpoint. If a CDN or reverse proxy serves your website, ask the provider separately about protection between that service and the origin. CyberScan’s baseline does not measure certificate expiry or enumerate supported ciphers.
Security headers instruct browsers about specific behaviour. HSTS tells a browser to use HTTPS for future requests. Content Security Policy can restrict resources and other browser actions. X-Content-Type-Options reduces MIME type guessing, while Referrer-Policy controls which referring-page information is sent with requests. Presence is a starting observation: a policy must suit the application and behave as intended.
Sources: MDN: Transport Layer Security (opens in a new tab); MDN: Strict-Transport-Security (opens in a new tab); MDN: Content Security Policy (opens in a new tab); MDN: X-Content-Type-Options (opens in a new tab); MDN: Referrer-Policy (opens in a new tab)
Record the exact page or hostname, the check date, the response received and any redirect or access limitation. Identify whether the application team, hosting provider or CDN controls the response. The same-looking header may be set at more than one layer, so agree where the change belongs before altering configuration.
Keep the original finding alongside the change request. Describe the intended outcome and the journeys that must keep working, such as sign-in, a booking form or embedded payment. A fresh response can show that a header changed; checks of those journeys establish whether the change is usable. Keep an unavailable or blocked retest open rather than treating missing evidence as completion.
Synthetic worked example. This is an illustrative workflow, not a customer case or the result of a live scan.
| Stage | Evidence and decision |
|---|---|
| Observation | An authorised homepage response does not contain a Content-Security-Policy header. The public report records that response and date. |
| What remains unknown | The observation does not prove that an injection vulnerability exists. Other pages, application behaviour and alternative controls have not been assessed. |
| Owner and action | The developer inventories required resources and designs a policy. A report-only trial can help investigate violations before an enforcing change, where appropriate. |
| Evidence for closure | Retain the deployed policy, a new response observation and successful tests of the site’s important journeys. Record unresolved exceptions with an owner. |
A blank CSV for the asset, observation, responsible owner, approved change and retest result. Complete it locally and keep credentials and unnecessary personal information out of the record.
Download blank CSV templateOpen in a spreadsheet application and replace the blank-entry rows with your own records. The template contains no findings, formulas or macros. Completing it does not upload it to CyberScan.
The public-baseline mode in CyberScan’s protected workspace does not require a scanner API key. Existing authorised workspace access, sign-in, permission confirmation and domain-control verification are required. The result covers the defined public observations, and all checks run on demand.
No. The baseline establishes whether its HTTPS request succeeded. It does not provide a certificate-expiry, full chain or cipher assessment. Use a suitably scoped TLS assessment when those are the questions you need answered.
Review the domain estate and deployment implications first. The includeSubDomains directive extends the policy to subdomains, so an unsuitable change can affect services beyond the page you tested. Ask the responsible provider to check readiness and recovery implications.
Sources: MDN: Strict-Transport-Security (opens in a new tab)
No. A header check observes selected response settings. A penetration test is a separately scoped assessment using techniques intended to investigate exploitable weaknesses. Choose the assessment that answers your actual question.
Sources checked . Check the linked guidance and your provider’s current instructions before changing a live service.
Compare public observations with the supported connected scanner modes before you start.
Choose a website security checkTurn a scanner finding into an owned remediation task. Check asset attribution, vendor evidence, business impact and the result of a suitable retest.
Explore vulnerability managementCheck the meaning of SPF, DKIM and DMARC observations. Find the correct DKIM selector, map legitimate senders and plan a controlled email policy change.
Explore email securityReview the accounts, backups and dependencies behind your business. Build a practical security action plan and keep evidence of recovery exercises.
Explore business resilience