Your site has HTTPS. The padlock shows in the browser bar. That handles one thing well: it encrypts the data traveling between a visitor's device and your server so no one can read it in transit. What it does not do is stop an attacker from injecting malicious scripts into your pages, trick your visitors into clicking something on a fake overlay, or let your browser know that it should refuse to load content from untrusted sources. That is the job of HTTP security headers, and most small business sites have none of them.
This post covers the six headers that matter most for a service business site, what each one does in plain terms, and what the absence of any of them actually costs you in practice. It fits into a broader look at everything a service business website needs at the infrastructure level, but you can read this section on its own.
What does HTTPS actually do?
HTTPS encrypts the connection between a visitor's browser and your web server, so data cannot be intercepted or read while it is moving across the internet. The "S" in HTTPS stands for "secure" and is made possible by an SSL (or more accurately, TLS) certificate, a small file installed on your server that proves your domain is who it claims to be.
Before HTTPS became widespread, any coffee shop Wi-Fi could let someone read exactly what you were sending to a website: form submissions, passwords, contact details. Encryption closed that gap. Google also started treating HTTPS as a ranking signal in 2014, so most hosting providers now issue free SSL certificates automatically via services like Let's Encrypt.
What HTTPS does not do is worth understanding just as clearly. It says nothing about whether the code on your page is trustworthy, whether your site can be embedded in a malicious frame, or whether scripts from unknown third-party sources are allowed to run. Those controls live in headers, and they are separate from your certificate entirely. You can have a valid SSL certificate and still have a site that is trivially easy to attack at the application layer.
What are HTTP security headers?
Security headers are short instructions your server sends to a visitor's browser alongside every page response, telling it how to behave when rendering your site. They are not visible to your visitors and they do not change how your site looks. They are a set of rules the browser follows in the background.
Think of them as a policy document attached to every page load. One rule might say "never load this page inside another site's frame." Another might say "only run scripts that come from our own domain." Another might say "always use HTTPS even if someone links to the http:// version." Each rule is one line in the server response. Adding all of them takes a few minutes if your infrastructure supports it. Skipping them leaves meaningful attack surface open, the kind that a determined attacker or an automated scanner will find.
The grade most small business sites receive on their first security header audit at securityheaders.com, even when they have a valid paid SSL certificate installed.
When we run a security header audit on a new client site, the modal grade is an F. That holds even for sites with paid SSL certificates and professional hosting. The two headers that move the needle fastest for a service site are HSTS, which forces HTTPS unconditionally, and X-Frame-Options, which blocks clickjacking on booking pages. Those two alone take a site from a failing grade to a passing one in most cases, and they are both single-line additions.
What is HSTS and why does it matter for your booking form?
HSTS (HTTP Strict Transport Security) tells every browser that has ever visited your site to use HTTPS automatically on all future visits, with no exceptions. Without it, the very first HTTP request can go out unencrypted before the server has a chance to redirect it, creating a brief window for interception.
Here is the practical version: imagine a patient or customer clicks an old link to your site that still begins with "http://" rather than "https://". Without HSTS, their browser sends that initial request in plain text. Your server responds with a redirect to HTTPS, and from that point forward the connection is encrypted. But that first unencrypted request already traveled across the network. With HSTS, the browser already knows from a previous visit that your site requires HTTPS and upgrades the request itself, before anything leaves the device.
The header looks like this in a server config: Strict-Transport-Security: max-age=31536000; includeSubDomains. The max-age value (in seconds) tells the browser how long to remember the rule. One year is standard. The includeSubDomains flag applies the same rule to any subdomain, which matters if you have a booking portal or client login on a separate subdomain.
What is X-Frame-Options and how does it protect your booking page?
X-Frame-Options prevents your site from being loaded inside a hidden iframe on another page. The attack this stops is called clickjacking: an attacker places your booking page inside an invisible frame on their site, positions it precisely over a button they control, and tricks a visitor into clicking your booking form while they think they are interacting with something else.
For a service business, booking pages and contact forms are exactly the targets. Setting this header to SAMEORIGIN means your pages can only be embedded on your own domain. Setting it to DENY means they cannot be framed at all, anywhere. Either setting closes the clickjacking vector completely.
A dental practice we worked with discovered this gap the hard way. Their WordPress site had been compromised through a vulnerable plugin. Patients who clicked the Book Appointment button were being silently redirected to a spam site for several weeks before the office noticed. That specific attack used a script injection rather than a frame, but the vulnerability chain is similar: no content policy, no frame protection, an outdated plugin, and a site that had never been audited. Once the redirect was caught and cleaned, we added X-Frame-Options and a Content Security Policy as part of the recovery pass. The same two headers that would have made the initial injection far harder to pull off.
What is a Content Security Policy?
A Content Security Policy (CSP) is a header that tells the browser exactly which sources of content are allowed to run on your page. Scripts, stylesheets, images, fonts, forms: each type of resource can have its own allowlist. Anything not on the list gets blocked before it runs.
This is the most powerful header on this list and also the most complex to configure correctly, because a CSP that is too strict will break your own site. If your booking widget, analytics script, or chat tool loads from a third-party domain and you forget to include that domain in your CSP, visitors will see a broken page.
For most service sites, a reasonable starting point is a "report-only" mode: the browser flags violations without actually blocking anything, so you can see what would break before you enforce the policy. After a week of report-only data, you have a clear picture of every source your site legitimately loads and can write a CSP that allows exactly those sources and nothing else.
The practical benefit for a small business site is script injection protection. If a plugin is compromised or an attacker finds a way to inject code into your site, a well-configured CSP can prevent that injected script from running at all, because it comes from an untrusted source. It is not a substitute for keeping plugins updated, but it is a meaningful backstop when something slips through.
What does X-Content-Type-Options do?
X-Content-Type-Options with the value nosniff tells the browser to trust the content type your server declares and not try to guess it. Without this header, some browsers will attempt to "sniff" the type of a file by reading its contents, which can lead to a browser executing a file as a script when your server intended it to be treated as plain text or an image.
This is one of the simplest headers to add and has essentially no downside. The header is one line: X-Content-Type-Options: nosniff. It belongs on every site and is one of the first things the OWASP Secure Headers Project recommends.
What is Referrer-Policy?
The Referrer-Policy header controls how much information is passed to other sites when a visitor clicks a link and leaves yours. By default, browsers often send the full URL of the page the visitor was on to the destination site, including any query parameters that might contain session tokens, search terms, or identifiable information.
For a service business, the most common setting is strict-origin-when-cross-origin. This sends your domain name to other sites (so your analytics and ad platforms can attribute traffic correctly) but strips any path or query parameters, so sensitive details do not travel with the referrer. It is a privacy protection for your visitors that also keeps you on the right side of data handling expectations.
What is Permissions-Policy?
Permissions-Policy (formerly Feature-Policy) controls which browser features your site is allowed to use, and specifically prevents third-party scripts embedded on your site from accessing features you have not explicitly enabled. The features in question include the camera, microphone, geolocation, and payment APIs.
For a typical service site that has no need for camera or microphone access, setting a restrictive Permissions-Policy means that even if a third-party script you load is malicious, it cannot silently activate those features. The header might look like: Permissions-Policy: camera=(), microphone=(), geolocation=(self). This says: camera off, microphone off, geolocation only from your own origin.
How do you actually add these headers to your site?
Where you add security headers depends entirely on your hosting infrastructure. There are three common paths.
Cloudflare: If your site runs behind Cloudflare (even on the free plan), you can add response headers through the Transform Rules section of the dashboard. No code changes to your site, no server access needed. This is the fastest path for most small business sites and takes about ten minutes to configure all six headers.
Vercel or Netlify: Both platforms support custom headers through a configuration file (vercel.json or netlify.toml). You add a headers block that specifies which paths get which headers. The configuration takes a few lines and deploys with your next push.
Traditional hosting (Apache or Nginx): Apache sites can set headers in an .htaccess file using the mod_headers directive. Nginx sites add a add_header block in the server or location config. Both approaches are well-documented, but they require access to your server configuration files, which some managed hosting plans restrict.
If your site lives on a fully managed builder like Squarespace or basic Wix, your options are limited. These platforms control the server layer and do not expose header configuration to site owners. In that case, proxying through Cloudflare is usually the only practical path to adding security headers without migrating to a different infrastructure.
The managed hosting post in this cluster goes deeper on the trade-offs between managed builders and infrastructure you actually control, including what you give up on the security side when you trade control for convenience.
How do you check what security headers your site has right now?
Go to securityheaders.com and enter your domain. The tool grades your headers from A+ to F and shows exactly which headers are present, which are missing, and what each one does. It is free, takes five seconds, and gives you a specific action list.
Most service business sites score an F on the first check. That is not an indictment of the site overall; it reflects the fact that header configuration is almost never included in a basic website build or managed hosting setup. The builder or developer who built the site likely configured the design and content correctly, without ever touching server-level security policy, because most clients never ask about it.
A second useful tool is the Mozilla HTTP Observatory at observatory.mozilla.org. It runs a broader set of checks and includes HTTPS configuration quality alongside the header audit, so you can see both the certificate health and the header posture in one report.
The infrastructure layer of your site, including hosting, email authentication, and security configuration, fits into the foundation covered in our guide to building a website that actually works for a service business. Security headers are one piece of that foundation, and an easy one to fix once you know where to look.
Do security headers have anything to do with email security?
Security headers and email authentication are separate systems, but they share the same underlying logic: both are configuration layers that sit above the visible surface of your site or email and tell the internet how to handle your domain. HTTP security headers protect page rendering in browsers. SPF, DKIM, and DMARC protect email delivery and prevent spoofing of your domain in email.
Businesses that invest in one but not the other leave a meaningful gap. An attacker who cannot inject code through your hardened website might pivot to sending phishing emails that appear to come from your domain, targeting your customers. The email authentication guide in this cluster covers SPF, DKIM, and DMARC in the same plain-language format as this post.