Service
Website Security
What you get
- An architecture with no database, no admin login and nothing executing on request
- Security headers and a content security policy configured and verified
- Forms hardened against spam, injection and cross-site request forgery
- A written incident plan, so a bad day is a procedure rather than a panic
Website Security in detail
Security for businesses, not for headlines
Website security is usually sold with the wrong story. The picture is a hooded figure targeting your company; the reality is a script working through a list of millions of domains, testing for software versions with published vulnerabilities. It is entirely indiscriminate, it runs constantly, and it does not care how small you are.
The consequences are unglamorous but expensive. Spam pages injected into your site for somebody else's search rankings. A conditional redirect that only fires for visitors arriving from Google, so you never see it yourself. Your hosting used to send phishing email until your domain's reputation is ruined. A browser warning that stops every visitor at the door. Weeks of clean-up, and a search position that took years to build gone in days.
Our approach is unfashionably practical: reduce the number of places an attacker can aim at, configure the protections browsers already offer, keep software current, and have a tested plan for the day something still goes wrong.
Start by removing the targets
The most effective security work happens in the architecture, before any hardening.
No database. Content is stored as Markdown in a Git repository and compiled into HTML when the site is built. There is no database to be injected into and no database credentials in play on the public site.
No public login. The editing interface is authenticated against GitHub and is not part of the public website. There is no /wp-login.php equivalent to brute-force, and no password of yours that could be reused from a breach elsewhere.
Nothing executing per request. Pages are static files. When a visitor requests one, a file is returned. There is no code interpreting their input on the way through, which is where a large proportion of web vulnerabilities live.
No plugin ecosystem. Third-party plugins are the leading cause of compromise on small business websites, and the risk grows with every one installed. We use a small number of well-maintained dependencies and review them monthly.
The remaining dynamic surface — the contact form — is deliberately narrow, and gets attention accordingly. This is a large part of why we build the way we do; see website development for the detail.
Configure what the browser already offers
Modern browsers will enforce a great deal on your behalf if the site tells them to. Most sites never bother. We configure and verify:
- HTTP Strict Transport Security, so browsers refuse to connect over plain HTTP even if a link or an old bookmark tries to
- A Content Security Policy listing precisely which origins may serve scripts, styles, images, fonts and frames — the single most effective mitigation against cross-site scripting
X-Frame-Optionsandframe-ancestors, preventing your pages being embedded in someone else's site for clickjackingX-Content-Type-Options: nosniff, so a file cannot be coerced into being interpreted as something it is not- A restrictive Permissions Policy, switching off camera, microphone, geolocation, payment and browsing-topics access that the site has no use for
- A sensible Referrer Policy, so full URLs are not leaked to third parties
Each of these is a few lines of configuration. Together they close off a meaningful range of attacks, and they cost nothing to run.
Protecting forms and enquiry data
Your contact form accepts input from strangers and puts it somewhere that matters, which makes it the most sensitive part of most business websites.
Validation happens on the server. Client-side validation is for the user's benefit; it can be bypassed trivially. Every field is validated and sanitised again on the server against the same schema, with control characters stripped and lengths capped.
Submissions go through a server action, not a public endpoint. The framework verifies the request origin against the host, which means cross-site request forgery is handled at the platform level rather than by hand-rolled tokens.
Bot traffic is filtered in layers. A honeypot field that no real visitor can see or focus, a rate limit per client, and reCAPTCHA v3 scored on the server. We use v3 rather than a checkbox challenge specifically because it asks nothing of the user and therefore creates no accessibility barrier — puzzle challenges are a genuine problem for people with visual or cognitive impairments.
Output is escaped, always. Content is sanitised when it is rendered, so even a compromised editor account cannot inject script into a visitor's browser. Structured data is generated from typed objects rather than string concatenation.
Personal data is minimised. The form asks for what is needed to reply and nothing more. Enquiries go straight to your CRM; we do not build up a shadow copy of your customer database.
Credentials and secrets
Every secret — CRM client secrets, refresh tokens, reCAPTCHA keys, organisation identifiers — is held in an environment variable, injected at runtime, and never committed to the repository. Anything the browser must know is separated explicitly from anything it must not.
Access tokens are exchanged server-side and cached in memory for the life of the process. They are never placed in a cookie, a URL or a page body, so they cannot leak through browser history, a referrer header or a shared screenshot.
If you have inherited a site with credentials committed to a repository or hard-coded into a theme file — which is remarkably common — that is one of the first things we fix.
Keeping up to date
Dependencies age. A package that was fine last quarter may have an advisory against it today. We review dependencies monthly and immediately on any advisory affecting the stack, apply updates to a preview deployment, verify, and then promote to production.
For clients on a managed plan this is included and invisible. For everyone else, website maintenance covers the same ground on a scheduled basis.
Planning for the bad day
Good security assumes something will eventually go wrong. What separates a bad afternoon from a bad month is preparation.
Every client we look after gets a one-page incident plan covering:
- Who to contact and in what order
- Where the backups are, how old they are, and how to restore them
- How to take the site offline safely if that becomes necessary
- What to tell customers, and when
- The 72-hour notification obligation to the Information Commissioner's Office under UK GDPR, and how to judge whether it applies
Backups are tested rather than merely scheduled, because an untested backup is a hope. We restore to a preview environment periodically to prove the process works.
Where to start
If you are unsure how exposed you are, the sensible first step is an assessment. We review hosting, software versions, headers, certificates, forms, access control and backups, then give you a written summary ranked by real-world risk — with the things that genuinely matter separated from the noise that automated scanners like to flag.
Most assessments find two or three things worth fixing immediately and a longer list that can be dealt with in order. Occasionally we find nothing serious, and we will happily tell you that too.
To arrange one, tell us about your site or call 01420 446331. If you think you may already have been compromised, say so and we will treat it as urgent.
Where the value is
What makes the difference
Fewer places to attack
Static pages, no public login, no plugin directory and no database. Most published exploits simply have nothing to aim at.
Headers done properly
HSTS, a content security policy, frame and content-type protections, a restrictive permissions policy and a sensible referrer policy — configured and tested, not copied from a blog post.
Credentials handled correctly
Every secret lives in an environment variable, is never sent to the browser and is never committed. Access tokens are short-lived and refreshed server-side.
Honest about risk
Nobody can promise you will never be attacked. We can reduce the surface, detect problems quickly and make recovery a routine.
How it works
The steps involved
- 01
Assess
A review of hosting, software versions, headers, certificates, forms, access control and backups, with findings ranked by real-world risk.
- 02
Harden
Fix what matters: patch or remove unsupported software, configure headers, lock down forms, tighten access, enforce HTTPS everywhere.
- 03
Monitor
Uptime, certificates and dependency advisories watched continuously, so a new vulnerability is news rather than a surprise.
- 04
Prepare
A written plan covering who does what, how to restore, and how to meet the 72-hour reporting obligation under UK GDPR if personal data is involved.
Deliverables
Exactly what is handed over
- Written security assessment with risks ranked and explained in plain English
- Configured security headers and a tested content security policy
- HTTPS enforcement, HSTS and certificate monitoring
- Hardened forms with server-side validation, rate limiting and bot protection
- Dependency audit and patching, with an ongoing review schedule
- Backup and restore procedure, tested end to end
- A one-page incident response plan you can actually follow
Questions
Website Security: common questions
Our site has never been attacked. Is this really necessary?
Almost all attacks on small business websites are automated and indiscriminate. Nobody chose you; a script found a version number it recognised. The relevant question is not whether you are a target but whether you would notice, and how long recovery would take.
What actually happens when a small business site is compromised?
Usually it is quiet: hidden spam pages added for someone else's SEO, a redirect that only fires for visitors arriving from search, or your server used to send phishing email. The cost is a search penalty, a browser warning and days of clean-up — not a dramatic defacement.
Do we need a firewall or a security plugin?
If you are running a database-driven CMS, probably yes. Part of the point of how we build is that those layers become largely unnecessary: there is no login form to brute-force and no plugin to exploit, so there is much less for a firewall to defend.
Can you help after we have already been hacked?
Yes. We will establish how access was gained, clean or rebuild, restore from a known-good backup, request review from Google Search Console where a warning has been applied, and then close the original hole so it does not recur.
Ready to talk about website security?
Send a couple of sentences about the situation. We will reply with what we would do, what it would cost and how long it would take.
Related services
Often needed alongside this
Managed Websites
One monthly fee covering hosting, security, updates, monitoring and the changes you need.
Website Maintenance
Scheduled care that stops small problems becoming expensive ones.
Website Development
Fast, secure builds on modern foundations, with content you can edit yourself.
Start a conversation
Tell us about your project
A few details are enough to get a useful answer. We will read it properly, look at what you have now, and reply with honest advice — even if that advice is that you do not need us.
- A reply within one working dayUsually the same day. You will hear from the person who would do the work, not a sales team.
- A fixed price before anything startsWe quote for the whole project, in writing, with the scope set out plainly. No hourly surprises.
- Local, if that matters to youWe work with businesses across Surrey and Hampshire, and further afield. Meetings in person or online.