Website Security Basics Every Business Owner Should Actually Do

Website security advice for small businesses tends to swing between two unhelpful extremes. One side hands you a list of enterprise controls — SOC 2, threat modeling, red teams — that bear no resemblance to the realities of a five-person service business. The other side reduces everything to "use a strong password" and a free SSL certificate, then acts surprised when the contact form starts mailing spam to the world.

The truth sits in the middle, and it is shorter than most people think. There is a real list of basics that almost every small business site should be doing, and a separate list of things that get sold as essential but rarely move the needle for a business under a hundred employees. This post is about the first list.

The framing comes from years of running website care plans for service businesses, plus the standards that actually matter: OWASP, NIST's Cybersecurity Framework, and Mozilla's Web Security Guidelines.

HTTPS Is the Floor, Not the Ceiling

Every site needs HTTPS in 2026. This is not a debate. Browsers mark non-HTTPS pages as insecure, search engines deprioritize them, and password fields trigger warnings. Free certificates from Let's Encrypt make it cost nothing.

But HTTPS alone is not enough. Three details get missed even on sites that have a green padlock:

• Force HTTPS for every request. Add a permanent redirect from http:// to https:// at the server or CDN layer. Half-configured sites still respond to plain HTTP, which is an opportunity for downgrade attacks.
• Add HSTS. The Strict-Transport-Security header tells browsers to refuse to connect over plain HTTP for a defined period. MDN's HSTS reference covers the values. A reasonable starting point is max-age=31536000; includeSubDomains.
• Monitor certificate renewal. A certificate that fails to renew silently is a multi-hour outage waiting to happen. If your stack uses Let's Encrypt, confirm the renewal cron actually runs.

You can verify all three on any URL in a few seconds with the SSL Labs Server Test or the Mozilla Observatory.

Security Headers: Free Defense in Depth

Security headers are the most underused tool in small business web security. They cost nothing to add, they provide real protection against common attacks, and most sites still ship without them.

The headers worth setting:

• Content-Security-Policy (CSP) — restricts which scripts, styles, and resources the browser will execute. The single most impactful header for preventing cross-site scripting (XSS). Start with MDN's CSP guide and roll out in Content-Security-Policy-Report-Only mode first to catch breakage.
• Strict-Transport-Security (HSTS) — already covered above.
• X-Content-Type-Options: nosniff — prevents the browser from guessing MIME types, which is a known XSS vector.
• Referrer-Policy: strict-origin-when-cross-origin — controls how much URL information leaks in the Referer header to third parties.
• Permissions-Policy — disables browser features (camera, microphone, geolocation, etc.) the site does not need. MDN's Permissions-Policy reference lists the directives.
• X-Frame-Options: SAMEORIGIN or a CSP frame-ancestors directive — prevents clickjacking by blocking your site from being embedded in other sites' iframes.

Mozilla Observatory will grade your site against all of these and tell you exactly what is missing. Going from a typical "F" to an "A" usually takes a single pull request and a small amount of CSP tuning.

CSP is the one that requires real thought. Strict CSPs break embedded analytics, ad pixels, A/B test scripts, and chat widgets. The right move is to inventory what your site loads, allow only those origins, and use nonces or hashes for any inline scripts you cannot eliminate. Plan a few hours for the first roll-out; after that it is mostly maintenance.

Authentication: MFA Is the Bar

Compromised credentials are the most common entry point for breaches at every size of business, including yours. The defense is multi-factor authentication, applied to every account that can change anything.

The accounts that should have MFA enforced:

• Domain registrar. A lost domain is an existential business problem. Registrar accounts are also a common target precisely because they are often forgotten.
• DNS provider if separate from the registrar.
• Hosting provider and any platform dashboard (Vercel, AWS, Cloudflare, etc.).
• CMS admin accounts.
• Email tenant (Microsoft 365, Google Workspace).
• Any SaaS that holds customer data, payment data, or has billing rights.
• GitHub, GitLab, or wherever your code lives.
• Password manager.

Prefer hardware keys or passkeys to SMS-based codes. SMS codes are still better than nothing but are vulnerable to SIM swapping. The NIST Digital Identity Guidelines (SP 800-63B) explicitly recommend phishing-resistant authentication where it is available.

If your team is small enough that you know everyone by name, this is realistic to enforce in a single afternoon. If it has been a while since you reviewed who has access to what, that audit is overdue.

Secrets Management: Stop Pasting Keys in Slack

API keys, database passwords, third-party tokens — these are the credentials that get leaked the most often, usually in three ways:

• Committed to a public Git repository because someone hardcoded them in an .env file that was not in .gitignore.
• Shared over Slack, email, or a project management tool, then archived forever.
• Stored in a developer's terminal history or a spreadsheet that gets passed around.

The fixes are well-trodden:

• Use a real secret store. Your hosting provider almost certainly has one (Vercel environment variables, AWS Secrets Manager, Cloudflare secrets, etc.). For team-shared credentials, 1Password or Bitwarden handles this well.
• Never commit secrets. Use git-secrets or gitleaks as a pre-commit hook. GitHub's secret scanning catches some categories of leaks automatically.
• Rotate on schedule. Quarterly is fine for most service businesses. Always rotate immediately when someone leaves or when credentials are exposed.
• Use scoped tokens. Many APIs let you generate read-only or write-restricted keys. A leaked read-only token is far less catastrophic than a full-admin one.

The OWASP Secrets Management Cheat Sheet is the most thorough single reference if you want to go deeper.

Software Updates: The Unsexy Drumbeat

The vast majority of public-facing site compromises in the small business space are not zero-days. They are six-month-old vulnerabilities in plugins, themes, and CMS cores that nobody updated.

A workable cadence:

• Critical security patches within 48 hours. Hosting providers and CMS platforms usually announce these explicitly.
• Routine updates monthly, applied to a staging environment first when possible.
• Major version upgrades scheduled and tested. Do not let yourself fall more than one major version behind.

If you are on WordPress, the plugin and theme ecosystem is your single largest attack surface. The WPScan vulnerability database tracks known issues across thousands of plugins. Audit annually for plugins that have not seen a release in over a year — abandoned plugins are a common path in.

If you have moved off WordPress to a modern stack — and we have written about why and how to do that — your update surface is mostly framework dependencies and Node packages. GitHub Dependabot will open pull requests for vulnerable dependencies automatically.

Backups That Are Actually Restorable

A backup is only useful if it is recent, complete, and restorable. Most small business backup setups fail at least one of those three.

The bar:

• Daily automated backups of database and file storage.
• Stored off-host. A backup on the same server as the site is not a backup; it is a copy. Use a separate cloud account, a separate provider, or both.
• Encrypted at rest with keys you control.
• Retained for at least 30 days for daily backups, with monthly snapshots held longer.
• Restored on a schedule. A backup you have never restored is a hope, not a plan. Pick a quarter and actually do a test restore on a staging environment.

The 3-2-1 backup rule is still the right mental model: three copies of your data, on two different media, with one stored off-site.

Incident Response Without a SOC

Most small businesses skip incident response planning because it sounds like enterprise overkill. It is not. Even a one-page document beats trying to figure things out at 2 AM with a defaced homepage.

The minimum:

• A list of who to call. Hosting provider support, the developer who can restore from backup, the registrar to lock the domain if it gets transferred, the lawyer for breach notification questions.
• Where the backups live and how to restore them. Written down. Not in someone's head.
• A defined "rollback" procedure — how to revert the site to a known-good state.
• A status page or a fallback communication channel so customers can see "we know, we're working on it" rather than calling support.
• Notification thresholds. What triggers calling a lawyer? What triggers notifying customers? Decide this when you are calm, not when you are panicking.

NIST's Computer Security Incident Handling Guide (SP 800-61) is the government reference, written for organizations larger than yours but useful as a vocabulary.

For service businesses where the website is the front door but not the only system that matters, an incident plan also covers email, payment processing, and any custom internal software that the team relies on day to day. The plan does not have to be long; it has to exist before you need it.

What's Optional for a Small Business Site

To be useful, this list also has to be honest about what most small business sites can deprioritize:

• Web Application Firewalls are great if your hosting provider includes one (Cloudflare, AWS, etc.) but rarely worth a separate purchase for a marketing site.
• DDoS mitigation beyond what your CDN provides is unnecessary for almost every site under 100k monthly visitors. If you are a target, you will know.
• Bug bounty programs make sense for SaaS products holding sensitive data, not for a service business website.
• Penetration tests are valuable annually for sites with login areas and customer data, expensive overkill for static marketing sites.

Spend the budget where the actual risk lives.

A Realistic Annual Cadence

If you do nothing else, run this loop once a year and after any major change:

1. Confirm HTTPS is forced and HSTS is set.
2. Run Mozilla Observatory and fix anything below an A grade.
3. Audit who has access to the registrar, hosting, CMS, email, and any critical SaaS. Remove anyone who left.
4. Verify MFA is enforced on every account that can change anything.
5. Rotate API keys and tokens that have not been rotated in the last twelve months.
6. Restore a backup to a staging environment and confirm the site comes back.
7. Update or write the one-page incident response document.

That is most of the security posture a small service business actually needs. It is a few days of work spread across a year, and it is the difference between an awkward but recoverable incident and the kind of breach that ends up in the local news.

If this is the kind of work you would rather not own personally, it is part of every website care plan we run, and we will pull a free audit of your current site against this list if you want a starting baseline. Most sites we look at are passing about half of it. Getting to the other half is rarely as expensive or as scary as it sounds.