Why I wrote this
Website security gets framed two ways. One is panic. Every breach is the end of the world. The other is denial. "No one would target a business this small." Both are wrong, and both stop business owners from doing the few things that actually matter.
The 2024 IBM Cost of a Data Breach Report put the global average breach at $4.88M, with the United States average at $9.36M. The same report found organisations that used security AI and automation extensively saved an average of $2.22M per incident compared to those that did not. That gap is the whole story. Most of the cost of being hacked is the cost of finding out late and fixing it under pressure.
I have shipped 250+ projects since 2009. The strongest security work I have done was leading the Payment Service at bolttech, a $1B+ unicorn, where 40+ payment provider integrations and 99.9% uptime were the bar. That kind of work shapes how I think about smaller business sites. The principles do not change. The budgets do.
This guide walks you through the five threats most likely to hit a small or mid-size business, the controls that block 90% of opportunistic attacks, and when paying for a security audit is worth it.
TL;DR
The five threats that matter for most business sites are SQL injection, cross-site scripting, broken authentication, sensitive data exposure, and DDoS. None of them are exotic. All of them are documented in the OWASP Top 10. The controls that block the majority of opportunistic attacks are HTTPS everywhere, multi-factor authentication on admin accounts, a Web Application Firewall, monthly patching, and tested off-site backups. Most breaches exploit a known vulnerability that had a patch available before the attack.
What a breach actually costs
Headline numbers are easy to dismiss. The IBM report breaks the cost into four buckets that map to real spend:
- Detection and escalation. Figuring out something is wrong, scoping it, calling in forensics. Roughly a third of the total.
- Notification. Letters, credit monitoring, legal review, regulator filings. Smaller share, but where the deadlines bite.
- Post-breach response. Credit watch, help desk, regulatory fines, settlements.
- Lost business. Customer churn, reputational damage, downtime.
Two numbers stick with me. The mean time to identify a breach in 2024 was 194 days. The mean time to contain it after identification was 64 days. So an average breach is sitting inside the company for nearly nine months before the lights come back on.
The Verizon 2024 Data Breach Investigations Report adds the texture. About 68% of breaches involved a non-malicious human element. A misconfiguration, a phished credential, an unpatched system. Only a small slice were truly novel attacks against well-defended targets.
What that means for a business owner: most of what protects you is unglamorous. Patching. Password managers. Off-site backups. The exotic stuff comes later, if at all.
The five threats that matter
1. SQL injection
Your site takes user input. A search box, a login form, a filter on a product page. That input gets used in a database query. If your code does not separate the query template from the data, an attacker can rewrite the query.
A classic example. A search box runs:
SELECT * FROM products WHERE name = 'USER_INPUT'
Type ' OR '1'='1 into the search box and you change it into:
SELECT * FROM products WHERE name = '' OR '1'='1'
That returns every row. The same trick on a login form returns the first user. The same trick on a poorly written admin page can drop tables.
The fix is one word: parameterized queries. Every modern framework (Laravel Eloquent, Prisma, Drizzle, Django ORM, Rails ActiveRecord) does this by default. The trap is the raw query you wrote "just this once" for a custom report. Audit those.
2. Cross-site scripting (XSS)
XSS is SQL injection's cousin. Instead of injecting a query, an attacker injects JavaScript that runs in another user's browser when they visit your page. Comments, profile fields, search results that echo your search term, any place where user input ends up rendered to the page is a candidate.
Once a script runs in a logged-in user's browser, it can read the session cookie, post on the user's behalf, and quietly exfiltrate anything visible on the page.
Modern front-end frameworks (React, Vue, Svelte) escape rendered values by default. The risk lives in three places: anything using dangerouslyInnerHTML, anything that renders rich text, and any older jQuery or vanilla DOM code that builds HTML by string concatenation.
3. Broken authentication
This is the largest category by volume. The 2024 Verizon DBIR put credential abuse as the top initial access vector, used in roughly 38% of all breaches. The patterns are familiar:
- Reused passwords. A user's password leaked from another site gets sprayed at your login page.
- No 2FA on admin accounts. One phished password is the whole game.
- Session cookies that never expire.
- Password resets that send a long-lived link to an inbox the attacker also owns.
The fixes are cheap. Force 2FA on every admin account (TOTP or hardware key, not SMS). Use bcrypt or Argon2 for password hashing. Expire sessions after a sane window. 24 hours is generous for most apps. Rate-limit login and password reset endpoints.
4. Sensitive data exposure
This is the bucket that catches everything from "I emailed a CSV of customer addresses to the wrong person" to "credit card numbers in plain text in the database." The common thread is that data was kept where it did not need to be, or moved somewhere it should not have gone.
Three rules cover most of it:
- Use HTTPS for everything. No exceptions for "internal" tools or admin panels.
- Do not store what you do not need. Card numbers belong with Stripe, Adyen, or Braintree, not in your database.
- Encrypt what you do store. Database-level encryption for PII, key management with a real KMS, and a hard rule against API keys in source code.
The PCI DSS 4.0 standard makes most of these mandatory if you touch card data. They are good rules even if you do not.
5. DDoS
A Distributed Denial of Service attack floods your site with traffic until it falls over. The motive is usually extortion or competitive sabotage.
DDoS is the threat business owners worry about most and the one that is easiest to outsource. Cloudflare, Fastly, Akamai, and AWS Shield all sit in front of your site and absorb attacks at the edge. Cloudflare's free tier handles a surprising amount of malicious volume. Cloudflare Pro at $20 per month covers most small business needs. For higher-stakes traffic, AWS Shield Advanced or Cloudflare Magic Transit step in.
SSL and HTTPS, briefly
If you do nothing else, do this. Every page on your site runs over HTTPS. Every form. Every admin panel. Every subdomain.
Let's Encrypt issues free certificates that browsers trust. Most modern hosts (Vercel, Netlify, SiteGround, WP Engine, Cloudflare Pages) install a certificate automatically. On a self-managed VPS, Caddy handles SSL with a four-line config. Certbot handles it for Nginx in about three minutes.
Once HTTPS is stable for a week, add HSTS:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
That stops downgrade attacks where someone on the same Wi-Fi catches your first HTTP request before the redirect fires. For the full setup including the errors people hit on the first try, see my SSL setup guide for business sites.
OWASP Top 10, simplified
OWASP publishes a top ten list of the most common web application risks. Here is the 2021 list (the current one in 2026, since OWASP refreshes every three to four years) in plain English.
| # | Risk | Plain English | Where to start |
|---|---|---|---|
| 1 | Broken Access Control | The wrong people can read or change data | Check permissions on every endpoint |
| 2 | Cryptographic Failures | Sensitive data is not encrypted | HTTPS everywhere, modern crypto libraries |
| 3 | Injection | Attackers inject code into queries | Parameterized queries, input validation |
| 4 | Insecure Design | Security was not part of the original design | Threat-model new features before building |
| 5 | Security Misconfiguration | Defaults left on, debug mode in production | Hardening checklists, infrastructure as code |
| 6 | Vulnerable & Outdated Components | Old libraries with public CVEs | Monthly patching, dependency scanners |
| 7 | Authentication Failures | Weak passwords, no 2FA, session issues | 2FA, bcrypt/Argon2, session timeouts |
| 8 | Software & Data Integrity | Tampered builds or unsigned data | Signed releases, locked CI pipelines |
| 9 | Logging & Monitoring Failures | You cannot tell when you have been hit | Central logs, alerts on anomalies |
| 10 | Server-Side Request Forgery (SSRF) | Server is tricked into making requests | Validate URLs, restrict outbound traffic |
For most small and mid-size business sites, items 1 through 7 cover the realistic threat model.
A printable checklist
Walk this once a quarter. If you cannot answer yes to anything in the Essential block, fix it this month.
Essential
- HTTPS on every page, valid certificate, auto-renewing
- HSTS configured (after 7 days of clean HTTPS)
- 2FA required for every admin account on CMS, hosting, email, cloud, Git
- Passwords hashed with bcrypt or Argon2, never MD5, SHA1, or plain text
- Off-site backups, daily, with a tested quarterly restore
- WAF in front of the site (Cloudflare, AWS WAF, Sucuri)
High priority (next 30 days)
- Core framework, dependencies, plugins all on a monthly patch cadence
- No secrets in source code; everything in env vars or a secrets manager
- No card numbers stored on your servers (use Stripe, Adyen, Braintree)
- User input validated and sanitized at every entry point
- Error pages do not leak stack traces, file paths, or database names
- Session timeouts configured (24 hours is generous)
- Logs centralized somewhere you can search
Medium priority (next 90 days)
- Security headers set: CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
- Rate limits on login, password reset, checkout, registration
- File upload restrictions and malware scanning
- Written incident response plan, kept somewhere not on the laptop
- Automated dependency scans in CI (Dependabot, Snyk, Renovate)
- Vendor security review for any third-party tool with access to your data
Nice to have
- Annual penetration test ($5K–$20K)
- Phishing-aware staff training
- Bug bounty programme (HackerOne, Intigriti)
When a security audit is worth it
A security audit is a paid review of your site by someone who finds bugs for a living. It typically covers vulnerability scanning, manual penetration testing, code review, configuration review, and a written report with prioritized findings.
Cost varies wildly. Solo consultants charge $2K–$5K for a small site. Boutique firms charge $5K–$15K. Big-four firms charge $50K+ and sell you a follow-up. For most small and mid-size businesses, the boutique-firm range is the sweet spot.
Hire one if any of the following are true:
- You handle payment data, health data, or anything regulated
- You are pre-launch on a product that will hold customer data
- You have never had an outside set of eyes on your stack
- You had a security incident before
- A partner or insurer requires it
- You are entering a new market with new compliance rules
The math is simple. A $5K audit that finds one $250K vulnerability is the cheapest insurance you will buy.
Reflecting on the pattern I see most
The clients who get into real trouble are not the ones who never thought about security. They are the ones who thought about it once, three years ago, and never came back to it. A patched 2022 install is a 2022 install. The plugin you trusted in March was sold to a new owner in November. The intern who set up the staging server has long since moved on, and the staging server is still up, with admin/admin and the production database backup in a public S3 bucket.
Security is not a project. It is a small recurring tax. An hour a month on patching, a 20-minute quarterly walk of the checklist above, an annual review with someone outside the team. The companies that pay that tax never feature in the breach reports. That is the goal.
[INSERT REAL ANECDOTE: a moment from a client engagement where slow patching or a missing 2FA almost caused a breach, to be filled in with details Adriano is comfortable sharing]
FAQ
Should small businesses worry about being targeted?
Yes. Most attacks are not targeted. The Verizon DBIR shows the majority of breaches start with automated scanning that hits anything reachable. A "no one cares about my site" hobby blog gets the same probes as a Fortune 500, and usually a worse defence.
Does my web host cover security for me?
Partially. Hosts secure the network, the OS, and (sometimes) the runtime. Your application code, your CMS, your plugins, and your admin accounts are on you. Read your host's shared responsibility document. Every reputable host has one.
Do I need to comply with GDPR, CCPA, or PCI?
GDPR applies if you handle personal data of EU or UK residents. CCPA/CPRA applies if you handle California residents and meet the size or revenue thresholds. PCI DSS applies if you take card payments, even one a year. The simplest path on PCI is to never see a card number, which most modern payment processors handle for you.
What do I do if I think I have been hacked?
Do not delete anything yet. Isolate the site behind a maintenance page, freeze backups, capture logs, rotate every secret. Then restore from a known-clean backup into a fresh environment. The full step-by-step lives in my hacked website recovery playbook.
How often should I patch?
Monthly minimum. Critical CVEs the same week they ship. Most breaches in the Verizon DBIR exploit vulnerabilities that had patches available for months, sometimes years.
Can I outsource security entirely?
You can outsource execution. You cannot outsource accountability. A managed security provider is great. A vendor who promises to "handle it" without a written scope is a future bad day.
What is the cheapest control with the best return?
Multi-factor authentication on every admin account, full stop. The 2024 Verizon DBIR puts credential abuse at the top of initial access vectors. Switching to TOTP or a hardware key on the four accounts that matter (hosting, CMS, email, cloud) takes a morning and removes the most common breach path. Cost: a $25 hardware key, optional. Time: under an hour. Risk reduction: large enough that some cyber insurers now require it before they quote a policy.
How do I know if my CMS plugins are actually safe?
Three quick checks. First, check the last update date. Anything that has not been updated in 12 months is a risk. Second, look for the plugin in the Patchstack vulnerability database or the WPScan vulnerability database for WordPress. Third, check who owns the plugin now. Plugins get sold, and a sold plugin sometimes ships a backdoor in its next "update." Run those three checks once a quarter and you are ahead of most sites your size.
Where to go next
If you are starting from zero, the order I would tell a client is: HTTPS, 2FA on admins, off-site backups, WAF, monthly patching. That is the first month. The rest of the checklist is the next quarter.
If you want a second pair of eyes on what you have today, I run security reviews as part of my fractional CTO engagements and as one-off scoped projects under custom web applications. The case study work that informs how I think about this kind of review: bolttech payment integration for the high-stakes side and Imohub real estate portal for the cost-sensitive side.
Related reading:
- Website security for ecommerce in 2026
- Hacked website recovery: the 48-hour playbook
- SSL setup guide for business sites
- WAF vs CDN in 2026
- Website maintenance: what is actually included
If you want a quick verdict on where your site sits on the checklist above, book a free strategy call. I will give you a prioritized list, no sales pitch attached.