A Website Can Have HTTPS and Still Need Security Headers

"My website has HTTPS, a valid TLS certificate, and other security controls. So the website is secure."

That is a good start.

HTTPS is important.

A valid TLS certificate is important.

Secure authentication, strong passwords, MFA, secure coding, firewalls, WAFs, access controls, monitoring, backups, and other security measures are important too.

But there is another layer that is often overlooked:

Security headers.

A website can have:

• ✓ HTTPS
• ✓ A valid TLS certificate
• ✓ A firewall
• ✓ A WAF
• ✓ Secure authentication
• ✓ Strong access controls
• ✓ Secure application code

…and still have missing, weak, or incorrectly configured security headers.

That does not automatically mean the website is vulnerable or compromised.

It means there may be additional browser-side security controls that should be reviewed.

What Are Security Headers?

Security headers are special instructions that a web server sends to a browser through an HTTP response.

In elementary terms:

Security headers tell the browser how it should handle certain content, connections, and behaviors from the website.

For example, a website can tell the browser to:

• ✓ Prefer HTTPS connections
• ✓ Restrict where scripts and other resources can come from
• ✓ Prevent certain pages from being embedded by other websites
• ✓ Prevent certain content from being interpreted incorrectly
• ✓ Limit how much referrer information is shared
• ✓ Restrict access to certain browser features
• ✓ Apply additional browser security policies

The browser reads these instructions and applies the relevant rules.

You usually do not see security headers on the webpage itself.

They work mostly behind the scenes.

How Do Security Headers Work?

The basic process is simple:

User → Website → HTTP Response → Security Headers → Browser Enforces Policy

For example:

1. A user opens a website.
2. The browser sends an HTTP request.
3. The web server or application sends an HTTP response.
4. The response contains security headers.
5. The browser reads them.
6. The browser applies the specified rules.

So security headers are not usually something the user interacts with directly.

They are instructions that help the browser handle the website more safely.

A Simple Example: Content-Security-Policy

Consider:

Content-Security-Policy: default-src 'self'

Content-Security-Policy: default-src 'self'

In simple terms, this tells the browser to restrict content to the website's own origin unless additional sources are explicitly allowed.

Now imagine the website does not have a CSP.

That does not automatically mean:

"The website has been hacked."

It also does not automatically mean:

"The website has XSS."

The correct security question is:

"Does another vulnerability exist that this missing protection could make easier to exploit or more damaging?"

That distinction is critical.

HTTPS vs. Security Headers

HTTPS and security headers are related to security, but they do different jobs.

HTTPS / TLS

HTTPS primarily protects communication between the browser and the website by providing:

• ✓ Encryption
• ✓ Integrity protection
• ✓ Server authentication through certificates

Security Headers

Security headers provide additional instructions that influence how the browser handles the website.

They can help with areas such as:

• ✓ Content execution
• ✓ Clickjacking protection
• ✓ Transport-security behavior
• ✓ Cross-origin behavior
• ✓ Referrer information
• ✓ Content interpretation
• ✓ Browser-side attack mitigation

Therefore:

"HTTPS and security headers do not replace each other."

Think of it simply:

HTTPS protects the communication channel.

Security headers help control browser behavior.

Both can be important parts of a layered security design.

What If Security Headers Are Missing?

Imagine a website has:

• ✓ HTTPS
• ✓ Valid TLS certificate
• ✓ Strong authentication
• ✓ MFA
• ✓ Secure server configuration
• ✓ Firewall
• ✓ WAF
• ✓ Secure application code
• ✓ Access controls
• ✓ Logging and monitoring

But several recommended security headers are missing.

Should we immediately declare the website "insecure"?

No.

First ask:

Which headers are missing?

What protection do they provide?

Does this application actually need them?

Does another vulnerability exist that makes the missing protection important?

Can the risk be demonstrated?

What is the realistic impact?

That produces a much more accurate security assessment.

Not Every Missing Header Has the Same Risk

This is another important point.

Not every security header has the same purpose.

Not every website needs the same configuration.

A missing header may be:

a hardening recommendation,

a defense-in-depth issue,

or, in combination with another weakness,

a meaningful security risk.

The correct assessment depends on:

• ✓ The purpose of the header
• ✓ The application's architecture
• ✓ The application's functionality
• ✓ The data being handled
• ✓ Existing vulnerabilities
• ✓ Existing security controls
• ✓ Attack reachability
• ✓ Exploitability
• ✓ Potential impact

For example:

Missing header → additional hardening opportunity

is very different from:

Missing header + existing vulnerability → increased attack impact

That is why context matters.

1. Strict-Transport-Security (HSTS)

Purpose: Helps browsers enforce HTTPS after they have received the HSTS policy.

What if HSTS is missing?

Without HSTS, a browser may still attempt an HTTP connection before being redirected to HTTPS, depending on the website's configuration and the user's circumstances.

This can increase exposure to certain downgrade or man-in-the-middle scenarios.

The exact risk depends on the application, browser behavior, network environment, and how HTTPS is implemented.

What should we check?

Ask:

Can an attacker interfere with an initial insecure connection before HTTPS is established?

What should we do?

• ✓ Use HTTPS everywhere.
• ✓ Configure HSTS appropriately.
• ✓ Choose an appropriate max-age.
• ✓ Use includeSubDomains only when the relevant subdomains are ready for HTTPS.
• ✓ Consider HSTS preload only after understanding its consequences.
• ✓ Test the configuration before deploying it widely.

2. Content-Security-Policy (CSP)

Purpose: Controls where scripts, images, styles, frames, and other resources can come from and what the browser is allowed to execute.

What if CSP is missing?

Without CSP, the browser does not have that additional policy layer for restricting content sources.

This can increase the impact of certain client-side vulnerabilities.

For example, if a website already has an XSS vulnerability, a strong CSP may help limit what injected content can do.

But:

Missing CSP does not automatically create XSS.

There normally needs to be another weakness that allows attacker-controlled content to reach the webpage.

What should we check?

Ask:

If malicious content reaches the webpage, what could the browser execute?

What should we do?

• ✓ Use CSP where appropriate.
• ✓ Restrict trusted sources as much as practical.
• ✓ Avoid unnecessary wildcards.
• ✓ Minimize unnecessary third-party sources.
• ✓ Avoid unsafe directives when they are not required.
• ✓ Consider nonces or hashes where appropriate.
• ✓ Test the policy carefully before enforcing it.

3. X-Frame-Options

Purpose: Helps prevent a website from being embedded inside a frame controlled by another website.

This can help protect against clickjacking.

What if it is missing?

If there is no other effective framing protection, an attacker may be able to place certain pages inside an iframe.

They could then attempt to trick an authenticated user into interacting with a page without fully realizing what they are clicking.

What should we check?

Ask:

Can another website frame this page and trick a user into performing an action?

What should we do?

• ✓ Configure appropriate framing protection.
• ✓ Consider CSP frame-ancestors.
• ✓ Document legitimate framing requirements.
• ✓ Avoid allowing untrusted websites to frame sensitive pages.

4. X-Content-Type-Options

Purpose: Helps prevent browsers from guessing a resource's content type instead of following the declared type Content-Type.

A common configuration is:

X-Content-Type-Options: nosniff

X-Content-Type-Options: nosniff

What if it is missing?

Without this protection, browsers may perform MIME sniffing in certain situations.

This can become more important when a website serves files with incorrect content types.

What should we check?

Ask:

Could the browser interpret a file differently from what the website intended?

What should we do?

• ✓ Use X-Content-Type-Options: nosniff where appropriate.
• ✓ Return correct Content-Type values.
• ✓ Validate uploaded files.
• ✓ Do not rely on this header alone to secure file uploads.

5. Referrer-Policy

Purpose: Controls how much referrer information is shared when a user moves from one webpage to another.

This matters because URLs can sometimes contain sensitive information.

For example:

https://example.com/reset?token=SECRET

https://example.com/reset?token=SECRET

Putting sensitive secrets in URLs is already a poor design.

Weak referrer controls can create additional exposure when sensitive URLs are sent to another origin.

What should we check?

Ask:

Could sensitive information from one webpage be unintentionally shared with another website?

What should we do?

• ✓ Configure an appropriate Referrer-Policy.
• ✓ Never put passwords, session secrets, or sensitive tokens in URLs.
• ✓ Review links from sensitive pages to external websites.
• ✓ Test the actual application behavior.

6. Permissions-Policy

Purpose: Controls which browser features and APIs a webpage is allowed to use.

These may include:

• ✓ Camera
• ✓ Microphone
• ✓ Geolocation
• ✓ Other browser capabilities

What if it is missing or too permissive?

A missing permissions policy does not automatically mean an attacker can turn on a camera or microphone.

Modern browsers have additional permission and security controls.

However, unnecessarily allowing browser capabilities can increase the application's attack surface.

What should we check?

Ask:

Does this website allow browser features that it does not actually need?

What should we do?

• ✓ Disable unnecessary features.
• ✓ Allow only the origins that need specific capabilities.
• ✓ Review third-party and embedded content.
• ✓ Apply the principle of least privilege.

7. Cross-Origin-Opener-Policy (COOP)

Purpose: Helps isolate a webpage's browsing context from documents opened from other origins.

This can provide additional protection against certain cross-origin attacks.

What if COOP is missing?

The absence of COOP does not automatically mean that an attacker can compromise the website.

The importance depends on the application's architecture and cross-origin behavior.

What should we check?

Ask:

Could another website or document interact with this browsing context in a way the application does not intend?

What should we do?

• ✓ Determine whether cross-origin isolation is needed.
• ✓ Understand legitimate cross-origin integrations.
• ✓ Test the policy before enforcing it.
• ✓ Consider COOP as part of a broader browser-security strategy.

8. Cross-Origin-Resource-Policy (CORP)

Purpose: Helps control which origins can load certain resources.

What if CORP is missing?

Without CORP, resources may be more broadly available to other origins, depending on the resource, browser behavior, and other controls.

This does not automatically mean sensitive information can be stolen.

What should we check?

Ask:

Can an untrusted website load a resource that should be restricted?

What should we do?

• ✓ Identify resources that require cross-origin restrictions.
• ✓ Apply an appropriate CORP policy where needed.
• ✓ Test legitimate cross-origin functionality.
• ✓ Consider CORP together with CORS, CSP, COOP, and other browser security controls.

Missing Does Not Automatically Mean Vulnerable

This may be the most important point in the entire article.

Finding:

"HSTS is missing."

does not prove:

"The website has been compromised."

Finding:

"CSP is missing."

does not prove:

"The website has XSS."

Finding:

"X-Frame-Options is missing."

does not automatically prove:

"The website is vulnerable to clickjacking."

A scanner can identify a missing security control.

But a scanner finding is not automatically the same thing as a confirmed vulnerability.

A proper security assessment requires context.

The process should be:

Missing Control → Understand Its Purpose → Identify the Possible Risk → Test the Application → Determine Exploitability → Assess Impact → Remediate → Verify

That is the difference between checking a box and actually performing a security assessment.

What Can an Attacker Actually Do?

The answer depends on the header, the application, and the other vulnerabilities that may exist.

An attacker cannot simply say:

"CSP is missing, so I can hack the website."

That is not how web security works.

Instead, an attacker looks for an existing weakness and asks whether the missing security control makes exploitation easier or increases the possible impact.

For example:

XSS + Weak CSP

may be more dangerous than:

XSS + Strong CSP

Similarly:

Sensitive page + missing framing protection

may create a clickjacking risk that appropriate framing protection could reduce.

And:

Sensitive information in URLs + Weak Referrer Policy

may increase the possibility of information leakage.

The important point is:

Security headers are protective layers. Their absence may increase risk, but the actual impact depends on the application and the attack path.

How Should We Assess Missing Security Headers?

A simple process works well:

1. Identify

Which security header is missing or misconfigured?

2. Understand

What security problem is the header designed to reduce?

3. Examine

Does the application have a related vulnerability or risky behavior?

4. Test

Can the suspected weakness actually be demonstrated?

5. Assess

What is the realistic impact?

6. Remediate

Add or correct the security control when appropriate.

7. Verify

Check the actual HTTP response again.

8. Monitor

Make sure future deployments or configuration changes do not accidentally remove the protection.

The Simple Rule Everyone Should Remember

Do not think:

"A security header is missing; therefore, the website is insecure."

Think:

"A security control is missing. What does it protect? What could happen without it? Does this website have a related weakness? Can the risk be demonstrated? And what should be done about it?"

That is a much better way to understand website security.

HTTPS is important.

TLS certificates are important.

Authentication is important.

Authorization is important.

Secure coding is important.

Security headers are important.

Monitoring and logging are important.

Vulnerability management is important.

No single security control can protect everything.

The goal is defense in depth.

Understand the control. Understand the risk. Test the real situation. Fix what needs to be fixed. Then verify that the protection actually works.

That is cybersecurity—not simply finding something missing, but understanding why it matters, whether it is actually exploitable, and what the real impact is.

🛡️How to Check Security Headers in Your Browser

You do not need to be a cybersecurity expert to check a website's security headers.

You can check them directly from your browser.

Here is a simple step-by-step method.

Method 1: Check Security Headers Using Your Browser

Step 1: Open the website

Open the website you want to check.

For example:

https://example.com

https://example.com

Only check websites you are authorized to assess when performing security testing.

Step 2: Right-click on the webpage

Right-click anywhere on the webpage.

A menu will appear.

Look for:

Inspect

or

Inspect Element

Click it.

Step 3: Open the Network tab

Developer Tools will appear.

Look for the:

Network

tab.

Click it.

If you do not see it immediately, you may need to expand the Developer Tools window.

Step 4: Reload the webpage

With the Network tab open, reload the webpage.

You can press:

Ctrl + R

or click the browser's reload button.

You should now see the requests made by the webpage.

Step 5: Select the main webpage request

Look for the main request for the website.

It may appear as:

example.com

example.com

or:

/

/

Click that request.

Step 6: Find "Headers"

A panel containing information about the request will appear.

Look for:

Headers

Click it.

You will normally see sections such as:

General

Request Headers

Response Headers

The section we are interested in is:

Response Headers

Step 7: Look for security headers

Now look through the Response Headers.

You may see headers such as:

Strict-Transport-Security
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

Strict-Transport-Security
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

You may also see other headers.

For example:

content-security-policy: default-src 'self'

content-security-policy: default-src 'self'

or:

x-content-type-options: nosniff

x-content-type-options: nosniff

or:

strict-transport-security: max-age=31536000

strict-transport-security: max-age=31536000

If a particular header does not appear, it may not be present in that response.

A Very Simple Way to Understand the Result

Think of it like a checklist.

🔐 Security Headers

• 🛡️ Strict-Transport-Security (HSTS): ✓ Present / ✗ Missing
• 🔒 Content-Security-Policy (CSP): ✓ Present / ✗ Missing
• 🖼️ X-Frame-Options: ✓ Present / ✗ Missing
• 🧩 X-Content-Type-Options: ✓ Present / ✗ Missing
• 🔗 Referrer-Policy: ✓ Present / ✗ Missing
• ⚙️ Permissions-Policy: ✓ Present / ✗ Missing

But remember:

Missing does not automatically mean vulnerable.

You still need to understand what the header does and whether its absence creates a realistic security risk for that particular website.

You Can Also Copy the Headers and Ask AI

This is where AI can make the process easier for beginners.

After opening Response Headers, you can copy the header information and paste it into ChatGPT, Claude, Gemini, or another AI assistant.

For example, you could ask:

"Explain these HTTP response headers in very simple English. Tell me which security-related headers are present, which are missing, what each one does, and whether the missing headers are actually important for this website. Do not assume that a missing header automatically means the website is vulnerable."

You can then paste the headers underneath your question.

AI can help explain what the headers mean.

But there is an important rule:

Do not blindly trust the AI's conclusion.

Use AI to help you understand the information.

Then verify important findings yourself.

AI can explain.

You still need to validate.

Method 2: Use SecurityHeaders.com

If you want an even easier method, you can use SecurityHeaders.com.

It is a website that analyzes a site's HTTP response headers and provides a security grade along with information about missing or present security-related headers.

Step 1

Open:

SecurityHeaders.com

Step 2

Enter the website you want to check.

For example:

https://example.com

https://example.com

Step 3

Start the scan.

Step 4

Review the results.

You may see:

A+

A

B

C

D

E

or

F

The site also shows which security-related headers it found and which ones are missing.

But Don't Treat the Grade as the Whole Story

This is very important.

Suppose SecurityHeaders.com gives a website a C.

That does not automatically mean:

"The website is hacked."

And an A+ does not automatically mean:

"The website is completely secure."

The grade mainly reflects the HTTP security headers that the service checks.

It is not a complete penetration test, vulnerability assessment, or security audit.

A website can have excellent security headers and still contain:

• authentication vulnerabilities
• authorization problems
• SQL injection
• XSS
• insecure APIs
• business-logic flaws
• vulnerable dependencies
• configuration problems
• exposed secrets
• other security weaknesses

Likewise, a missing header may be only a hardening issue rather than an exploitable vulnerability.

The Best Approach

For someone who is just learning, I recommend using both methods.

First:

Check the headers yourself in the browser.

This teaches you what an HTTP response actually looks like.

Then:

Use SecurityHeaders.com.

This gives you a quick automated assessment.

Then:

Copy the relevant headers and ask an AI assistant to explain them.

For example:

"Explain these headers in simple English. Identify the security headers, explain what each one does, identify anything missing, and explain whether the missing items are merely hardening recommendations or could create a realistic security risk. Do not claim a vulnerability without evidence."

Finally:

Verify the important findings yourself.

This gives you:

Browser → Raw Headers → Security Scanner → AI Explanation → Human Verification

That is a much better learning process than simply looking at a letter grade.

One More Important Point

Security headers can vary between different responses.

The headers on the homepage may not be identical to the headers on:

• login pages
• API endpoints
• error pages
• file-download responses
• application pages
• redirects

Therefore, checking only one page does not necessarily tell you everything about the website.

For a serious security assessment, you need to understand the application's architecture and examine the relevant responses.

For beginners, however, checking the main webpage is a good place to start.

You don't need expensive tools to begin learning. Open your browser, inspect the response headers, understand what they mean, and then verify what you find.

That simple process can teach you a lot about how websites actually protect users in the browser.