Website and web application security for small business

Most small businesses treat their website, their CRM, and their line-of-business web applications as separate concerns. The website is “marketing.” The CRM is “sales.” The booking tool or portal is “operations.” They run on different platforms, managed by different people, and nobody owns the security of all of them together.

Attackers do not see it that way. To them, every public-facing system with a login page or a form is a potential entry point, and every one that is unmonitored is an opportunity. A compromised website can be used to push malware to visitors, host phishing pages, or pivot into the business’s internal systems. A compromised CRM can leak every customer record the business has ever touched. A compromised web application can be a foothold for ransomware or a direct path to financial fraud.

This guide covers what a practical web security posture looks like for a small business, the specific risks to look at across each system type, and the security measures that actually make a difference.

Why web security matters more than it used to

Small business websites used to be mostly brochures. If the site went down, it was embarrassing, but the business kept running. That is not true anymore. For most SMBs today, the public web presence is tied directly to revenue:

• Websites capture leads. A contact form, a newsletter signup, or a chatbot sends data directly into sales pipelines. Downtime or compromise interrupts lead flow immediately.
• CRMs run sales and customer success. Every call, every deal, every renewal conversation lives in the CRM. Without it, sales people are flying blind and customer success cannot answer questions.
• Web applications run core operations. Booking systems, patient portals, client intake forms, e-signature tools, project management platforms – these are not optional anymore. An outage is a business outage.
• Every system holds data that regulators care about. Customer names, email addresses, payment information, health data, financial records. A breach of any of it triggers notification requirements, potential fines, and reputational damage.

The attack surface is wider, the data at stake is more valuable, and the downtime is more expensive than it was five years ago. Small business web security has to catch up.

The main threats to web-facing systems

Understanding the threat landscape is the first step toward picking the right defenses. These are the categories that matter most for SMBs.

Automated attacks and bots

Most attacks on small business websites are not manual. They are automated, running 24/7 against every public website on the internet, looking for outdated software, weak passwords, exposed admin panels, and known vulnerabilities. The bot does not care that you are a 15-person accounting firm – it is scanning every IP address in a range.

Common automated attacks include credential stuffing (trying username/password combinations from previous breaches), vulnerability scanning (probing for known unpatched flaws), content scraping (copying your site wholesale), and denial-of-service attempts (overwhelming the site with requests until it falls over).

Targeted exploitation of web applications

When a business runs a web application that handles money, personal data, or privileged business functions, targeted attacks become more likely. Attackers look for SQL injection, cross-site scripting (XSS), authentication bypasses, and logic flaws that let them access data or functionality they should not have.

The OWASP Top 10 lists the most common categories of web application vulnerabilities, and they have been remarkably consistent for years: broken access control, cryptographic failures, injection, insecure design, misconfiguration, outdated components, authentication failures, data integrity issues, logging gaps, and server-side request forgery.

CMS and plugin vulnerabilities

WordPress powers a large percentage of small business websites, and every WordPress site is running some combination of core software, themes, and plugins – each of which can have security issues. A single outdated plugin is the single most common way WordPress sites get compromised.

The same dynamic applies to Drupal, Joomla, and other content management systems. The platform itself is typically secure when kept current, but the ecosystem of third-party plugins is uneven in quality.

Credential theft and account takeover

Phishing targeting the people who administer the website, the CRM, or the web application is one of the most effective paths to compromise. If an attacker gets the admin’s password, every technical control in front of the system is bypassed.

Credential stuffing (using credentials stolen from other breaches) is also rampant. Any employee who reuses passwords across services has already given attackers a way in.

Supply chain compromise

Third-party scripts, libraries, and integrations are everywhere on modern websites – analytics pixels, chat widgets, payment scripts, embedded forms. Each one is code that runs on your site that you did not write, maintained by a vendor whose security you cannot audit. When the vendor is compromised, every site using their code is at risk.

Denial of service

DDoS attacks against small businesses used to be rare. They are becoming more common, both as extortion attempts (“pay us or your site stays down”) and as cover for other attacks. A small business site cannot absorb a sustained DDoS without help from its hosting provider or a CDN.

The security measures that actually help

Here is the stack that meaningfully reduces risk across websites, web apps, and CRMs. Not every business needs every layer, but most businesses need more of it than they currently have.

Web Application Firewall (WAF)

A WAF sits in front of the website or application and inspects every incoming request, blocking the patterns associated with known attacks – SQL injection payloads, XSS attempts, malicious bot traffic, exploit attempts against known CVEs. It is the single highest-impact control for any public-facing web system, because it catches the automated noise before it ever reaches the application.

Cloud-delivered WAFs from Cloudflare, AWS, or Sucuri are generally the most practical choice for SMBs. They update their rule sets continuously based on threats seen across their entire customer base, and they require no on-server software. Self-hosted WAFs (ModSecurity, for example) work too, but they require more ongoing tuning.

CDN and DDoS protection

A Content Delivery Network caches your static content across a global network of servers, which both speeds up the site for visitors and absorbs traffic spikes – including malicious ones. A good CDN in front of a small business site makes denial-of-service attacks dramatically harder to pull off, because the attacker is fighting the CDN’s capacity, not your origin server’s.

Cloudflare is the most common choice for SMBs because the free tier is genuinely useful and the paid tiers add advanced protections without enterprise pricing. AWS CloudFront, Fastly, and Akamai are alternatives, usually for larger or more technical businesses.

Bot protection

Generic rate limiting and WAF rules catch some bot traffic, but determined scrapers, credential stuffers, and carding attackers use techniques that evade basic defenses. Dedicated bot protection distinguishes real users from automation using a mix of signals – JavaScript challenges, behavioral analysis, device fingerprinting, and reputation data.

Cloudflare’s Bot Management, Akamai Bot Manager, and DataDome are the recognizable names in this space. Managed hosting providers increasingly include bot protection as part of the hosting layer too – some platforms run edge bot detection and a WAF across every hosted site by default, so customers do not have to configure a separate bot management product to get the benefit. This matters for SMB websites because the alternative is either paying for an enterprise bot product or leaving the site exposed to whatever gets through the CDN.

DNS security

The domain name system is a quiet but common attack vector. DNS hijacking, where an attacker changes a domain’s DNS records to redirect traffic to a malicious server, can be catastrophic – email starts going to the wrong place, the website points to a phishing clone, and recovery takes hours or days.

Protection here comes from enabling two-factor authentication on the DNS provider account, using a reputable registrar that supports DNSSEC, and turning on registrar-lock on the domain to prevent unauthorized transfers. These are small steps but they close a very real attack path.

SSL/TLS everywhere

Every page on the website, every login to the CRM, every API call to the web application should be encrypted. Let’s Encrypt makes free SSL certificates trivial to obtain, and modern hosting providers automate the renewal. There is no longer a cost excuse for running anything over HTTP in 2026.

Enforce HTTPS with HSTS headers so browsers refuse to connect over HTTP even if someone types it. Disable old TLS versions (1.0 and 1.1) which have known vulnerabilities.

Strong authentication on every admin account

Every account that can change the website, CRM, or web application needs multi-factor authentication. This is the single most important control for preventing account takeover, and it is free on almost every platform.

Phishing-resistant MFA (hardware keys, Authenticator app with number matching) is preferable to SMS codes. MFA alone is not enough, but it is the foundation everything else builds on.

Patch management

Every CMS, plugin, theme, library, and server component needs to be kept current. For WordPress, enabling automatic updates for minor releases and keeping plugins current is the minimum bar. For custom web applications, establish a monthly review cycle for dependencies, and monitor security advisories for the libraries you use.

Unpatched software is how the majority of small business compromises happen. The fix is not technically complicated – it is an operational discipline problem.

Monitoring and logging

You cannot respond to an incident you do not know about. Every web-facing system should be sending logs somewhere you can actually look at them, with alerts for the patterns that matter – repeated failed logins, privilege escalations, admin actions outside business hours, unusual data exports.

For SMBs, this is usually where managed security services earn their value. Nobody on a small team is watching logs at 2am. A managed security provider’s SOC is.

Regular backups with offsite copies

Every web system needs backups you can actually restore from. This means tested backups (not just configured ones), stored offsite (not on the same server as the primary), retained long enough to catch a breach you did not notice for weeks (at least 30 days, 90 is better).

For CMS-based websites, combine database backups with file backups. For web applications, include the underlying database and any user-uploaded content. For CRMs, understand what the vendor backs up and what you are responsible for – the line is different for every platform. Backup-as-a-service fills the gap when the built-in options are not enough.

Vulnerability scanning and penetration testing

Automated vulnerability scanners (Nessus, Qualys, Rapid7) check for known issues on a schedule. They are good at finding outdated software versions, misconfigurations against a checklist, and missing patches. They are not good at finding the issues that actually get web applications breached.

Penetration testing is where a real person, usually a security professional, actively tries to break into the application the same way a real attacker would. This matters far more for web apps than for static websites, for a few reasons.

Web apps have business logic that scanners cannot understand. A scanner can tell you the login page uses TLS. It cannot tell you that the password reset flow lets anyone reset anyone else’s password by changing the user ID in the URL. It cannot tell you that the discount code field accepts negative numbers and lets a customer get paid to check out. It cannot tell you that the API exposes endpoints that bypass the UI’s permission checks. These are logic flaws, and they are exactly what attackers look for.

Custom code has no community vetting. A WordPress plugin used by 100,000 sites has been poked at by thousands of researchers, attackers, and bug bounty hunters. A custom web application built for one business has been looked at by the developers who built it and nobody else. The first time someone with attacker mindset reviews it should not be after it has been breached.

Chained vulnerabilities are invisible to scanners. A modern web app breach is rarely one big vulnerability. It is usually a chain: an information disclosure flaw reveals a username, weak rate limiting allows credential stuffing, a privilege escalation bug lets the compromised account access admin functions, an unprotected backup file gets the database. Each individual flaw might be rated low or medium severity by a scanner. The chain is critical. Only a human pen tester sees the chain.

Compliance frameworks increasingly require it. PCI DSS, SOC 2, HIPAA security risk assessments, and CMMC all reference application-layer testing. If you handle payment cards, health data, or government contracts, pen testing is not optional anyway.

The economics make sense. A serious web app pen test for an SMB-scale application costs a few thousand to low five figures. The average cost of a small business data breach runs into six and seven figures when you account for incident response, notification, legal exposure, and customer churn. The math works out before you even factor in regulatory penalties.

Most SMBs do not need quarterly pen tests. An annual test of the most critical web application, combined with continuous automated scanning, is a reasonable baseline. Test again whenever there is a major release or a significant architectural change – new authentication system, new payment integration, new API surface. If the application handles money, health data, or anything covered by a compliance framework, the testing cadence is usually specified by the framework and should be followed strictly.

The deliverable from a good pen test is a report that explains each finding, ranks it by severity, and provides remediation steps the development team can act on. The follow-up matters as much as the test itself – findings that sit in a report unfixed are not security improvements. Treat the report as a project, not a document.

Least privilege access

Not everyone needs admin access to the website. Not everyone needs export permissions in the CRM. Not everyone needs read access to every record. Review the permissions on every web-facing system at least annually and remove access that is not actively needed.

This is the control with the most upside for the least cost, and it is the one most small businesses never review.

Specific considerations for each system type

Websites (WordPress, Shopify, Squarespace, etc.)

The main risks are CMS/plugin vulnerabilities, admin account takeover, and automated attacks. The defenses are a WAF in front (Cloudflare or the hosting provider’s native WAF), automatic updates, MFA on admin accounts, and regular backups.

Hosting matters more than most people realize. A managed hosting provider that handles platform patching, runs a WAF at the edge, isolates sites in containers, and monitors for compromise removes a huge amount of work from the business. Shared hosting without these protections is where most small business site compromises happen.

CRMs (Salesforce, HubSpot, Zoho, etc.)

CRMs are usually SaaS, so the vendor handles most infrastructure security. The risks that remain are on your side: account takeover, over-permissioned users, API tokens that grant broad access, and integrations that sync data to other less-secure systems.

The defenses here are MFA on every user, role-based access (sales reps do not need export rights), audit logging of unusual activity, and careful review of every integration before it is installed. When an employee leaves, revoke CRM access immediately as part of offboarding.

Custom web applications

Custom apps are where the highest-risk vulnerabilities live, because there is no vendor patching them and no large community testing them. The defenses here are code-level: secure coding practices, dependency management, pre-launch security review, and ongoing monitoring.

If you have a custom app that handles money, personal data, or privileged business functions, get it pen-tested by a qualified third party. The cost of the test is always less than the cost of a breach.

Third-party web apps (booking tools, portals, e-commerce add-ons)

Treat these like SaaS CRMs: the vendor is responsible for most of the stack, but account security, permissions, and integration hygiene are on you. Before adopting any new third-party web tool, ask about their security program – how they handle authentication, where they store data, how they respond to incidents, whether they have a SOC 2 report.

What Sequentur handles for clients

For managed IT clients, we handle web security across all of these surfaces – WAF and CDN configuration for client websites, MFA enforcement across CRM and web application accounts, DNS protection and monitoring, patch management for WordPress and other CMS platforms, backup configuration and testing, and ongoing monitoring through our MDR service.

Web security is one of those areas where the technology is relatively mature and the gaps are almost always in process and consistency. Every business has a firewall. Not every business has one that is actually blocking what it needs to block. Every business has backups. Not every business has tested them. The work of security is keeping the controls actually doing their job over time.

If your web presence has grown past the point where you are comfortable managing this on your own, schedule a call and we will walk through your stack.