Five website security settings you can fix in an hour

Website security sounds like a project that needs a specialist and a budget line. Most of it isn’t. The five checks below take about an hour combined, and they cover the mistakes that actually get small business sites hacked — not exotic attacks, just unlocked doors.

Turn on HSTS so browsers can’t be tricked onto HTTP

HTTP Strict Transport Security tells browsers: always talk to this site over HTTPS, never fall back to plain HTTP, even if someone tries to force it. Without it, an attacker on the same network as your visitor can quietly downgrade the connection and read or alter traffic.

To check if you have it, open your site, look at the response headers in your browser’s dev tools (Network tab, click the main document request), and look for Strict-Transport-Security. If it’s missing, your host or CMS almost certainly has a one-line setting or config entry to add it — look for “HSTS” in your hosting panel or nginx/Apache config.

Start with a short max-age while testing, then raise it once you’re sure every page loads over HTTPS.

Add a Content Security Policy to block injected scripts

A Content Security Policy (CSP) is a header that tells the browser which sources are allowed to run scripts, load images, or submit forms on your pages. If someone manages to inject a malicious script — through a vulnerable plugin, a compromised ad script, or a comment field — a good CSP stops the browser from executing it.

Check for the Content-Security-Policy header the same way you checked for HSTS. If it’s absent, don’t rush to lock everything down in one step. Deploy it first in report-only mode (Content-Security-Policy-Report-Only), watch what gets flagged for a few days, then switch it to enforcing once you’re confident nothing legitimate breaks.

This is the one setting worth having a developer glance at, since a too-strict policy can silently break a payment widget or analytics script.

Rate-limit logins and forms

Login pages and contact forms are the two most hammered spots on any website. Bots try thousands of password combinations an hour, or flood your contact form with spam, and most sites have no limit on how often someone can try.

A rate limit caps attempts per IP address over a time window — for example, five login attempts per minute before a short lockout. On nginx this is a few lines with limit_req; most CMS platforms have a plugin or built-in setting for login throttling.

To test it, try logging in with a wrong password six or seven times quickly. If nothing slows you down, there’s no limit in place yet.

Back up, then actually test the restore

Almost every site has backups configured. Far fewer owners have ever restored one. A backup you haven’t tested is a backup you’re guessing about.

Check three things in under ten minutes:

• Backups run automatically, not only when someone remembers
• At least one copy lives somewhere other than the server itself — a separate storage bucket or offsite location
• You can actually open or restore a recent backup file without errors

When we built fortulox.com — a lottery platform with a public site, a user dashboard, and an admin panel, all shipped in two days — the backup and restore check was the first thing we verified before launch, specifically because a platform handling draws and entries has zero tolerance for silent data loss.

Keep software and plugins updated, on a schedule

Most website breaches don’t involve a clever attacker — they involve a known vulnerability in an outdated plugin, theme, or server package that was patched months earlier. Updates are boring, which is exactly why they get skipped.

Set a recurring slot, even just fifteen minutes every other week, to check for updates on your CMS core, plugins, and server-level software. If you’re running a store or booking system, test the update on a staging copy first, since plugin updates occasionally conflict with each other.

Sites with more moving parts need this more, not less. Vareno.fun, a store shipping to 27 EU countries, runs on a stack with several payment and tax integrations — exactly the kind of setup where one unpatched dependency can cascade into checkout failures across every market at once.

What an hour actually buys you

None of these five settings require rebuilding anything. They require someone to check a header, flip a setting, run a test restore, and put a recurring reminder on a calendar.

If you’d rather have someone run through this list once and wire up the monitoring so you don’t have to think about it again, that’s the kind of hour-long job we fold into most build and maintenance work.