The security basics for a website are HTTPS on every page, a small set of security response headers, no secret keys in browser code, strong unique logins with two-factor authentication on every account, prompt updates for any software the site runs, and as few moving parts as possible. A static site has the least to attack.
Most website security advice is written for large companies with security teams. A small business does not need most of it. It needs a short list of things done properly, and the discipline to not add things that create risk.
Our clearest example is Homes by Jan, a realtor's site we moved from WordPress to a static build. The security result was a side effect of the architecture: with no database and no admin login on the server, there is no longer anything there to attack. Gayer Law, a 305 page static site, is the same story. Nothing to patch.
This post covers the basics that apply to any site, in rough order of value.
What are the basics of website security?
The basics of website security are encrypting traffic with HTTPS, sending a few protective response headers, keeping secrets on the server, protecting every login with a strong password and two-factor authentication, keeping software updated, and reducing how much software there is. Most successful attacks on small sites exploit a gap in one of those.
In checklist form:
- Serve everything over HTTPS and redirect plain HTTP to it.
- Send security headers. A few lines of configuration.
- Keep secret keys out of browser code. Anything sent to the browser is public.
- Lock down the accounts. Registrar, DNS, hosting, email, and any admin login, each with a unique password and two-factor authentication.
- Update what you run. Content management systems, plugins, themes, and libraries.
- Remove what you do not need. Every plugin, form, and admin screen is something to defend.
- Keep a backup you have tested. Security includes being able to recover.
Notice that only two of those are about the website's code. Item 4 is the one that sinks businesses. An attacker who gets into the domain registrar or the email account does not need to hack the site at all.
Why does every website need HTTPS?
Every website needs HTTPS because it encrypts the connection between the visitor and the site, so nobody on the network in between can read or alter what is sent. Browsers label sites without it as not secure, and many modern browser features only work over HTTPS.
HTTPS used to mean buying a certificate and installing it by hand each year. Most modern hosts now issue and renew certificates automatically at no extra charge, so there is rarely a reason to be without one.
Three things to check once it is on:
- HTTP redirects to HTTPS. Type the address without the "s" and confirm you end up on the secure version.
- No mixed content. A secure page that loads an image or script over plain HTTP weakens the protection, and browsers may block it.
- The certificate renews. Automatic renewal can fail quietly. An uptime monitor that watches the certificate date catches that, as described in error monitoring for web apps.
HTTPS protects the connection. It says nothing about whether the site itself is trustworthy or free of bugs. It is the floor, not the ceiling.
What are security headers and which ones matter?
Security headers are instructions a website sends with every page that tell the browser to switch on extra protections. They cost nothing, take a few lines of configuration, and close off whole categories of attack, such as another site embedding yours in a hidden frame.
| Header | What it does | Effort |
|---|---|---|
X-Content-Type-Options: nosniff | Stops the browser guessing a file's type, so a file cannot be run as a script by mistake | Trivial |
X-Frame-Options: SAMEORIGIN | Stops other sites loading your pages inside a frame, which blocks clickjacking | Trivial |
Referrer-Policy | Limits how much of your page address is passed to other sites when a visitor follows a link | Trivial |
Strict-Transport-Security | Tells the browser to use HTTPS only for your domain from now on | Low, but be sure HTTPS works everywhere first |
Permissions-Policy | Switches off browser features the site does not use, such as camera or location | Low |
Content-Security-Policy | Lists exactly which sources of scripts, styles, and images are allowed | Real work, needs testing |
This site sets the first three for every path in its hosting configuration file. This is the actual block:
{ "source": "/(.*)", "headers": [
{ "key": "X-Content-Type-Options", "value": "nosniff" },
{ "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
{ "key": "X-Frame-Options", "value": "SAMEORIGIN" }
] }The referrer setting there means another site learns which domain a visitor came from, but not the specific page.
Content-Security-Policy is the most powerful header on the list and the easiest to get wrong. A policy that is too strict breaks your own scripts, fonts, and embedded widgets. If you add one, most browsers support a report-only mode that logs what would have been blocked without blocking it. Start there. MDN keeps a full reference to HTTP headers if you want the detail on any of these.
Why should secrets stay out of the browser?
Secrets should stay out of the browser because everything a browser downloads can be read by the person using it. JavaScript files, page source, and network requests are all visible in the developer tools. A secret API key placed in front-end code is published to every visitor.
The pattern that goes wrong is a form or widget that calls a paid service directly from the page, with the key in the script. The fix is to send the request to your own server or a small server function, which holds the key and makes the call.
Some keys are meant to be public, and providers label them that way. The test is what the key allows. If it can read private data, send messages, or spend money, it stays on the server. We go through the handling rules in environment variables and secrets.
How does having fewer moving parts make a site safer?
Fewer moving parts make a site safer because every piece of software that runs on a server is something that can have a flaw, needs updating, and can be misconfigured. A site with no database, no admin login, and no plugins has removed most of the things attackers look for.
That is the argument for static sites. The pages are built ahead of time and served as plain files. There is no login page to guess passwords on and no database to inject into. The Gayer Law site is 305 pages of exactly that.
It is not the right answer for everyone. A business whose staff edit pages daily may be better served by a content management system, and WordPress can be run safely with care. The trade is that someone has to do the caring, every month. We cover that in is WordPress secure and compare the two approaches in WordPress or a static site.
Static does not mean nothing can go wrong. Forms still post somewhere, third-party scripts still run in your visitors' browsers, and the accounts behind the site still need protecting. Each outside script you add is code you did not write running on your pages, so add them sparingly.
Frequently asked questions
Does a small business website really get attacked?
Yes. Most attacks are automated and do not choose targets. Programs scan the internet for known weaknesses in common software and try whatever they find. A small site running outdated software is attacked for being reachable, not for being important.
Is the padlock icon enough to show a site is safe?
No. The padlock means the connection is encrypted. It does not mean the site's software is up to date, that its logins are protected, or that the business behind it is honest.
How can I check my site's security headers?
Open the browser's developer tools, load a page, and look at the response headers in the network panel. Free online header scanners will also grade a site and list what is missing.
Do I need a security plugin or a firewall service?
For a static site, usually not, since there is little for one to protect. For a site with logins or a database, a firewall in front of it is worth considering, alongside prompt updates and strong passwords.
If you want a plain review of where your site stands, we can do one. Get in touch.