Intelligence module

What your server tells every visitor about how it is configured

A passive read of the response headers and transport settings that browsers rely on to protect people using your site. Nothing is probed, nothing is exploited, and nothing here approaches a penetration test.

Check your headers Run the full analysis

Infrastructure expertise from Elite Security Europe.

When a browser loads your page, the response carries instructions about how the content should be treated: whether the page may be embedded in a frame elsewhere, whether the browser should guess at content types, where scripts may legitimately be loaded from, how much referrer information to disclose when a visitor clicks away.

These instructions cost nothing to send and remove entire categories of browser-side risk when present. Their absence does not mean a site is vulnerable. It means one of the cheap defences is not deployed.

This module reports what is present and what is not, in measured terms. It does not tell you that you are at risk of anything, because a header check cannot establish that.

Checks

What is read

Every one of these is a header your server already sends, or does not, to everyone who requests a page.

Content Security Policy

Governs where scripts, styles and other resources may be loaded from. The most consequential of these headers and the most involved to configure correctly, since a policy that is too strict breaks the site.

Strict Transport Security

Instructs browsers to use HTTPS for future requests, closing the window in which an initial insecure request could be intercepted. Its declared duration matters as much as its presence.

Content type options

Prevents browsers from guessing a resource's type rather than trusting the declared one. A single directive, no practical downside, and frequently absent.

Frame and origin controls

Determines whether your pages may be embedded elsewhere and how they are isolated from other browsing contexts, which affects a family of clickjacking and cross-origin techniques.

Referrer policy

Controls how much of the current address is disclosed when a visitor follows a link away. A privacy consideration more than a security one, and relevant where addresses carry parameters.

Permissions policy

States which browser capabilities the page may use — camera, microphone, location and similar. Restricting what is not needed reduces what an injected script could reach.

A missing header is a defence not deployed. It is not a vulnerability, and reporting it as one would be the kind of fear-based advice this module is designed to avoid.

Interpretation

What the score reflects

Reflects the presence of the public response headers and transport settings that reduce common browser-side risks. It is not a vulnerability assessment.

It says nothing about your application’s security, your server’s patch level, your access controls or your data handling. A site with a perfect header configuration can be thoroughly insecure in ways this module has no means of detecting and no business speculating about.

What a high score establishes is that the inexpensive browser-side controls are in place, which is a reasonable proxy for whether somebody has been paying attention. What a low score establishes is that there is straightforward work available, not that anything is wrong.

Never reported publicly

Exact administrative or login paths
Origin server addresses behind a proxy or CDN
Specific software versions, where they are disclosed
Anything characterised as exploitable
Internal hostnames or asset names
Details that would assist somebody acting in bad faith

Where such details are observed, they are recorded internally and made available to a verified domain owner. They are not published in a snapshot anybody can generate.

Example finding

A representative finding

This is an illustration of the report format rather than a result from a real assessment.

Moderate

No Content Security Policy Is Declared

What we found: The pages examined return no Content-Security-Policy header. Other protective headers are present, including strict transport security with a long duration and content type options.
Why it matters: A Content Security Policy restricts where the browser may load scripts and other resources from, which limits what an injected or compromised third-party script could do. Its absence is not evidence of a problem; it means this particular control is not available if something else goes wrong.
General direction: Introduce a policy in report-only mode first so violations are recorded without breaking the site, review what legitimate resources it flags, then enforce once the policy reflects what the site actually loads. Sites using third-party tags need particular care at this stage.
How IXSEO can help: Passive Security Exposure Review, with infrastructure expertise from Elite Security Europe.

Boundaries

What this module will never do

These constraints are enforced in the fetching layer rather than left to policy, and they apply regardless of what is entered or who is asking.

Scan ports or enumerate services on any host.
Probe for vulnerabilities or submit payloads of any kind.
Attempt authentication or interact with a login form.
Enumerate directories, files or administrative endpoints.
Attempt to trigger error conditions to learn from the response.
Characterise anything observed as exploitable.
Publish detail that would assist somebody acting in bad faith.

Infrastructure expertise from Elite Security Europe

Frequently asked questions

Is this a penetration test?

No, and the difference is fundamental rather than one of degree. A penetration test attempts to find and demonstrate exploitable weaknesses with permission. This reads the headers your server already sends to every visitor. Security Exposure findings identify publicly observable indicators and do not replace an authorised penetration test.

Could running this be mistaken for an attack?

It should not be. The module makes ordinary requests for pages, using normal methods and timing, and reads the responses. There is no scanning, no enumeration, no unusual payloads and no attempt to trigger errors. In your logs it should be indistinguishable from a handful of visits.

Why does IXSEO check this at all?

Because the same requests that establish how a page is built also reveal how it is served, so the check costs nothing extra. And because a site presenting itself as trustworthy while omitting basic browser protections is inconsistent in a way that is worth telling the owner about.

We have a firewall and a security provider. Is this redundant?

Largely, and the module will usually say so. Where a provider is handling this well, the finding is positive rather than absent. Where headers are missing despite a provider being in place, that is worth raising with them, since it usually indicates a configuration option that was never enabled.

Can you test our infrastructure properly?

Only under a separate signed authorisation defining the legal entity, the authorising person, the exact systems in scope, the testing window, rate limits, exclusions and emergency contacts. That is never initiated from anything on this website, and domain verification alone does not authorise it.

ToolSecurity Header CheckerA free passive check of the headers described on this page.PolicyVulnerability disclosureHow to report a security issue in IXSEO's own systems.EcosystemElite Security EuropeThe specialist expertise supporting this area of the assessment.

Read what your server is sending

Security Exposure is an optional module on the free snapshot, and the standalone checker covers the same headers without running a full analysis.

Check your headers Discuss an authorised assessment