6 Common Website Security Mistakes Businesses Make (And How to Fix Them)
Table of Contents
Mistake 1: Missing Security Headers
Mistake 2: Expired or Misconfigured SSL Certificates
Mistake 4: Weak TLS Configurations
Mistake 5: Missing SPF, DKIM, and DMARC Records
Mistake 6: Not Monitoring Continuously
How ScanSentinel Catches These Mistakes
Introduction
Most website security breaches don't involve sophisticated zero-day exploits or nation-state attack chains. They exploit well-known, thoroughly documented, and entirely preventable misconfigurations.
The 2024 Verizon Data Breach Investigations Report found that the majority of breaches involved a human element or a configuration error — not advanced malware. These aren't the kinds of vulnerabilities that make headlines, but they are the kinds that get businesses into trouble every single day.
The frustrating part? Every one of these mistakes has a straightforward fix. The harder part is knowing they exist in the first place.
This article covers the six most common website security mistakes we see at ScanSentinel across thousands of domain scans. For each one, we'll explain what goes wrong, why it matters, and how to fix it.
Mistake 1: Missing Security Headers
What Goes Wrong
HTTP security headers are response headers your web server sends alongside every page. They instruct the browser to enable (or disable) specific security features. Despite being easy to configure and having zero performance impact, the majority of websites ship with few or none of them.
At ScanSentinel, we check for seven critical headers: HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, and Permissions-Policy. Across our scan history, more than half of scanned domains are missing at least four of these — and missing CSP is nearly universal on smaller sites.
Why It Matters
Each missing header represents a class of attack that your site is unprotected against:
No HSTS? Users can be tricked into visiting an unencrypted version of your site via a man-in-the-middle downgrade attack.
No CSP? If an attacker manages to inject a script (via a compromised third-party library, for example), the browser has no way of knowing it shouldn't execute it.
No X-Frame-Options? Your site can be embedded in an invisible iframe on a malicious page, tricking users into clicking buttons or entering credentials — a technique called clickjacking.
No X-Content-Type-Options? Browsers may guess the content type of a file and execute it as something dangerous, a practice known as MIME sniffing.
These aren't theoretical threats. Clickjacking attacks have targeted major banks and social media platforms. Cross-site scripting (XSS) — which CSP is designed to prevent — has been in the OWASP Top 10 every year since its inception.
How to Fix It
Add the relevant headers to your web server configuration. For a typical Nginx site, adding add_header directives for each header takes about ten lines of configuration. For a modern application behind a reverse proxy, most frameworks have middleware or plugins that handle header injection. We cover implementation in detail in our security headers guide.
Mistake 2: Expired or Misconfigured SSL Certificates
What Goes Wrong
SSL/TLS certificates have an expiration date — typically 90 days to one year from issuance. When a certificate expires, browsers block access to the site and display a full-page security warning. Users see this and leave. Trust evaporates.
Beyond expiration, we also see certificates that are technically valid but misconfigured: mismatched domain names, missing intermediate certificates in the chain of trust, or certificates issued by untrusted certificate authorities. Let's Encrypt has made certificates free and automated, but automation can fail silently. A renewal script that stopped working six weeks ago won't announce itself until the certificate expires.
Why It Matters
An expired certificate is the digital equivalent of a "Closed" sign on your front door. E-commerce sites lose transactions. SaaS applications lose user confidence. Marketing sites lose SEO rankings — Google has confirmed that HTTPS is a ranking signal, and a site that repeatedly serves expired certificates will see its visibility drop.
A 2023 study found that 18% of the Alexa Top 1 Million websites had experienced a certificate-related outage in the preceding 12 months. This is not a rare edge case.
How to Fix It
Use automated certificate renewal. Let's Encrypt's Certbot can run as a cron job. Most cloud platforms (Cloudflare, AWS Certificate Manager, Azure) offer managed certificates that auto-renew. If you're managing certificates manually, set calendar reminders at least 30 days before expiration. Better yet, add your domain to a monitoring service that alerts you weeks before a certificate expires — not hours after.
Mistake 3: Exposed Open Ports
What Goes Wrong
Your web server needs ports 80 (HTTP) and 443 (HTTPS) open to the internet. It does not need port 3306 (MySQL), port 5432 (PostgreSQL), port 6379 (Redis), port 27017 (MongoDB), or port 22 (SSH) open to the entire world. Yet we find these database and administration ports exposed on a significant percentage of scans.
This typically happens for one of two reasons. Either a cloud firewall rule was set to 0.0.0.0/0 (allow all) during initial setup and never tightened, or a developer temporarily exposed a service for remote debugging and forgot to close it. In both cases, the result is the same: a production database or administration interface is accessible to anyone who discovers it.
Why It Matters
When a database port is exposed to the internet, attackers don't need to breach your application. They can attempt to connect directly to the database. If the database has a weak or default password — and many do — they have full access to your data. This is not hypothetical. In 2023, thousands of Redis and MongoDB instances were compromised because they were exposed to the internet without authentication, leading to ransomware attacks and data theft.
Even ports that might seem harmless — like FTP (21) or Telnet (23) — represent a risk. Telnet transmits credentials in plain text. FTP has been obsolete for over a decade. If these are open, something is misconfigured.
How to Fix It
Audit your cloud firewall rules. Remove any 0.0.0.0/0 rules that aren't strictly necessary for ports 80 and 443. Use security groups to restrict access by IP range — your database should only be reachable from your application servers, not from the public internet. If you need remote access, use a VPN or a bastion host.
ScanSentinel checks 16 common ports across every scan, so you'll know immediately if something you thought was internal is actually public.
Mistake 4: Weak TLS Configurations
What Goes Wrong
Even when an SSL certificate is valid, the underlying TLS configuration may be dangerously weak. This includes supporting outdated protocol versions (TLS 1.0 and TLS 1.1) and permitting weak cipher suites (RC4, DES, 3DES, EXPORT-grade ciphers, NULL ciphers).
TLS 1.0 dates from 1999 and has been formally deprecated by the IETF. TLS 1.1, from 2006, has also been deprecated. Both are vulnerable to known attacks, including POODLE and BEAST. PCI DSS compliance requires that TLS 1.0 not be used for payment card data, and most regulatory frameworks have followed suit.
Weak ciphers are encryption algorithms that can be broken with modern computing power. RC4, for example, was found to have biases in its output that allow plaintext recovery in practical attack scenarios. Enabling these ciphers means you're offering attackers an encryption scheme they can feasibly crack.
Why It Matters
Supporting old TLS versions isn't backward compatibility — it's a downgrade attack waiting to happen. An attacker who can position themselves between a user and your server can force the connection to negotiate TLS 1.0 and then exploit its known weaknesses. This is called a protocol downgrade attack, and the only defence is to stop offering the old protocol in the first place.
Similarly, weak ciphers undermine the entire purpose of TLS. If the encryption can be broken, the connection might as well be unencrypted.
How to Fix It
Configure your server to support only TLS 1.2 and TLS 1.3. Disable all cipher suites containing RC4, DES, 3DES, MD5, EXPORT, NULL, or LOW in their names. For Nginx, this means setting ssl<em>protocols TLSv1.2 TLSv1.3; and specifying an explicit ssl</em>ciphers list. For Apache, similar directives apply. Most modern web server packages ship with sensible TLS defaults, but custom or legacy configurations often need updating.
We cover TLS configuration in depth in our SSL/TLS guide.
Mistake 5: Missing SPF, DKIM, and DMARC Records
What Goes Wrong
Email authentication records — SPF, DKIM, and DMARC — are DNS TXT records that tell receiving mail servers how to verify that an email claiming to be from your domain genuinely originated from your authorised infrastructure. When these records are missing or misconfigured, anyone can send an email that appears to come from your domain.
SPF (Sender Policy Framework) lists the IP addresses and servers authorised to send email on your behalf. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing email. DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when authentication fails — quarantine the message, reject it, or let it through.
In our scans, roughly 40% of domains with mail servers have no DMARC record, and about a quarter have no SPF record at all. Among domains that do have SPF, a concerning number use a soft fail policy (~all) rather than a hard fail (-all), meaning spoofed emails may still be delivered.
Why It Matters
Domain spoofing is one of the most effective phishing techniques. An attacker sends an email from [email protected] or [email protected], and the recipient — seeing a legitimate sender address — opens the attachment or clicks the link. Without SPF, DKIM, and DMARC, the receiving mail server has no reliable way to distinguish this forged email from a legitimate one.
Beyond security, missing email authentication directly impacts deliverability. Gmail and Yahoo both announced in 2024 that they would require DMARC for bulk senders. Microsoft and others are following suit. If you send transactional emails, marketing campaigns, or newsletters, your delivery rates will suffer without proper authentication.
How to Fix It
SPF: Add a TXT record at your domain root like v=spf1 include:_spf.google.com -all (adjust for your email provider). Use -all (hard fail) rather than ~all (soft fail) once you're confident your configuration is correct.
DKIM: Most email providers (Google Workspace, Microsoft 365, SendGrid, etc.) generate a DKIM key pair. You add the public key as a TXT record at [selector]._domainkey.yourdomain.com.
DMARC: Add a TXT record at _dmarc.yourdomain.com like v=DMARC1; p=quarantine; rua=mailto:[email protected]. Start with p=none (monitoring only) and tighten to p=quarantine or p=reject as you verify legitimate email is passing authentication.
We cover email authentication setup step-by-step in our email security guide.
Mistake 6: Not Monitoring Continuously
What Goes Wrong
The single most common mistake isn't a specific misconfiguration — it's the absence of ongoing monitoring altogether. Businesses configure their server once, pass an audit, or launch their site, and then never check these settings again.
But security posture isn't static. Certificates expire. Headers get accidentally removed during deployment. Someone opens a port for a maintenance window and forgets to close it. A DNS change breaks SPF. A CMS update disables CSP. These changes happen constantly, and if you're only checking manually — or not checking at all — you'll find out about them after something bad happens.
Why It Matters
The average time to detect a security misconfiguration without automated monitoring is measured in months. The average time for an attacker to discover the same misconfiguration is measured in hours. This asymmetry is why continuous monitoring matters.
A scan run once tells you your posture at a single point in time. Scans run daily or weekly tell you the trend. Trend data lets you distinguish between a one-off configuration drift (fix it and move on) and a systemic problem (your deployment process is stripping headers from every release).
How to Fix It
Adopt automated, scheduled scanning. Add your domains to a monitoring platform, set a scan frequency appropriate for your risk profile (daily for customer-facing applications, weekly for marketing sites), and configure alerts for when findings change. The goal is to know about problems before your users, your customers, or an attacker does.
Actionable Recommendations
Audit your headers right now. Open your browser's developer tools, visit your site, and look at the response headers. Count how many security headers you see. If the answer is fewer than five, you have work to do.
Check your certificate expiry date. Your browser can show you — click the padlock in the address bar. If it expires in fewer than 30 days, set up automated renewal today.
Run a port scan against your own domain. Or better yet, let ScanSentinel do it for you. Find out if anything is exposed that shouldn't be.
Verify your email authentication. Use a free online tool or ScanSentinel's DNS scanner to check whether SPF, DKIM, and DMARC records are present and correctly configured.
Set up monitoring. Whatever tool you use, make sure it runs on a schedule and alerts you to changes. One-off security checks create a false sense of security.
How ScanSentinel Catches These Mistakes
ScanSentinel's scanning engine checks for all six of these issues in every scan:
Missing security headers: Presence and configuration of HSTS, CSP, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, and Permissions-Policy. Warns on dangerous CSP directives like `unsafe-inline` and `unsafe-eval`.
Expired SSL certificates: Certificate validity, issuer and subject, remaining validity period, and chain of trust. Alerts when certificates have fewer than 30 days remaining.
Exposed ports: Scans 16 common ports including databases (MySQL, PostgreSQL, Redis, MongoDB), remote administration (RDP, SSH), and legacy services (FTP, Telnet). Flags unexpected open ports.
Weak TLS configurations: Checks support for all four TLS versions from 1.0 to 1.3. Attempts connections using weak cipher classes. Flags any weak cipher the server accepts.
Missing email authentication: Resolves SPF (domain root), DKIM (10 common selectors), and DMARC (`_dmarc` subdomain) records. Checks SPF policy strictness and DMARC policy level.
No continuous monitoring: Scheduled scanning with configurable frequency. Email and webhook alerts. Score trend tracking over time.
Every finding comes with a severity rating (Low, Medium, High, Critical) and actionable remediation guidance written in plain English. You don't need to be a security engineer to understand what needs fixing and how to fix it.