Service status
Free Web Security Check
Check security headers, HTTPS and website configuration
Check a website
Check which security settings your website exposes publicly. The web check examines Content-Security-Policy, HSTS, HTTPS redirects and visible features of the TLS certificate, among other things. You receive findings, explanations and notices about anything that could not be measured.
The check starts from the address you enter and makes selected additional requests. It does not search every page or access areas behind login or SSO. You do not need to install anything or have a Wolf-Agents account.
Turn a setting into a next step
A missing header can point to a specific task for hosting or development. A header that is present may still have an unsuitable setting. The check helps you interpret these observations and ask focused questions.
Start with a finding that needs attention: which address was actually reached? Which value was observed? What change does the explanation recommend, and does it suit your website? A stricter CSP can block functions you need. Establish the use case before adopting an example configuration.
What the web check examines
Scope model · no measurement performed
From a public target to a limited finding
- Public address
Example:
https://example.com - Entered address and selected additional requests
Observations are possible only where the information can be retrieved and falls within the check scope.
On narrow screens, scroll the table sideways.
| Check area | Observation and scope |
|---|---|
| HTTP security headers | CSP, HSTS and other security headers in the retrieved response; not every response from your application is checked. |
| HTTPS and redirects | The request and redirect path covered by the check and selected related settings. |
| TLS certificate | Visible certificate features of the checked target; not a complete analysis of your entire TLS infrastructure. |
| Domain DNS and HSTS preload | Selected DNS and preload features. A single check does not replace a full DNS assessment. |
| Delivered HTML | Selected features and references to third-party resources in the retrieved page; not a complete browser run. |
Read findings alongside the measurement time and coverage. Not measured means neither passed nor that a feature is demonstrably absent. Redirects, protection systems in front of the target and connection problems can change which response is reached.
Outside the scope: no full crawl, login or SSO, source code, user permissions, business logic or complete browser run. This diagram does not assign a grade. No overall web grade is provided when the measurement basis is insufficient or the response reached is not HTML.
Understand important headers
Security headers are instructions in an HTTP response. They can restrict browser functions or activate additional protections. A header being present does not guarantee security; a missing header alone does not prove an exploitable vulnerability.
On narrow screens, scroll the table sideways.
| Header | Purpose and next check |
|---|---|
| Content-Security-Policy (CSP) | Restricts script sources and connections, among other things. An appropriately enforced policy can add a barrier against script injection. Report-Only does not block violations of that monitoring policy; an application vulnerability still needs to be fixed. |
| Strict-Transport-Security (HSTS) | Instructs supporting browsers to use HTTPS for a limited period. Without a known policy or matching preload entry, the first HTTP request may be unencrypted. includeSubDomains and preload require preparation; a valid certificate remains necessary. |
| X-Frame-Options | DENY prevents framing; SAMEORIGIN limits it to the same origin. CSP frame-ancestors allows more specific rules. Check intentional embedding and sensitive interfaces. |
| X-Content-Type-Options | nosniff limits interpreting resources as a different type, particularly for scripts and stylesheets. Correct Content-Type values and secure upload rules remain necessary. |
| Referrer-Policy | Controls which URL information is passed on as the referrer. Without an explicit header, other rules apply, including browser defaults; this does not automatically mean the full URL is shared. Sensitive data should not be included in URLs. |
| Permissions-Policy | Restricts selected browser functions for pages and embedded content. It does not grant camera or microphone access or replace any necessary user permission; support and defaults vary by function. |
| Cross-Origin-Opener-Policy (COOP) | Can separate browsing context groups. Check login and payment pop-ups in particular. A missing policy does not prove that another tab can read arbitrary data. |
| Cross-Origin-Embedder-Policy (COEP) | Sets additional conditions for third-party resources. With require-corp, affected resources need suitable CORP or CORS permissions. This does not check whether their content is trustworthy; required resources must continue to work. |
COOP and an appropriate embedding policy can together enable cross-origin isolation. Adopt these settings only when they suit your application. The MDN HTTP header reference and the linked guides explain the details.
What A+ tells you – and what it leaves open
A+ is the highest grade in the web check. Its scale is A+, A, B+, B, C, D, E and F. The rating follows the web assessment model with its own weightings and limits; it is not a percentage of your overall security and is not directly comparable with an email or API grade.
Read the individual findings and measurement coverage alongside the grade. “Not measured” means that no usable measurement is available. It means neither “passed” nor “feature absent”. The report may omit an overall grade when the measurement basis is insufficient. No overall web grade is provided for a JSON or other non-HTML response either.
Even A+ does not confirm complete security. Source code, user permissions, business logic, malware and areas behind a login are among the things not examined. The check does not replace a full web application penetration test. A rating today does not rule out later changes or causes of disruption.
Check, interpret and measure again after a change
- Enter an authorised public address, prepare the check, review and accept the order, then start the check yourself.
- Read the target, measurement time, findings and any notices about limited measurements.
- Agree any necessary change with the person responsible. Test the affected website functions in your own environment.
- If needed, start a new check for the same address afterwards. Compare the two results by their findings and scope.
An unchanged letter does not prove an unchanged configuration. Different responses can lead to the same grade. Automatic monitoring and an automatically calculated comparison report are not part of this process.
Document the web findings
To keep or share a result, use the report files offered on the results page. PDF suits reading and filing, DOCX allows your own additions and CSV supports further work with the findings table. DOCX is editable; identify any changes you make.
Browser findings remain free. Order new report files separately; price, tax and scope appear before you place a binding order. Contract delivery requires an email address. Purchased originals remain in the archive for three calendar years from first delivery. Downloading does not start a new measurement; existing free-file promises retain their original validity.
Requesting an optional result email does not unlock additional content or run a new check. The report page and reading guide explains how to distinguish observations, interpretation and next actions.
Frequently asked questions
Can I check CSP and HSTS together?
Yes, on the response reached and within the checks provided. A CSP must also be tested against the functions your website actually needs. A missing HSTS header in this response does not prove that a browser has no previously stored HSTS policy.
Why does the same website sometimes produce a different result?
A different URL, redirect, change made in the meantime or protection system in front of the website can return a different response. Compare the address actually reached, the time and the measurement coverage. Downloading an old report again does not update its measurement.
Does the check find viruses or every exploitable vulnerability?
No. It examines selected configuration features and response signals. Malware analysis, a comprehensive active vulnerability assessment and a full penetration test are not included.
Is a report without concerning findings recognised evidence of security?
The report is a technical working document for the stated scope. It does not confirm legal compliance and is not recognised evidence for an audit or insurance assessment. An individual expert assessment of your website is not included; automated classifications can be wrong.
How do I act on a finding?
Check the explanation and recommendation against your environment. The HSTS guide, CSP explanation and web security guides can help with the next steps. Wolf-Agents does not change your configuration.
Technical sources
HSTS: RFC 6797 · Content Security Policy · How we use AI
These sources explain the mechanisms. The scope above describes which parts this check actually measures.