What security headers are, and why most Thai business sites have none

When you type a domain into the check on our homepage, our server sends one request to that site, exactly as a customer's browser does every day, and reads what comes back before the page itself. That part of the response is called the headers, and it tells the browser how to treat the site.

This article explains what each finding means for a business, not for a programmer.

Your site talks to the browser before the customer sees anything

Every time someone opens a page, the server sends a few short lines before the content. They carry instructions such as "do not let other sites embed this page" or "from now on, only connect encrypted". If the server does not send them, the browser falls back to permissive defaults designed twenty years ago, when the internet had far fewer criminals.

The good news is that adding these headers takes minutes for someone who knows what to do. The bad news is that most web vendors never do it, because no client ever asks.

One: enforce encrypted connections

The technical name is HSTS. When a customer types yourshop.com without https://, the browser first tries an unencrypted connection. In that split second, anyone on the same Wi-Fi, in a cafe or an airport, can step in.

This header tells the browser "remember that this site is always encrypted". After the first visit, the browser refuses to connect unencrypted ever again.

Without it: a customer filling in a form on public Wi-Fi can be intercepted.

Two: control which scripts may run

The technical name is Content Security Policy, or CSP. A modern site runs code from many places: Google Analytics, a chat widget, a payment provider. If someone finds a way to inject code (through a poorly validated form or a vulnerable plugin), that code runs on your site as if it were part of it, and can read everything a customer types.

CSP is a list of allowed sources. Anything not on the list is blocked by the browser, even if it was successfully injected.

Without it: one small hole becomes a full theft of customer data. This is how card details have leaked from many online shops in recent years.

Three: stop other sites from embedding yours

A scammer can build a page with your site hidden underneath, transparent, and place a "claim your prize" button exactly over your "confirm transfer" button. The customer thinks they are claiming a prize; they are actually clicking your button. The technique is called clickjacking.

The X-Frame-Options header, or the frame-ancestors directive in CSP, tells the browser nobody may embed this page.

Without it: sites with logins or payments are at real risk. A pure brochure site is lower risk, but there is still no reason not to set it.

Four: stop the browser guessing file types

Some browsers are too clever. Given a file labelled as an image that looks like code inside, they may decide to run it as code. The header X-Content-Type-Options: nosniff says "trust what I told you, do not guess".

Without it: sites that accept uploads (profile photos, documents) risk a doctored file being executed as a script.

Five: control what leaks when a customer clicks away

When a customer clicks a link from your site to another, the browser tells the destination which page they came from. By default it sends the full URL. If your URL contains an order number, a customer name or a password-reset token, it leaks immediately.

A Referrer-Policy of strict-origin-when-cross-origin sends only your domain, never the page or its parameters.

Without it: data in URLs leaks to external sites and the ad trackers embedded in them.

Six: do not announce your software version

Many sites send headers like X-Powered-By: PHP/7.2.34 or Server: Apache/2.4.29 without knowing it. For an attacker this is a gift: search "PHP 7.2.34 exploit" and get a list of vulnerabilities guaranteed to apply to your site.

With it: automated attack bots pick your site as a target ahead of sites that stay quiet.

Seven: the HTTPS certificate and its expiry

The certificate is what makes the padlock appear. It expires, usually after 90 days or a year. When it does, browsers show a full-screen red warning and almost every customer closes the tab.

This happens more often than you would think, especially over long holidays, because nobody is watching. Our check shows the days remaining. Under 30 with no automatic renewal is urgent.

Eight: response time

The last item is not security, it is money. The time the server takes before sending the first byte back (TTFB) is the floor under everything else. If the server needs two seconds before it starts answering, the page is at least two seconds slow no matter how light it is, and a customer on provincial 4G waits far less than you imagine.

What to ask your web vendor

If you are hiring someone, or already have a site and want to know what the maintainer has done, ask three questions:

1. Does our site set HSTS and CSP? Can I see the values?
2. Does the HTTPS certificate renew automatically, and who is alerted if that fails?
3. Does our server disclose its software version?

If the answer is silence, or "you do not need that", you have your answer.

All of this can be checked free in five seconds on our homepage, and the full 24-item report with fixes is the security audit.