PRACTICAL SECURITY GUIDANCE

Website security headers and HTTPS checks

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

What CyberScan can establish

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.

What do HTTPS and security headers tell you?

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)

Turn one observation into an answerable task

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.

Four practical steps

  1. Define the asset and permission. Name the hostname and business service. Confirm who can authorise assessment and who controls the web, hosting and CDN configuration.
  2. Keep the observation and its limits. Save the dated result, the response scope and unavailable checks. Distinguish a missing header from a verified application vulnerability.
  3. Plan and test the change. Ask the responsible maintainer to review the policy, test important journeys and agree a rollback route. Avoid copying a generic policy into production.
  4. Retest and retain evidence. Repeat the relevant check after deployment. Record the observed value, application test outcome, remaining exceptions and next review date.

Worked example: A missing Content Security Policy

Synthetic worked example. This is an illustrative workflow, not a customer case or the result of a live scan.

Synthetic worked example: A missing Content Security Policy
StageEvidence and decision
ObservationAn authorised homepage response does not contain a Content-Security-Policy header. The public report records that response and date.
What remains unknownThe observation does not prove that an injection vulnerability exists. Other pages, application behaviour and alternative controls have not been assessed.
Owner and actionThe developer inventories required resources and designs a policy. A report-only trial can help investigate violations before an enforcing change, where appropriate.
Evidence for closureRetain the deployed policy, a new response observation and successful tests of the site’s important journeys. Record unresolved exceptions with an owner.

Website control evidence log

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 template

Open 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.

Common questions

Can I run a website check without a scanner API key?

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.

Does a successful HTTPS check prove that my certificate configuration is complete?

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.

Should I enable HSTS for every subdomain immediately?

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)

Is a header score a penetration test?

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: NCSC: Penetration testing (opens in a new tab)

Primary 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)NCSC: Penetration testing (opens in a new tab)

Sources checked . Check the linked guidance and your provider’s current instructions before changing a live service.

Choose your next step

Compare public observations with the supported connected scanner modes before you start.

Choose a website security check

Email security

Check 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 security