What Security Headers Actually Tell You

Security headers are easy to scan and easy to overinterpret.

A single HTTP request can produce a neat list:

• Strict-Transport-Security: present;
• Content-Security-Policy: missing;
• X-Frame-Options: present;
• Referrer-Policy: missing;
• Cross-Origin-Opener-Policy: missing.

That list is useful.

It is not a security verdict.

HTTP response headers are instructions and metadata delivered with a particular response. Some change browser behavior in ways that reduce specific classes of risk. Some control privacy or feature exposure. Some are relevant only to particular application architectures. Some are legacy mechanisms. Others merely reveal implementation details.

A responsible analyst therefore asks more than:

Is the header present?

The better questions are:

1. What browser behavior does this header control?
2. Is the value meaningful and syntactically valid?
3. Is the control appropriate for this type of resource?
4. Is it enforced consistently across the relevant routes and responses?
5. What can — and cannot — be inferred from its presence or absence?

This guide explains how to read security-header results as evidence rather than as a scorecard.

A header scan is a snapshot of one response

Before interpreting individual headers, understand what was actually measured.

When a tool requests a URL, it observes an HTTP exchange at a particular moment.

The result may depend on:

• the exact URL;
• whether redirects were followed;
• the final hostname;
• response status;
• CDN or reverse-proxy behavior;
• geographic edge;
• request headers;
• authentication state;
• route;
• cache state;
• application deployment;
• time.

A header found on:

https://example.test/

does not automatically prove that the same header is present on:

https://example.test/login

or:

https://app.example.test/

or:

https://api.example.test/.

Similarly, a header on a final 200 OK response may differ from headers delivered on an earlier redirect.

The first rule is therefore:

Treat a header scan as evidence about the observed response, not as a complete description of the entire organization or application.

Presence is only the first layer

For each header, separate four questions.

1. Presence

Was the header returned?

This is the easiest question.

2. Value

Does its value express a meaningful policy?

A weak or malformed policy can be very different from a strong one.

3. Applicability

Is this header relevant to the resource and architecture being observed?

Not every modern header belongs on every response.

4. Consistency

Is the policy present across the routes where it matters?

A good policy on the homepage can coexist with a weak policy elsewhere.

This four-part model prevents a common mistake:

counting headers and treating the total as a security grade.

Strict-Transport-Security: a transport policy

Strict-Transport-Security, usually called HSTS, tells a user agent that a host should be contacted only over secure transport for a specified period.

A typical value may look like:

Strict-Transport-Security: max-age=31536000; includeSubDomains

The core directive is max-age.

It defines how long the browser should remember the HSTS policy.

What HSTS tells you

A valid HSTS header on an HTTPS response tells you that the site is asking compliant user agents to enforce HTTPS-only interaction with that host for the advertised period.

Additional directives can expand the intended scope.

For example:

includeSubDomains

extends the policy to subdomains under the conditions defined by HSTS.

What HSTS does not tell you

HSTS does not prove:

• the application is free from vulnerabilities;
• TLS configuration is otherwise strong;
• every subdomain is correctly configured;
• the organization has perfect certificate management;
• all historical traffic was protected.

HSTS is one transport-security control.

It should not be converted into a general claim about the security of the application.

Why value matters

These two responses both technically contain HSTS:

Strict-Transport-Security: max-age=60

and:

Strict-Transport-Security: max-age=31536000

but they express very different persistence.

A presence-only scanner loses that distinction.

Content-Security-Policy: the policy matters more than the header name

Content-Security-Policy, or CSP, is one of the most expressive browser-side security mechanisms.

It allows a server to define restrictions around resources and browser behaviors such as:

• script sources;
• style sources;
• image sources;
• network connections;
• frames;
• embedding;
• form destinations;
• document base URLs;
• plugin-like object content.

A policy might include directives such as:

default-src 'self'

script-src 'self'

object-src 'none'

base-uri 'self'

frame-ancestors 'none'

The important analytical point is:

CSP is not binary.

The existence of the header tells you almost nothing about the strength of the policy until you read its directives.

Enforced CSP versus Report-Only

There are two important delivery modes:

• Content-Security-Policy
• Content-Security-Policy-Report-Only

An enforced CSP affects browser behavior.

A Report-Only policy is designed for monitoring and policy development rather than enforcement.

That distinction is critical in an audit.

A site may have a sophisticated Report-Only policy while still not enforcing equivalent restrictions.

Do not record:

CSP is enabled.

when the only observed policy is Report-Only.

Record exactly what was observed.

Weak-looking CSP can still require context

Avoid simplistic rules such as:

unsafe-inline appears, therefore CSP is useless.

or:

there is no default-src, therefore CSP is broken.

CSP evaluation depends on the complete policy and the directives that apply to the resource type.

Modern deployment patterns can include nonces, hashes, directive-specific restrictions and compatibility behavior.

The correct workflow is:

1. capture the complete policy;
2. parse each directive;
3. identify which resource types it governs;
4. distinguish enforced from Report-Only policy;
5. look for obviously broad or absent restrictions;
6. avoid claiming more than the observed policy establishes.

Framing controls: CSP frame-ancestors and X-Frame-Options

Framing controls address whether a page may be embedded by other pages.

Two mechanisms commonly appear:

• CSP frame-ancestors;
• X-Frame-Options.

Typical X-Frame-Options values include:

DENY

and:

SAMEORIGIN.

CSP can express framing restrictions through frame-ancestors.

What these controls tell you

They tell you that the publisher is expressing a browser-enforced policy about which ancestors may embed the document.

This can reduce exposure to classes of user-interface attacks involving unwanted framing.

What absence does not prove

The absence of X-Frame-Options alone does not prove framing is unrestricted.

The site may use CSP frame-ancestors.

Conversely, the presence of one framing control does not establish that the entire application has a uniform policy.

Check both mechanisms and inspect the actual values.

X-Content-Type-Options: a narrow but useful control

The important value for:

X-Content-Type-Options

is:

nosniff.

The Fetch Standard defines behavior for this header that requires user agents to respect declared content types in relevant fetch contexts rather than performing certain MIME-type sniffing behavior.

What nosniff tells you

It tells you that the response is asking the browser to apply stricter content-type checking in the contexts covered by the standard.

What it does not tell you

It does not prove that:

• all Content-Type values are correct;
• uploaded content is handled safely;
• the application prevents every form of content confusion;
• the endpoint is otherwise secure.

Again, the header represents one browser behavior.

Referrer-Policy: primarily a privacy and disclosure control

Referrer-Policy controls how much referrer information a user agent includes when navigating or fetching resources.

Policies can range from relatively restrictive to relatively permissive.

Examples include:

no-referrer

same-origin

strict-origin

strict-origin-when-cross-origin

What it tells you

A declared Referrer Policy provides evidence about how the publisher intends browsers to handle referrer information.

This can matter when URLs contain:

• sensitive paths;
• identifiers;
• internal structure;
• capability-like tokens;
• query parameters.

What absence means

Do not automatically classify absence as a critical vulnerability.

Browsers have default behavior even when the site does not declare an explicit header.

The analytical finding is more precise:

No explicit Referrer-Policy response header was observed on this response.

Whether that is important depends on the application, browser defaults, URL design and threat model.

Permissions-Policy: feature exposure, not a universal checklist item

Permissions-Policy allows a site to control the availability of policy-controlled browser features and APIs.

For example, a site may explicitly disable features such as geolocation or fullscreen in particular contexts.

A restrictive example can look like:

Permissions-Policy: geolocation=(), camera=(), microphone=()

What presence tells you

It tells you that the application is explicitly declaring policy for one or more browser features.

What absence does not tell you

The absence of the header does not automatically mean the site has a vulnerability.

Permissions Policy is highly dependent on application behavior.

A simple static site and a complex embedded application may have very different reasons to define one.

This is an important example of why:

missing header ≠ security defect

without additional context.

Cross-origin isolation headers are architectural controls

Modern scanners may also report:

• Cross-Origin-Opener-Policy — COOP;
• Cross-Origin-Embedder-Policy — COEP;
• Cross-Origin-Resource-Policy — CORP.

These headers participate in cross-origin isolation and resource-sharing behavior.

They can be important for applications that need strong isolation properties or particular browser capabilities.

They are not universal requirements for every website.

COOP

Cross-Origin-Opener-Policy affects relationships between top-level documents and browsing-context groups.

COEP

Cross-Origin-Embedder-Policy places requirements on the cross-origin resources a document can embed when using relevant isolation modes.

CORP

Cross-Origin-Resource-Policy allows a resource to express policy about cross-origin loading.

Why their absence is contextual

Strict cross-origin isolation can affect:

• third-party widgets;
• embedded documents;
• external scripts;
• images;
• analytics;
• legacy integrations.

Therefore a scanner should not equate:

COOP missing

with:

website insecure.

The useful result is:

This response does not advertise COOP.

Then ask whether the site's architecture or security requirements make that meaningful.

X-XSS-Protection: legacy signals should not dominate modern analysis

Security scanners often accumulate historical headers over time.

X-XSS-Protection is a good example of why the age and status of a mechanism matter.

A modern header audit should not reward a site simply for returning every header that has ever existed.

The better question is:

Is this mechanism still part of the current browser security model we are trying to evaluate?

If a tool identifies a header as deprecated or legacy, treat that as context rather than as a missing modern defense.

The Server header is not the same kind of security control

A response may include:

Server: nginx

or another runtime or platform identifier.

This is different from HSTS or CSP.

It does not instruct the browser to enforce a security policy.

It is implementation metadata.

What it can tell you

It can contribute a weak technology signal.

What it cannot prove

It may be:

• generic;
• rewritten by a proxy;
• inserted by a CDN;
• intentionally misleading;
• stripped;
• unrelated to the application runtime behind the edge.

Do not turn a Server value into a precise technology or vulnerability claim.

Corroborate it with other technology signals.

How to interpret a Security Headers Checker result

Imagine an OSINT.dev result says:

2/11 headers present · 3 missing, 6 warnings.

That is not equivalent to:

Security score: 2/11.

The tool is reporting observations across several categories.

Some findings may concern broadly relevant controls:

• HSTS;
• CSP;
• MIME-type enforcement.

Others may be contextual:

• Permissions Policy;
• COOP;
• COEP;
• CORP.

Another may be an information-disclosure clue:

• Server.

Another may be a legacy signal:

• X-XSS-Protection.

The result should therefore be read as:

Eleven predefined header signals were checked on this response. Two were present. Some absent or unusual values deserve contextual review.

Not:

The site has only 18% security.

A practical interpretation matrix

Precision matters.

Check redirects before interpreting the final response

Security policies can change during a redirect chain.

For example:

1. http://example.test
2. https://example.test
3. https://www.example.test/

Each response can have different headers.

If your tool reports only the final response, you may miss useful information about how the initial request was handled.

For transport analysis in particular, the path from the first URL to the final HTTPS destination can matter.

Use the redirect chain as corroborating evidence.

Check more than the homepage when the question requires it

A homepage scan is a useful baseline.

It is not a substitute for route-aware analysis when the investigation concerns a specific application function.

Potentially relevant routes can include:

• login;
• account;
• application dashboard;
• static assets;
• API responses;
• download endpoints.

But scope and proportionality still apply.

Do not turn a header check into broad endpoint enumeration.

Request only the public routes necessary to answer the question.

Consider the response type

A policy relevant to an HTML document may be less meaningful on another response type.

Ask:

• Is this an HTML document?
• JSON?
• image?
• redirect?
• error page?
• static asset?

A blanket expectation that every response contains every header can create false positives.

The unit of analysis is not:

the company.

It is:

this response, from this URL, at this time, in this context.

CDN and proxy layers can be analytically useful

Headers are often injected or removed by infrastructure between the application and the user.

Examples include:

• reverse proxies;
• CDNs;
• managed hosting;
• edge middleware;
• web application firewalls.

This means header differences can become useful infrastructure signals.

Suppose:

• the homepage includes HSTS;
• a secondary hostname does not;
• Server values differ;
• cache headers differ;
• redirect behavior differs.

That pattern may suggest different delivery paths or configuration layers.

It still does not automatically reveal the complete backend architecture.

Compare over time carefully

Security headers can change after:

• deployments;
• framework upgrades;
• CDN changes;
• policy rollouts;
• incident remediation;
• application migrations.

If you compare two observations, record:

• URL;
• timestamp;
• tool version;
• response status;
• final URL;
• header values.

Then describe the change precisely.

For example:

CSP was not present in the response observed on date A and was present with policy X on date B.

That is stronger than:

The site became secure.

Common interpretation mistakes

Mistake 1 — Counting headers as a grade

Different headers protect different things.

Some are context-dependent.

A simple ratio is not a meaningful global security score.

Mistake 2 — Ignoring values

A header name without its policy value is incomplete evidence.

Mistake 3 — Treating warnings as vulnerabilities

A scanner warning is a prompt for analysis.

It is not automatically a vulnerability finding.

Mistake 4 — Assuming the homepage represents every route

Policies can differ by hostname, path, response type and infrastructure layer.

Mistake 5 — Treating modern architecture headers as universal requirements

COOP, COEP, CORP and Permissions Policy can be important without being mandatory for every site.

Mistake 6 — Ignoring Report-Only mode

Monitoring and enforcement are different states.

Mistake 7 — Inferring backend details from Server alone

Server banners are weak technology evidence.

Mistake 8 — Confusing control presence with effective security

A correct header can reduce one class of risk.

It does not validate the rest of the application.

A repeatable header-analysis workflow

Use this sequence.

Step 1 — Record the target

Capture:

• requested URL;
• timestamp;
• whether redirects are followed;
• final URL.

Step 2 — Record the response context

Capture:

• status;
• response type;
• relevant hostname;
• major redirect transitions.

Step 3 — Capture complete header values

Do not store only present/missing flags when the policy value matters.

Step 4 — Classify each finding

Ask whether the header concerns:

• transport;
• content execution;
• framing;
• content typing;
• privacy;
• browser capabilities;
• cross-origin isolation;
• implementation metadata;
• legacy behavior.

Step 5 — Evaluate applicability

Is this control relevant to the resource and application?

Step 6 — Evaluate the value

Is the declared policy meaningful?

Step 7 — Corroborate when needed

Use:

• redirect analysis;
• another public route;
• technology indicators;
• previous public observations.

Step 8 — Write the conclusion at the right strength

Prefer:

No enforced CSP header was observed on the final HTML response.

over:

The site has no XSS protection.

Prefer:

The response advertises HSTS with a one-year max-age.

over:

HTTPS is completely secure.

Related OSINT.dev tools

Security Headers Checker

Use this as the primary observation tool.

It checks a defined set of response-header signals and reports:

• present values;
• missing values;
• warnings;
• final URL;
• response status.

Its output is evidence for interpretation, not a security grade.

Redirect Chain & Response Inspector

Use this when the requested URL redirects before reaching the final document.

It helps establish which response actually carried each observable behavior.

Tech Stack Snapshot

Use technology indicators to corroborate weak implementation hints such as server banners.

Do not assume the values are authoritative.

urlscan.io

Previously collected public scans can sometimes provide a useful independent observation of web behavior at another point in time.

Treat third-party scan data according to its timestamp and collection context.

The core principle

A good security-header analysis does not ask:

How many security headers does this website have?

It asks:

Which browser policies did this response declare, what do those policies actually enforce, which controls are relevant here, and how strongly can we interpret the result?

That leads to better findings.

It also leads to fewer false conclusions.

Security headers matter.

But their value comes from the browser behavior they control — not from the number of green checks in a scanner.

References

Primary standards used in this guide:

• RFC 6797 — HTTP Strict Transport Security (HSTS)
  https://www.rfc-editor.org/rfc/rfc6797.html

• Content Security Policy Level 3 — W3C
  https://www.w3.org/TR/CSP3/

• Fetch Standard — WHATWG (X-Content-Type-Options, Cross-Origin-Resource-Policy)
  https://fetch.spec.whatwg.org/

• HTML Standard — WHATWG (X-Frame-Options, Cross-Origin-Opener-Policy and browser context behavior)
  https://html.spec.whatwg.org/

• Referrer Policy — W3C
  https://www.w3.org/TR/referrer-policy/

• Permissions Policy — W3C
  https://www.w3.org/TR/permissions-policy/