Practical technical support
Understand a public website security check
Use observable evidence to choose a sensible next check. A green header badge cannot establish that a whole website is secure.
Last reviewed:
What we can observe
The website security checker reads one public response and the site’s crawl instructions. It checks the final connection, selected HTTP headers and a bounded set of resource references and form actions in returned HTML. It does not sign in, submit forms, execute website scripts or test an exploit.
HTTPS is necessary evidence, not a safety verdict
A verified certificate helps establish an encrypted connection to the requested hostname. A malicious website can also use HTTPS. Our check does not audit TLS configuration across protocols, determine the operator’s honesty or inspect private application data.
HSTS is a separate browser instruction to prefer HTTPS after learning the policy. Start with working HTTPS before adding a long HSTS lifetime. Including subdomains or requesting preload can affect services beyond the page you are editing; do not copy a policy without checking that coverage.
Match the control to its purpose
| Control | Useful question |
|---|---|
| Content Security Policy | Does the policy limit the sources the application genuinely needs? Presence alone does not show that it blocks the relevant attack. |
| Framing restrictions | Should this page be embedded? Review CSP frame-ancestors and any X-Frame-Options header against that intention. |
| nosniff | Are resource types served correctly, with a matching browser instruction against MIME sniffing? |
| Referrer policy | How much URL information should a destination receive? Browser defaults, meta policies and individual links also matter. |
| Permissions Policy | Which browser features does this page need? A camera tool must retain the permissions needed to work. |
Read mixed-content findings in a browser
An HTTP image or form destination in an HTTPS document is worth investigating. Some resource requests may be upgraded or blocked by a browser. Our check does not fetch them, follow their redirects, inspect CSS or run script-created requests. Open your own page’s developer tools to confirm what actually happens, then test the important user journeys.
Why we cannot certify software patches
A public Server or X-Powered-By value is a declaration. It can be hidden, changed, served by a proxy or retained after a vendor backports a fix. Hiding it reduces disclosure but does not patch software. To assess a PHP or plugin advisory, check the installed package, configuration and vendor guidance with the host or administrator. A generic public page cannot establish whether a named vulnerability is present or fixed.
Use a measured change process
- Check that the response belongs to the intended page, rather than a bot challenge or error screen.
- Review each observation against the page’s purpose.
- Make one configuration change in staging and test navigation, forms, media and external integrations.
- Review CSP reports where appropriate before enforcing a tighter policy.
- Record the change and retest. Keep patching, backups and account security as separate responsibilities.
The checker labels incomplete reads and does not issue an overall “safe” score. A clean public response can coexist with private application flaws; a missing optional header is not automatically a vulnerability.
Technical references: MDN’s CSP guide, HSTS, nosniff and framing controls.