Today we walked someone through assessing the security of any website using a single command. No tools to install, no account, no scanner. Just one line in the terminal and you see things most businesses choose to ignore.

We ran the command against tcaisolutions.nl. Within three seconds the output was on the screen, and for someone who had never looked at HTTP under the hood before, it was an eye-opener. Not because it was complicated. Precisely because it turned out to be so simple. Everything a website reveals about itself to the outside world is contained in a few lines of text the server sends with every visit.

Those lines are called HTTP response headers. Some are harmless metadata, like which server is running or how the cache behaves. Others are the difference between "this website is protected against known attacks" and "this website is wide open for anyone who knows where to look".

In this post we show you how to do it yourself, which six headers every modern website should have, what happens when they are missing, and what the headers of tcaisolutions.nl actually look like. Including the part where we acknowledge something we would still like to fix.

What happens when you open a URL

When you type a web address into your browser, something happens that you never see. Your browser sends a small message to the website's server. That message contains things like which page you want, which language you speak, and which browser you are using. The server reads the request, finds the page, and sends a response back.

That response has two parts. First, a stack of lines containing metadata: the response headers. Then the actual content of the page, the HTML your browser renders.

You normally only see the second part. The browser processes the headers quietly in the background and shows you the page as if those headers do not exist. But every visit to every website produces those headers, and whoever reads them learns a great deal about how that website defends itself.

One command, all the information

To see those headers without all the browser machinery around them, you use curl. It is a command-line tool that has been available on virtually every Linux, macOS and modern Windows system since 1996. On Windows it is curl.exe. Everywhere else, just curl.

The command is three characters plus a URL: 


curl -I https://tcaisolutions.nl/

The -I tells curl: "I only want the response headers, not the HTML behind them". Three seconds later you see something like this on your screen: 


HTTP/2 200
server: cloudflare
strict-transport-security: max-age=31536000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self' ...
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=(), payment=()

That is it. No installation, no login, no accounts. Every website in the world hands you those headers for free if you ask, and from those few lines you can tell how seriously the owner takes security.

The six headers every modern website must have

Not all headers carry the same weight. There are dozens of possible response headers, but for security there are six that make the difference between "defended" and "exposed". We will go through them in the order we most often find them missing on Dutch SMB websites.

1. Strict-Transport-Security (HSTS)

This header tells your visitor's browser: "only connect to me over HTTPS, not HTTP, and remember that for the next 12 months". Without HSTS, an attacker positioned between the visitor and your server can silently downgrade the connection to the unencrypted version of your site. The visitor does not see it happening. Login credentials, session data, payment information, all of it can be intercepted.

With HSTS in place, the browser simply refuses to talk to your domain over HTTP. The attack stops working.

2. Content-Security-Policy (CSP)

This is the hardest header to configure correctly, and also the most important. CSP is a list that tells the browser: "only scripts from these sources are allowed to run on my site, only styles from that location, only images from there". If an attacker manages to inject malicious JavaScript into your page (for example through a contact form where you forgot to sanitize input), the browser blocks that code because it is not on the approved list.

Without CSP, every Cross-Site Scripting vulnerability is directly exploitable. With CSP, the attacker has to break through an additional layer of defense.

3. X-Frame-Options

This header controls whether your site can be loaded inside an iframe on someone else's website. Why does that matter? Clickjacking. An attacker builds their own website, invisibly loads your site in an iframe behind their content, and places buttons on their page that actually generate clicks on your site. The visitor thinks they are clicking on the attacker's page, but they are actually clicking your login button, your delete-account button, your payment button.

With X-Frame-Options: SAMEORIGIN, only you can embed your own site in an iframe. Other domains are blocked. Clickjacking stops working.

4. X-Content-Type-Options

Short but effective. The value should always be nosniff, and it tells the browser: "if I tell you this file is a PDF, accept that. Do not try to guess whether it might secretly be HTML with JavaScript."

Without this header, an attacker can upload a file that looks like an innocent PNG or PDF but gets interpreted and executed by the browser as JavaScript. A classic path for persistence after a file-upload vulnerability.

5. Referrer-Policy

When someone clicks a link on your site to another site, the browser by default sends information about where they came from. That is the Referer header. Without any control, it includes the complete URL, including query parameters. If those parameters carry sensitive information (customer search terms, session tokens, password-reset links), you are leaking that data to every external site you link to.

Referrer-Policy: strict-origin-when-cross-origin says: "share only my domain, not the full path". Internal paths and query parameters stay private.

6. Permissions-Policy

The newest of the six. This header controls which browser features your site is allowed to use: camera, microphone, GPS, payment API, and more. By explicitly saying "no, I do not need any of these features", you prevent a compromised script on your page from suddenly requesting access to your visitor's webcam. Defensive programming at the deepest level.

The headers of tcaisolutions.nl, broken down

We are not going to pretend our own website is perfect, so let us show you the actual output. This is what curl -I https://tcaisolutions.nl/ returns for us, line by line. 


strict-transport-security: max-age=31536000; includeSubDomains; preload

HSTS for one year, covering all subdomains, and registered in the browser preload list. This is the strongest configuration. Good. 


content-security-policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://chat.tsssupport.nl; ...

CSP is present, with external sources on the correct whitelist. But notice the 'unsafe-inline' in the script-src directive. That means inline JavaScript in our HTML is still allowed to run. It is not a disaster, but it is not ideal either. In a perfect world, all JavaScript would live in external files with a per-page nonce or hash, and 'unsafe-inline' could go away. For us it is there because some third-party integrations still require it. It is on our list of things to address over time. 


x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=(), payment=()

These four are correct. Clickjacking covered, MIME sniffing disabled, referrer properly restricted, and we have explicitly stated that our site has no need for camera, microphone, GPS or payment API access. If a compromised script ever makes it onto the page, it will not get access to those sensitive browser features.

Is it perfect? No. That 'unsafe-inline' needs to go eventually. Is it better than 90% of the Dutch SMB sites we check? Yes. And that is exactly our point.

Why this concerns your business

You might think: "this sounds technical, this is something for my developer". That is partly true. But it also concerns you as a business owner, for four concrete reasons.

First reason: missing security headers directly increase the risk of XSS and clickjacking attacks. An attacker who can inject JavaScript through a contact form can steal sessions, redirect users to phishing pages, or perform actions on their behalf. This is not theoretical. This is the most common class of web attacks.

Second reason: during due diligence by larger clients, partners or investors, your site gets scanned automatically. Tools like SecurityHeaders.com grade every site from A to F. If you come back with a D or F, that is a red flag. Many B2B contracts now explicitly require that you have "industry-standard security headers" in place.

Third reason: NIS2 and other compliance frameworks expect appropriate technical measures. Security headers are one of the cheapest, most visible examples of such a measure. No regulation lists them explicitly, but if an auditor asks what you do about web security and you open with "we have CSP and HSTS correctly configured", you are already ahead.

Fourth reason: it costs very little. Configuring this full set of headers correctly is a matter of a few lines in your web server or CDN settings. An hour of work for someone who knows what they are doing, and no ongoing maintenance after that. The benefit-to-cost ratio is remarkably good.

Check yourself in 30 seconds

If you want to check your own site right now, you have two options.

The quick way: go to securityheaders.com, enter your domain, and within a second you get a letter grade and a list of what is missing. No installation, no account. Good for a first impression.

The direct way: open a terminal (PowerShell or Git Bash on Windows, Terminal on macOS or Linux) and type curl -I https://yourdomain.com/. You will see exactly what your server sends, without any external tool in between. Compare the output to the six headers above. What is there? What is missing?

If the whole list is absent, your site is probably sitting behind a standard web server configuration that was never adjusted. Not rare. And no longer acceptable in 2026.

What you can do now

Two directions, depending on what you are looking for.

Do you want to understand how security works and learn to investigate it yourself? The TCAI Solutions academy teaches you from scratch. Commands, tools, exercises, real examples. You do not just learn the theory, you apply it to real targets with guidance. Sign up for the academy

Or do you just want it sorted, without going into the technical details yourself? KECIAI, our subsidiary for development and web services, handles security configurations like these from start to finish. You do not need to know any of the details. keciai.nl

Checking your own headers takes 30 seconds. The rest of your security does not, but this first step does. Do it today.