DEV Community: Bug Circuit

WooCommerce Security Checklist for Stores

Bug Circuit — Thu, 20 Aug 2026 11:12:21 +0000

Originally published on the Bug Circuit blog.

The fastest way to leak customer data on WooCommerce isn't a genius hacker — it's a forgotten plugin update or a stale WordPress core, and you can close both gaps today.

This is for store owners running WooCommerce on WordPress who are worried about a breach hitting customer names, addresses, or order history — not developers looking for a code audit. You'll get a concrete checklist you can work through in one sitting, in the order that actually reduces risk fastest.

The real risk isn't your server holding credit cards

Most WooCommerce owners picture a breach as someone stealing credit card numbers off their server. In a properly configured store, that's not actually where the risk lives — if you use Stripe, PayPal, or another hosted payment gateway, card numbers never touch your database at all; they go straight from the customer's browser to the payment processor.

The real exposure is everything else: names, emails, shipping addresses, order history, and admin credentials, sitting in a WordPress database that's reachable through whichever of your 15 plugins hasn't been updated since last year. WordPress core, WooCommerce, and every plugin you install are all separate pieces of software with separate vulnerabilities — and CISA's Known Exploited Vulnerabilities catalog is full of exactly this pattern: attackers scanning the web for sites still running a patched-months-ago plugin version. CISA KEV Catalog

The checklist: do these in order

Work down this list top to bottom — it's ordered by how much risk each item removes per minute spent.

#	Task	Why it matters	How often
1	Update WordPress core, WooCommerce, theme, and every plugin	Unpatched software is the #1 entry point attackers scan for	Weekly, or auto-update minor versions
2	Delete plugins/themes you're not actively using	Inactive code still runs and still has vulnerabilities	Today, then quarterly
3	Turn on two-factor authentication (2FA) for every admin/shop manager account	Stops stolen passwords from being enough to log in	Today
4	Confirm your payment gateway is hosted checkout / tokenized (Stripe, PayPal, Square)	Your server never stores or sees full card numbers	Verify today
5	Set `DISALLOW_FILE_EDIT` to true in wp-config.php	Blocks attackers who get admin access from editing theme/plugin code	Today
6	Add strong security headers (HSTS, CSP, X-Frame-Options)	Reduces damage from XSS and clickjacking	Today
7	Confirm off-site, automated backups are running	Lets you recover instead of paying a ransom or rebuilding	Verify today, then weekly checks
8	Rename or remove the default "admin" username; enforce unique logins per staff member	Stops credential-stuffing and makes breach forensics possible	Today
9	Install a WordPress firewall/malware scanner (Wordfence, Sucuri, or your host's WAF)	Blocks known attack patterns before they hit your code	Today, monitor weekly
10	Review user roles — no one has Administrator who only needs Shop Manager	Limits what a compromised account can do	Monthly

Update discipline: the single biggest lever

Open WordPress admin → Dashboard → Updates right now and clear everything queued. Then set a recurring habit:

Enable automatic updates for minor WordPress core releases (Settings → this is on by default since WP 3.7 for security releases).
Update WooCommerce itself as soon as a new version drops — check the changelog for "security" or "vulnerability" language first.
Go through every installed plugin individually. If a plugin hasn't been updated by its developer in over a year, treat that as a red flag even if no known vulnerability is public yet.
Delete anything deactivated. A disabled plugin sitting in /wp-content/plugins/ is still a live target if its files are reachable.

This single habit closes more real-world breach paths than almost anything else on this list — most WordPress compromises trace back to a known, already-patched vulnerability in outdated software, which is exactly the pattern OWASP flags under "Vulnerable and Outdated Components" in its Top 10 risks. OWASP Top 10

Lock down who can log in

Your wp-admin login is the front door. Harden it:

Enforce 2FA for every account with admin or shop manager access — WP 2FA and Wordfence both offer free options.
Kill the shared "admin" account. Give every staff member and contractor their own login tied to their name, and remove access the day they leave.
Limit login attempts. Most security plugins add this by default — it stops brute-force password guessing.
Set roles correctly. A customer service rep processing refunds needs Shop Manager, not Administrator. Fewer people with full access means less damage if one account is compromised.
Disable XML-RPC if you don't use the WordPress mobile app or Jetpack — it's a common brute-force and DDoS amplification target.

WordPress.org's own hardening guide covers the server-level version of these steps if you manage your own hosting. WordPress.org: Hardening WordPress

Keep card data off your server entirely

This is the one that keeps owners up at night, and it's also the one with the cleanest fix: never let WooCommerce or your server touch a raw card number.

Use a gateway that tokenizes on the customer's browser — Stripe, Square, and PayPal's hosted fields all do this. WooCommerce's own checkout blocks integrate directly with these.
If you're on an older, custom-built checkout that stores card fields locally, migrate off it. That configuration puts you in a much heavier PCI DSS assessment category.
Confirm your gateway plugin settings show "hosted fields" or "tokenized" rather than a raw credit card number field rendered on your own domain.

Done this way, you typically qualify for the simplest PCI compliance self-assessment (SAQ A), because card data never enters your environment. The Payment Card Industry Security Standards Council publishes the official criteria for which SAQ applies to your setup. PCI Security Standards Council

Add security headers your browser already understands

Headers are instructions your server sends telling browsers how to treat your site defensively. Add these via your host, a plugin like Wordfence, or your .htaccess/nginx config:

Strict-Transport-Security: max-age=31536000; includeSubDomains — forces HTTPS, blocking downgrade attacks.
X-Frame-Options: SAMEORIGIN — stops your checkout page from being embedded in a malicious iframe (clickjacking).
X-Content-Type-Options: nosniff — stops browsers from misinterpreting uploaded files as executable scripts.
Content-Security-Policy — restricts which domains can load scripts on your site, a strong defense against injected skimmer scripts (a real WooCommerce attack pattern known as Magecart-style card skimming).

You can check what's currently set on your live store, free, with our security headers scanner — most WooCommerce sites are missing at least two of these out of the box.

Back it up before anything else breaks

A backup won't stop a breach, but it's the difference between a bad afternoon and losing your store. Confirm you have:

Automated, scheduled backups (daily for active stores) stored off the same server — UpdraftPlus, host-native backups, or your hosting provider's snapshot system.
At least one backup you've actually tested restoring, not just one you assume works.
Database backups included, not just files — WooCommerce order and customer data lives in the database.

Key takeaways

Outdated WordPress core, WooCommerce, or plugins are the most common way small stores get breached — update weekly and delete what you don't use.
Use a tokenized checkout (Stripe, PayPal, Square) so raw card numbers never touch your server — this also keeps your PCI compliance burden minimal.
Turn on 2FA, kill shared admin logins, and match user roles to what each person actually needs.
Add HSTS, CSP, and X-Frame-Options headers, and confirm off-site backups are actually running and restorable.
A checklist catches configuration gaps; it won't catch a logic flaw or an exposed endpoint specific to your setup — that takes a person actually testing your live site.

Working through this list yourself fixes the common, well-known gaps. What it can't do is find the issue unique to your store — a misconfigured REST API endpoint, a coupon logic flaw, an exposed staging URL. That's the gap a real manual security audit closes: a person actually testing your checkout and admin, not a scanner running the same generic ruleset every other site gets. If you want a free first read before spending anything, our free website security check will tell you, no card required, whether anything critical is already exposed.

How to Stop Brute-Force Attacks on WordPress Login

Bug Circuit — Sun, 16 Aug 2026 23:12:43 +0000

Originally published on the Bug Circuit blog.

You stop WordPress brute-force login attacks by rate-limiting failed login attempts, requiring two-factor authentication, and closing off the two doors attackers actually use — wp-login.php and xmlrpc.php — while skipping the tweaks that feel like security but don't add real protection.

This is for anyone running WordPress — a small business owner, an agency managing client sites, or a solo blogger — who's noticed a wall of failed login attempts in their logs, or just wants to get ahead of it. You'll get a step-by-step hardening stack with exact plugin names and config snippets, plus an honest breakdown of what's real defense versus what's just theater.

What a brute-force attack on WordPress actually looks like

Most WordPress attacks aren't a person typing passwords by hand. They're bots working through a list — either guessing many passwords against one username (classic brute force), or trying username/password pairs leaked from other breaches against your site (credential stuffing, per OWASP's Credential Stuffing Prevention Cheat Sheet). Both hit /wp-login.php (and /wp-admin/, which just redirects there) at high volume, hoping your admin account uses a weak or reused password.

There's a second, less obvious front: xmlrpc.php. This is WordPress's legacy remote-publishing API, and its system.multicall method lets an attacker bundle hundreds of username/password guesses into a single HTTP request. That means basic rate limiting — which usually counts requests, not the login attempts hidden inside them — can miss it entirely. This is one of the most useful facts in this guide, because most login-hardening advice ignores it.

The hardening stack: what matters vs. what's theater

Defense	Actually stops brute force?	Effort
Rate-limit / lock out after failed attempts	Yes	Low (plugin)
Two-factor authentication (2FA)	Yes	Low–medium
Disable or restrict XML-RPC	Yes	Low
Strong, unique passwords + no shared logins	Yes	Low
WAF / edge rate limiting (e.g. Cloudflare)	Yes, blocks before WordPress even loads	Medium
Hide/rename `wp-login.php`	Partial — cuts noise, not a real barrier	Low
Rename the "admin" username	Partial — stops the laziest bots only	Low
Login CAPTCHA	Partial — slows automation, not a full stop	Low

If you only have time for two things, do the first two rows.

Step 1: Limit login attempts and lock accounts out

Install Limit Login Attempts Reloaded (free, wordpress.org) and configure:

Lockout after 4 failed attempts.
Lockout duration: 20 minutes, doubling on repeat offenses.
"Cookie-based brute-force protection" and IP logging turned on so you can see who's knocking.

If you're behind Cloudflare (even the free tier), add a rate-limiting rule: block or CAPTCHA-challenge any IP sending more than 5 POST requests to /wp-login.php within 1 minute. Edge-level rate limiting stops traffic before it ever reaches your server, which matters if you're on shared hosting where WordPress itself can get overwhelmed just processing the attempts.

Step 2: Turn on two-factor authentication (2FA)

This is the single highest-leverage step. Even if a bot guesses your password, it still can't log in without the second factor. Use the official Two Factor plugin (wordpress.org, maintained by WordPress core contributors) or the 2FA module in Wordfence or Solid Security (formerly iThemes Security). Enforce it on every account with Administrator or Editor access — not just yours. CISA lists multi-factor authentication as one of the highest-impact steps anyone can take to prevent account takeover; see their guidance on turning on MFA.

Step 3: Disable or restrict XML-RPC

Most sites don't need XML-RPC anymore — WordPress 5.6+ added Application Passwords (under Users → Profile → Application Passwords) and a REST API that cover what the old Jetpack/mobile-app integrations used it for. If you don't use the WordPress mobile app or Jetpack's older connection method, block it outright.

Apache (.htaccess):

<Files xmlrpc.php>
Require all denied
</Files>

Nginx:

location = /xmlrpc.php {
    deny all;
}

If you do need XML-RPC (some Jetpack features still use it), don't disable the whole file — just remove the dangerous multicall method with a small must-use plugin:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
});

Step 4: IP-level lockout with fail2ban (self-managed servers/VPS)

If you manage your own server, install the WP fail2ban plugin, which logs failed WordPress login attempts to syslog in a format fail2ban can parse, then add a jail:

[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/auth.log
maxretry = 5
findtime = 600
bantime  = 3600

This bans the IP address at the firewall level after repeated failures — the attacker can't even reach wp-login.php again, not just get denied by it. On managed hosting (WP Engine, Kinsey, most shared hosts) you won't have shell access for this; lean on your host's built-in brute-force protection instead, which most reputable WordPress hosts now include.

Step 5: Hiding wp-login.php — useful, but don't count on it

Plugins like WPS Hide Login let you change your login URL from /wp-login.php to something custom, like /portal-access. This is "security through obscurity" — it doesn't fix a vulnerability, it just makes your site a less visible target to the dumbest, most generic bots scanning the entire internet for /wp-login.php. It genuinely does cut down log noise and server load. It should never be your only defense, because a single leaked link, a misconfigured cache, or a targeted attacker (rather than a mass scanner) bypasses it instantly.

What's mostly theater

Renaming the "admin" username alone — helps against the laziest scripts, does nothing against credential stuffing using real emails.
A CAPTCHA with no rate limiting behind it — slows bots down, doesn't stop a patient attacker.
"We're secure" trust badges — cosmetic, provide zero technical protection.

None of these are harmful to have, but don't let them substitute for 2FA and rate limiting.

Quick setup checklist

[ ] Login lockout after 4–5 failed attempts (plugin or edge rule)
[ ] 2FA enforced on every admin/editor account
[ ] XML-RPC blocked, or system.multicall removed if you need it
[ ] Unique, strong passwords — no shared logins across staff
[ ] fail2ban or host-level IP lockout if you're on a VPS
login URL hidden to cut down bot noise

If you're not sure any of this is actually configured correctly on your site, WordPress.org's own hardening guide is a solid technical reference to check settings against — or run our free passive security check to see what's exposed without touching your site.

If you're already seeing signs something's wrong — unfamiliar admin users, spam pages appearing, a host warning you — that's a different problem than prevention; our guide on what to do if your website's been hacked walks through the recovery steps. And if you're just trying to figure out your overall exposure before it gets to that point, our guide on how to tell if your website is hackable is a good next read.

Key takeaways

Rate limiting plus two-factor authentication stops the overwhelming majority of WordPress brute-force attempts — everything else is secondary.
XML-RPC's system.multicall lets attackers test hundreds of passwords in one request, so basic rate limiting alone can miss it — block or restrict it directly.
Hiding wp-login.php reduces bot noise but is not a real security control on its own.
Renaming the "admin" username and adding a CAPTCHA are minor helpers, not defenses — don't rely on them alone.
If you manage your own server, fail2ban with the WP fail2ban plugin adds real IP-level lockout; on managed hosting, confirm your host already does this.

Hardening login is one piece of the picture — it won't catch a vulnerable plugin, an outdated theme, or a misconfigured form elsewhere on the site. A Circuit audit is $49 and gets a real person manually checking your whole site, not just the login page, with a written report of exactly what's wrong and how to fix it. No pressure — it's just the honest next step once the login is locked down.

What a Website Security Audit Report Looks Like

Bug Circuit — Sat, 15 Aug 2026 17:12:10 +0000

Originally published on the Bug Circuit blog.

A website security audit report is a document that lists every vulnerability a human tester found on your site, ranked by how dangerous it is, with proof it's real and exact steps to fix it — not a scanner printout of vague warnings.

This is for anyone about to pay for a security audit (ours or anyone else's) who wants to know what they're actually buying before they hand over a card number. Below is a real, annotated sample report structure with example findings, so you can see exactly what a manual audit produces — and what to be suspicious of if a report doesn't look like this.

The three parts every real report has

A legitimate manual audit report has three sections, in this order:

Executive summary — one page, plain English, no jargon. What was tested, how many issues were found at each severity, and the overall risk picture in 3-4 sentences a non-technical owner can read in 30 seconds.
Findings list — every individual vulnerability, one at a time, each with the same fields (below). This is the bulk of the report.
Fix guidance — for each finding, the exact change to make: a setting to flip, a line to add to a config file, a plugin to update, code to patch.

If a report you're evaluating skips straight from a summary to a generic "harden your site" checklist with no specific findings tied to your actual site, it wasn't a real audit of your site — it was a template.

Anatomy of one finding, annotated

Here's what a single, real finding looks like inside the report, field by field.

Field	What it means	Example from a real finding
Title	Short name for the issue	Missing HTTP security headers on all pages
Severity	How bad it is if left unfixed (table below)	Medium
Location	The exact URL, page, or endpoint affected	`https://example.com/*` (site-wide)
Description	What the problem is, in plain English	Your site doesn't send a `Content-Security-Policy` or `X-Frame-Options` header, so a browser has no instructions to block malicious scripts or clickjacking attempts if an attacker manages to inject content.
Evidence	Proof it's real — a screenshot, a response header dump, a request/response pair	`curl -I https://example.com` response showing no `Strict-Transport-Security`, `X-Content-Type-Options`, or `Content-Security-Policy` headers present
Impact	What an attacker could actually do with it	An attacker who finds a second, smaller bug (like a comment field that isn't sanitized) could chain it with this gap to run scripts in your visitors' browsers or embed your login page in an invisible iframe to steal credentials
Fix	The exact change to make	Add these headers via your server config or CDN: `Content-Security-Policy: default-src 'self'`, `X-Content-Type-Options: nosniff`, `Strict-Transport-Security: max-age=31536000; includeSubDomains`, `X-Frame-Options: DENY`
Reference	Where to read more	OWASP Secure Headers Project

Every finding in a real report has all eight of those fields. If a "finding" is just a sentence with no evidence and no exact fix, that's filler, not an audit result — it's padding a page count, not proving a risk. You can check your own headers right now with our security headers scanner to see where you'd land before paying for anything.

How severity is actually decided

Severity isn't a vibe — it's based on how easy the bug is to exploit and how much damage it causes. Most manual auditors (us included) follow the same logic as the industry-standard OWASP Risk Rating Methodology, which weighs exploitability against impact.

Severity	What it means	Typical example	Fix urgency
Critical	Actively exploitable, no login required, major damage (data theft, full takeover)	SQL injection on a login form; exposed `.env` file with database credentials	Fix within 24-48 hours
High	Exploitable with some effort or partial access; serious damage	Admin panel reachable with a default or weak password; outdated plugin with a public, known exploit	Fix within a week
Medium	Requires specific conditions or user interaction; moderate damage	Reflected cross-site scripting (XSS) in a search field; missing security headers	Fix within a month
Low	Hard to exploit or limited impact on its own	Verbose server error messages revealing software versions	Fix when convenient
Informational	Not a vulnerability, but worth knowing	TLS certificate expiring in 60 days	No action required now, just a heads-up

For the specific mechanics of an issue like reflected XSS, OWASP's cross-site scripting page is the primary reference auditors cite — a good report should link to sources like this instead of just asserting "this is dangerous, trust us."

A short sample findings list, as it would appear in a report

Here's what the findings section of a real small-business site report might contain — condensed:

[Critical] Publicly accessible .env file exposing database credentials — https://example.com/.env returns the raw file instead of a 404. Contains database username, password, and API keys in plain text. Fix: block dotfiles in your web server config (e.g., Apache: <FilesMatch "^\.">Require all denied</FilesMatch>) and rotate every credential in the file immediately.
[High] Outdated WordPress plugin with a known, public vulnerability — Contact Form 7 running an old version with a documented flaw listed in the NVD database. Fix: update to the current version via WordPress admin → Plugins, or remove the plugin if unused. Check CISA's Known Exploited Vulnerabilities catalog for anything actively being used in real attacks.
[Medium] Login page has no rate limiting — An attacker can attempt unlimited password guesses against /wp-login.php with no lockout. Fix: install a login-attempt limiter (e.g., Limit Login Attempts Reloaded) or add rate limiting at the server/CDN level.
[Low] Server reveals its exact software version in error pages — Gives an attacker a head start on picking which known exploits to try. Fix: disable detailed error output in production (display_errors = Off in PHP, or the equivalent in your framework).

Notice each one names a real, specific location on the actual site — never "your site may be vulnerable to XSS somewhere." That specificity is the entire value of paying a human instead of running a free scanner yourself.

Manual report vs. automated scanner printout

The biggest giveaway of a low-effort "audit" is that it's just an automated scan with a cover page. Automated tools are useful and we use them too, but on their own they flag lots of things that aren't actually exploitable, and they miss logic flaws entirely — like a checkout page that lets you edit the price in a hidden form field, or an account page that shows another customer's order if you change a number in the URL. Those require a person actually clicking around and thinking like an attacker. We cover the difference in more depth in our guide to manual vs. automated penetration testing if you want the full breakdown.

Checklist: is the report you're about to pay for real?

Before you pay for any audit, check the sample report (a legitimate vendor will show you one) against this:

[ ] Every finding names an exact URL or location on your actual site — not a generic statement
[ ] Every finding includes evidence (screenshot, header output, or request/response)
[ ] Every finding has a severity rating with a stated reason, not just a color
[ ] Every finding includes a specific fix, not "contact a developer"
[ ] The report cites external references (OWASP, CISA, NVD) for technical claims
[ ] There's an executive summary a non-technical owner can actually understand
[ ] The vendor tells you plainly what was and wasn't tested (scope)

If you're not sure whether your site even needs this yet, our free website security check gives you a fast passive read and a plain yes/no on anything critical, no card required — and if you want to understand the risk picture in general first, our guide on how to tell if your website is hackable walks through the warning signs.

Key takeaways

A real audit report has three parts: executive summary, individual findings, and specific fixes — not just a scanner printout.
Every finding should include eight things: title, severity, exact location, description, evidence, impact, fix, and a reference.
Severity should follow a defined methodology (like OWASP's Risk Rating Methodology), not a gut feeling.
Manual testing catches logic flaws (like editable prices or exposed other-customer data) that automated scanners miss entirely.
Ask to see a sample report before paying for any audit — a real vendor will show you one without hesitation.

If you want to see this done on your own site instead of a sample, Circuit is a $49 one-time manual audit: a real person tests your site and hands you a report built exactly like the one above, with every finding tied to your actual pages and evidence attached — no subscription, no upsell pressure, just the report.

Sucuri vs Wordfence: Which One Do You Need?

Bug Circuit — Fri, 14 Aug 2026 11:12:47 +0000

Originally published on the Bug Circuit blog.

Sucuri catches malware after it's already on your site; Wordfence blocks a lot of attacks before they land — most small WordPress sites should start with Wordfence's free plugin and only add Sucuri's paid firewall if they need CDN-level protection or coverage beyond WordPress.

This guide is for owners of small WordPress sites — agencies, local businesses, indie SaaS running on WordPress — trying to decide between Sucuri and Wordfence, or wondering if they need both. You'll get a plain-English breakdown of what each tool actually does, a side-by-side comparison, and a short checklist for picking one. At the end, we cover the part neither tool touches: your actual configuration, user accounts, and custom code — the stuff a scanner can't judge for you.

What Wordfence actually does

Wordfence is a WordPress plugin built by Defiant Inc. It has three main jobs:

Endpoint firewall — code that loads with WordPress itself, before your theme or plugins run, and blocks malicious requests (SQL injection attempts, known exploit patterns, brute-force logins) at the PHP level.
Malware scanner — compares your core files, themes, and plugins against known-good copies and flags anything that's been changed or injected.
Login security — two-factor authentication (2FA, a second login step beyond your password), CAPTCHA on the login form, and lockouts after repeated failed attempts.

Because the firewall runs inside your WordPress install, it only protects that one site — and only WordPress. The free version updates its attack-signature rules on a 30-day delay; Wordfence Premium gets those updates in real time. See Wordfence's own documentation for what each tier includes: wordfence.com/help/firewall.

What Sucuri actually does

Sucuri (owned by GoDaddy) ships two different things under one name, and mixing them up is where most confusion starts:

Sucuri Security plugin (free) — a WordPress plugin that does malware and integrity scanning, activity logging, and hardening tips. It does not include a firewall.
Sucuri Website Firewall (paid) — a cloud/DNS-level proxy. You point your domain's DNS at Sucuri, and every visitor's traffic passes through their servers before it ever reaches yours. It filters attacks, includes a CDN (content delivery network, which also speeds up your site), and absorbs DDoS traffic floods.

Because the paid firewall sits in front of your DNS rather than inside WordPress, it can protect any platform — Shopify, plain HTML, Magento, WordPress, anything with a domain. Sucuri's paid plans also include malware removal if your site does get infected. Details: sucuri.net/website-firewall.

Sucuri vs Wordfence: side-by-side

	Wordfence	Sucuri
Firewall location	On your server (application-level)	In front of your server (DNS/network-level)
Works on non-WordPress sites	No	Yes (paid firewall)
Free tier includes a firewall	Yes, with delayed rule updates	No — scanner only
Includes a CDN	No	Yes (paid plan)
DDoS mitigation	Limited, server-side only	Yes — traffic never reaches your server
Malware removal service	Not built in; manual cleanup	Included on paid plans
2FA / login hardening	Built in, well regarded	Basic hardening tips only
Performance cost	Adds PHP processing per request	Offloads processing to their network
Best fit	Single WordPress site, tight budget	Multi-platform, high-traffic, or already-hacked sites

The application-level vs. network-level distinction matters more than most comparisons admit — it's an architecture difference, not just a feature list, and it changes what each tool can physically stop. OWASP's explainer on web application firewalls covers why placement matters: owasp.org/www-community/Web_Application_Firewall.

Which one do you actually need?

Answer these honestly:

Is your site WordPress-only, on a normal budget? Start with Wordfence's free plugin and turn on 2FA for every admin account right away — that alone stops most automated account-takeover attempts.
Has your site already been hacked, or do you need cleanup fast? Sucuri's paid plan bundles cleanup with the firewall, so you're not paying separately for incident response. See our guide on what to do if your website's been hacked.
Do you run more than one platform, or need a CDN anyway? Sucuri's network-level firewall does double duty as performance infrastructure.
Is your hosting slow or resource-limited? Sucuri offloads filtering off your server entirely; Wordfence's endpoint firewall adds a small amount of PHP processing to every request.
Do you want strong login protection for a small team? Wordfence's 2FA and login security are widely used and well documented.

You can run Wordfence's scanner and Sucuri's firewall at the same time without conflict, since one operates at the DNS layer and the other inside WordPress. Just avoid paying for two overlapping firewalls unless you have a specific reason, like wanting Sucuri's CDN but preferring Wordfence's login tools.

The gap neither tool covers

Here's the part most comparisons skip: both tools watch for known attack patterns and file changes. Neither one reads your actual setup and tells you it's wrong. A scanner can't see that:

An old contractor's admin account is still active, with a password from years ago and no 2FA.
Your contact form saves uploaded files to a publicly readable folder.
A custom plugin your developer wrote builds SQL queries with string concatenation instead of prepared statements.
A database backup is sitting somewhere public that no scanner ever looks at.
A staging copy of your site, running an old WordPress version, is still indexed and reachable.

These are security misconfigurations and logic flaws — one of the most common categories OWASP tracks in its Top 10 list of web application risks: owasp.org/Top10/A05_2021-Security_Misconfiguration. No signature-based scanner catches a misconfigured permission or an over-privileged account, because there's no known-bad pattern to match — it's simply wrong for your site.

This is also why staying current on updates matters regardless of which plugin you run. CISA's guidance on patching is a useful baseline reminder that a firewall doesn't replace timely updates: cisa.gov: Understanding Patches and Software Updates.

A quick self-check before you decide

[ ] Run a passive check on your headers and DNS setup — our free security headers tool shows what's missing in under a minute.
[ ] List every admin and editor account on your site — do they all still need access?
[ ] Confirm 2FA is on for every account with publish or admin rights.
[ ] Make sure your backups live somewhere the public internet can't reach.
[ ] If you're unsure whether your setup is exploitable at all, our guide on how to tell if your website is hackable walks through the warning signs.

Where a human audit fits in

Wordfence and Sucuri are both good at what they're built for: catching known attack signatures and known-bad file changes, continuously, for a low yearly cost. Neither is designed to sit down and think about your specific setup the way a person would — reviewing your actual user list, reading your custom code for logic bugs, or noticing that a form field passes user input straight into a database query.

That's the gap a manual audit fills, and it's a genuinely different kind of check than either plugin runs. For a fuller breakdown of what a scanner catches versus what a person tests, see our manual vs. automated penetration testing guide.

Key takeaways

Wordfence's firewall runs on your server and protects WordPress only; Sucuri's paid firewall runs at the DNS level and protects any platform, with a CDN included.
Wordfence's free tier includes a firewall with delayed rule updates; Sucuri's free tier is scan-only — the firewall is a paid add-on.
You can run both at once without conflict, but paying for two overlapping firewalls rarely makes sense.
Neither tool checks your admin accounts, custom code, or configuration for logic flaws — that takes a person reviewing your actual setup.
Run a free passive check first to see what's exposed before deciding which paid tier, if any, you actually need.

Bug Circuit's $49 manual audit is built for exactly that gap: a real person checks your site's configuration, accounts, and code — not just file signatures — and hands you a plain-English report of what's wrong and how to fix it. If you want a free yes/no on critical issues first, start with our free website security check.

What Is Cross-Site Scripting (XSS)? Plain-English Guide

Bug Circuit — Wed, 12 Aug 2026 17:12:34 +0000

Originally published on the Bug Circuit blog.

Cross-site scripting (XSS) is a security bug that lets an attacker sneak their own code into a page your visitors trust, so it runs inside their browser as if your site wrote it — quietly stealing login sessions, redirecting payments, or planting fake forms. It's one of the oldest and still most common web vulnerabilities, and it doesn't require breaking into your server — just finding one spot on your site that echoes back user input without cleaning it up first.

This is for owners of WordPress sites, Shopify stores, indie SaaS apps, or small business sites who've heard the term "XSS," maybe seen it flagged by a scanner, and want to know in plain English what it actually does and whether their contact or comment form is a target. By the end, you'll know how to test for it yourself and what a real fix looks like.

The short version: how XSS actually works

Every web page is a mix of your content and, sometimes, content your visitors typed in — a comment, a search term, a name field, a support ticket. Your site's job is to display that input back safely, as plain text.

XSS happens when your site instead treats that input as code and runs it. If someone types <script>steal_your_cookies()</script> into a form and your page prints it straight into the HTML without encoding it, the browser doesn't see text — it sees an instruction to execute. The script isn't hosted on some attacker's server pretending to be you; it runs directly inside your page, in the visitor's browser, with full access to whatever your page can see.

OWASP, the nonprofit that maintains the standard reference for web vulnerabilities, defines XSS as an injection attack where malicious scripts are injected into otherwise trusted, benign websites — and it's serious enough to be folded into the OWASP Top 10's Injection category, a list of the most critical risks to web applications.

The three flavors of XSS (and why the difference matters)

Not all XSS behaves the same way, and the type affects who's at risk and how urgently it needs fixing.

Type	Where the malicious script lives	How it usually gets delivered	Real-world risk
Stored (persistent) XSS	Saved in your database — a comment, review, forum post, profile bio	Attacker submits it once through a form	Every visitor who later views that page runs the script automatically — the most dangerous variant
Reflected XSS	Bounced back in the page's response, never saved	A crafted link with the script in the URL, sent via email or ad	Only affects someone who clicks the malicious link
DOM-based XSS	Injected entirely in the browser by client-side JavaScript	Page JavaScript reads something like the URL fragment and writes it into the page without checking it	Can happen even if your server-side code is perfectly clean

Stored XSS is the one to worry about most on a small site, because a single successful comment-form submission can quietly compromise every visitor who reads that page afterward — no clicking required.

What an attacker can actually do once their script runs

Once a script executes in a visitor's browser on your domain, it inherits whatever trust that visitor has placed in your site. Concretely, that means an attacker can:

Hijack a logged-in session. Read the session cookie or auth token and reuse it to log in as that user — including an admin — without ever knowing the password.
Inject a fake payment form. Overlay a convincing "update your card details" box on your real checkout or account page, capturing card numbers that go straight to the attacker instead of your payment processor.
Redirect or phish. Silently forward the visitor to a lookalike login page, or pop a fake "session expired, log in again" prompt that harvests credentials.
Log keystrokes or grab form data before it's even submitted.
Deface or spread. On stored XSS, the payload can rewrite the page for every subsequent visitor, or worm through comment sections automatically.

None of this requires the attacker to find a way into your hosting account or database directly — the browser does the work for them.

Is your contact or comment form actually exposed?

Any place your site takes text from a stranger and later displays it back — to that same visitor or to anyone else, including your own staff — is a candidate. Common spots on small sites:

Comment sections and product reviews
Contact forms that echo the name back on a "Thanks, {name}!" confirmation page
Search boxes that show "No results for {your search}"
Support/ticket forms an admin later opens in a dashboard
User profile fields (bio, display name, website URL)
Any WordPress plugin or theme that hasn't been updated in over a year

If your site is on WordPress, outdated plugins are the single most common source — vulnerable versions get published with fixes in the changelog, so an attacker just needs to know your plugin version. Not sure where you stand? Our free website security check flags exposed input points and out-of-date software without needing a login or card.

How to check it yourself (safely)

You can do a basic, non-destructive test on your own site — never test a site you don't own or have permission to test.

Find a form field that gets displayed back somewhere (comment box, contact form, search).
Submit a harmless test string: <script>alert('test')</script> or, if angle brackets get stripped, try "><img src=x onerror=alert(1)>.
Load the page where that input is displayed back.
If a popup box appears saying "test" or "1" — your input isn't being encoded, and that field is vulnerable.
If the text shows up literally as <script>alert('test')</script> on the page (not as a popup), the field is encoding it correctly.

Delete your test comment afterward. This manual check only catches the obvious cases — automated scanners and a trained eye catch far more, including DOM-based XSS that never touches your server logs at all, which is one reason a manual review typically finds more than automated scanning alone.

How to actually fix it

The fix depends on where the bug lives, but the core principle from OWASP's Cross-Site Scripting Prevention Cheat Sheet is simple: never let untrusted input become code.

Encode output, don't just filter input. Escape special characters (<, >, ", ', &) whenever user data is written into HTML, so <script> renders as text, not code. Every modern templating framework (React, Vue, Twig, Blade) does this automatically by default — don't bypass it with functions like dangerouslySetInnerHTML or v-html unless the content is sanitized first.
Sanitize rich text properly. If you must allow some HTML (e.g., a WYSIWYG comment box), run it through a real sanitizer library like DOMPurify — don't hand-write a regex filter, which almost always misses an edge case.
Set a Content-Security-Policy header. This tells the browser which sources of script it's allowed to run, so even an injected <script> tag gets blocked. A reasonable starting policy: Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'. See MDN's CSP reference for the full syntax. You can check what headers your site currently sends with our security headers scanner.
Lock down cookies so a successful XSS can't be turned into a session hijack. Set Set-Cookie: sessionid=<value>; HttpOnly; Secure; SameSite=Strict — HttpOnly stops JavaScript from reading the cookie at all, which blunts the most common XSS payoff even if a script does slip through.
Keep CMS/plugins current and remove unused ones. On WordPress, update core, theme, and every plugin promptly, and consider a web application firewall plugin (e.g., Wordfence or Sucuri) as a second layer, not a replacement for fixing the actual code.

None of these fixes require a rebuild — most are a template change, one HTTP header, and a cookie flag.

Key takeaways

XSS lets an attacker's script run inside your visitors' browsers on your own domain — it doesn't require hacking your server directly.
Stored XSS (comments, reviews, profile fields) is the highest-risk type because it hits every visitor automatically, not just people who click a bad link.
Watch any field that echoes user input back — contact forms, search boxes, comments — and test with a harmless <script>alert(1)</script> payload on your own site only.
Fix it with output encoding, a Content-Security-Policy header, and HttpOnly/Secure/SameSite cookie flags — not a hand-rolled filter.
Automated scanners miss a lot of real-world XSS, especially DOM-based cases; that's the gap a manual review is built to close.

If you'd rather have a person check for this instead of guessing from a checklist, that's exactly what Circuit is: a $49 one-time manual audit where a real security engineer tests your forms, comments, and inputs by hand and hands you a written report with exact fixes — not just a scanner printout. If you're not sure your site's been affected already, our guide on signs your website might be hackable is a good next read.

What Is a Website Vulnerability? Explained Simply

Bug Circuit — Thu, 06 Aug 2026 11:12:22 +0000

Originally published on the Bug Circuit blog.

A website vulnerability is a weakness in your site's code, settings, or software that could let someone do something they shouldn't — like read your database, take over an admin account, or deface your homepage. It's the flaw, not the attack itself. Whether that flaw ever gets used against you depends on a few other things we'll walk through below.

This guide is for site owners who just got a scan report, a security questionnaire from a client, or a vague warning from their host, and are staring at words like "critical severity" or "reflected XSS" with no idea what to do next. By the end, you'll know the difference between a vulnerability, an exploit, and risk; what each severity label actually means; the vulnerability types you'll run into most often; and how to decide what to fix first.

Vulnerability vs. exploit vs. risk — the three words people mix up

These three words get used interchangeably, but they mean different things, and knowing the difference changes how you react to a report.

Term	What it means	Owner-language example
Vulnerability	The weakness itself — a bug, misconfiguration, or missing protection	Your contact form doesn't check what type of file gets uploaded
Exploit	The actual method or code used to take advantage of that weakness	Someone uploads a disguised script through that form instead of a resume
Risk	The realistic chance and impact of that exploit happening to your site	Low risk if the form is rarely used and files aren't executed; high risk if uploaded files are stored in a public, executable folder

The U.S. government's official definition, from NIST's Computer Security Resource Center glossary, calls a vulnerability a "weakness in an information system... that could be exploited by a threat source" — note the word could. A vulnerability existing doesn't mean you've been attacked; it means the door isn't fully locked yet. (Source: NIST CSRC Glossary, "vulnerability")

That's also why two sites with the identical vulnerability can carry very different risk. A stale WordPress plugin on a personal blog is a nuisance. The same plugin on a site processing customer credit cards is a real problem — same vulnerability, very different risk. This is the piece automated scanners are worst at, and it's the main thing a human reviewer adds: judgment about your actual setup, not just a checklist match. Our guide to manual vs. automated penetration testing goes deeper on why that context matters.

How severity ratings actually work

Most scan reports label each finding Critical, High, Medium, or Low. These labels usually trace back to CVSS (Common Vulnerability Scoring System), an industry-standard 0–10 scoring formula maintained by FIRST.org and used in the U.S. National Vulnerability Database. The score weighs things like: can it be exploited remotely with no login required, does it need user interaction, and what does the attacker gain — read access, full control, or just a crash?

Here's how NVD maps the numeric score to the label you see on your report:

CVSS v3.1 score	Severity label	Rough translation for owners
9.0 – 10.0	Critical	Fix immediately — remote takeover or full data exposure with little effort
7.0 – 8.9	High	Fix this week — serious impact, though it may need specific conditions
4.0 – 6.9	Medium	Fix this month — real but limited impact, or harder to pull off
0.1 – 3.9	Low	Fix when convenient — minor impact or very hard to exploit

(Source: NVD Vulnerability Metrics / CVSS)

Two caveats worth knowing. First, severity measures technical impact, not your business impact — a Medium finding on your customer database can matter more to you than a Critical finding on a page nobody visits. Second, CISA maintains a separate list called the Known Exploited Vulnerabilities (KEV) catalog, tracking flaws that attackers are actively using in the wild right now, regardless of their CVSS score. If a vulnerability on your site shows up there, treat it as urgent no matter what label a scanner gave it. (Source: CISA Known Exploited Vulnerabilities Catalog)

The vulnerability types you'll actually see on a small-site report

Most small-business site findings fall into a handful of buckets tracked by OWASP, the nonprofit that maintains the industry-standard list of web app risks. You don't need to memorize the names — just recognize the shape of the problem when you see it.

Category (OWASP Top 10)	Plain-English description
Broken access control	A logged-in user (or nobody at all) can reach pages, files, or data they shouldn't — e.g., changing a URL's ID number to view someone else's order
Injection (SQLi, XSS)	Untrusted input gets treated as code — a comment box or search bar lets an attacker run database commands or scripts in visitors' browsers
Security misconfiguration	Default passwords, open admin panels, directory listing left on, or debug mode exposed on a live site
Vulnerable/outdated components	An old plugin, theme, or library with a known, published bug that hasn't been patched
Authentication failures	Weak or reused passwords, no lockout after failed logins, no multi-factor login option
Cryptographic failures	Sensitive data (passwords, card numbers) sent or stored without proper encryption, or an expired/misconfigured SSL certificate
Missing security headers	The site doesn't tell browsers to enforce HTTPS, block content-sniffing, or restrict where scripts can load from

(Source: OWASP Top 10)

A few of these you can spot yourself in minutes. Our free security headers checker scans for that last row instantly, and our guide on whether your website is hackable walks through the visible warning signs for the others.

A quick self-check before you panic (or don't)

When a report lands, run through this before deciding what to prioritize:

Read the finding title, not just the severity tag. "SQL Injection on login form" is worse than a Critical-labeled but theoretical issue that needs local server access.
Check if it's on the live site or just staging/dev. A vulnerability on a password-protected dev environment is far lower real-world risk.
Ask what data or access it touches. Customer emails and payment data matter more than a typo on an unused page.
Check the CISA KEV catalog if a CVE number is listed — is this being actively exploited right now, anywhere?
Confirm it's not a false positive. Automated scanners frequently flag things that a human glance rules out in seconds — this is the single biggest source of wasted panic for small site owners.

If you're already seeing strange behavior — unexpected admin users, spam pages appearing, a host warning — that's a different situation than a routine scan finding. Our what to do if your website's been hacked guide covers the immediate response steps.

Key takeaways

A vulnerability is the weakness, an exploit is the method used against it, and risk is how much it actually matters for your specific site — a report should never be read as "vulnerability = you're already hacked."
Severity labels (Critical/High/Medium/Low) come from CVSS scoring 0–10, but they measure technical impact only — always weigh a finding against what data or access it actually touches on your site.
If a CVE is listed on CISA's Known Exploited Vulnerabilities catalog, treat it as urgent regardless of its severity label.
Most small-site findings fall into a few repeatable buckets — outdated plugins, missing headers, weak access control, injection flaws — and each has a well-known, standard fix.
Automated scans are a good first pass but flag plenty of noise; a human reviewer who understands your specific setup is what turns a scary-looking list into a short, correctly prioritized to-do.

If you'd rather not decode a scan report alone, a real engineer can manually audit your site and hand you a plain-English list of what's actually urgent, with exact fixes — Circuit starts at $49, one time, no subscription required.

What Is SQL Injection? How a Form Leaks Data

Bug Circuit — Sat, 01 Aug 2026 23:13:49 +0000

Originally published on the Bug Circuit blog.

SQL injection is when an attacker types database commands into an ordinary web form — a search box, a login field, a "forgot password" box — and your website mistakenly runs those commands, often handing over every row in your database.

Who this is for

You run a small business website — a WordPress store, a Shopify-adjacent tool, an indie SaaS, or a site your agency built years ago — and someone mentioned "SQL injection" in a security questionnaire, a scary blog post, or a scan report. This guide explains what it actually is, how a single unprotected form can leak your whole customer and orders table, why "nobody's targeting little old me" doesn't protect you, and exactly what to check and fix. No jargon left unexplained.

What Is SQL Injection, in Plain English?

Your website's database (usually MySQL, PostgreSQL, or similar) stores everything: customer logins, orders, emails, sometimes payment references. To talk to that database, your website's code writes instructions in a language called SQL (Structured Query Language) — for example, "get me the customer whose email is X."

The problem happens when a developer builds that instruction by gluing raw user input directly into the command, like this:

SELECT * FROM users WHERE email = '" + userInput + "'

If userInput is a normal email address, this works fine. But if an attacker types something like ' OR '1'='1 into that box instead of an email, the database now reads a completely different instruction:

SELECT * FROM users WHERE email = '' OR '1'='1'

Since '1'='1' is always true, the database returns every user — not the one row the form intended. That's SQL injection: user input escaping the box it was meant to stay in and being executed as a command. OWASP's SQL Injection reference has the full technical breakdown, and injection flaws have sat in the OWASP Top 10 — the industry's standard list of the most common, most serious web application risks — for over two decades.

How One Search Box Can Leak an Entire Database

A login form is the classic example, but a search box is often worse, because search queries are naturally built from user text and often aren't protected as carefully.

Say your site has a product search that runs:

SELECT name, price FROM products WHERE name LIKE '%searchterm%'

If that query isn't built safely, an attacker can type a search term that isn't a search term at all — it's a UNION-based injection, which stitches a second, attacker-chosen query onto the first:

' UNION SELECT email, password FROM users --

If it works, the "product search" results page now quietly displays customer emails and password hashes instead of products. From there, an attacker can usually enumerate table names, dump the orders table, or pull payment-related fields — all through a box that was only ever supposed to filter a product list. No login required, no password guessed. One text field with no guardrails was the entire perimeter.

Why "We're Too Small to Target" Doesn't Hold Up

The instinct — "my site has 200 customers, nobody cares" — misunderstands how these attacks actually happen in 2026. Almost no one is manually typing payloads into your search box because they've heard of your business. Automated bots continuously crawl the open web, fingerprint what software and plugins a site is running, and fire known injection payloads at every form field they find — at a scale of thousands of sites per hour, with zero regard for how small you are.

This is exactly why CISA and the FBI issued a joint alert urging software makers to eliminate SQL injection through secure design, rather than treat it as a risk individual site owners can outsmart with obscurity — see CISA's Secure by Design alert on SQL injection. A vulnerable field is vulnerable whether one person or one million people know your brand name. If you want a sense of how exposed your specific site looks to that kind of automated scanning, our free website security check runs a passive pass with no card and no login required.

What It Looks Like When It Happens

SQL injection incidents on small sites tend to follow one of a few patterns:

Login bypass — attacker logs in as admin without a real password, using an OR '1'='1'-style payload.
Data dump — attacker uses UNION SELECT to pull customer emails, hashed passwords, or order history out through a search or filter field.
Blind injection — the page doesn't show data directly, but the attacker asks the database true/false questions one bit at a time (does row 1 start with 'a'? 'b'? ...) until they've reconstructed the data — slower, but works even when nothing looks obviously broken.
Destructive injection — instead of reading data, the attacker deletes or alters it (DROP TABLE), which is rarer but far more damaging to recover from.

If you're trying to work out whether an incident like this has already happened to you, our guide on signs your website may have been hacked walks through the concrete indicators to check first.

Is Your Site at Risk? A 5-Minute Checklist

You don't need to read code to get a first read on your exposure:

[ ] Any custom-built form or search box (not a stock plugin) that a developer wrote from scratch to query your database.
[ ] Old or unmaintained plugins/themes, especially on WordPress — outdated database-querying plugins are a common source.
[ ] Error messages that reveal SQL — try typing a single quote ' into a search or login field. If you see a database error mentioning "SQL syntax" or a table/column name, that's a strong red flag.
[ ] No web application firewall (WAF) in front of the site (Cloudflare, Sucuri, or similar) filtering malicious-looking requests.
[ ] A database user with full admin rights used for the website's day-to-day queries, instead of a limited-permission account.
[ ] No recent professional review of the code that handles forms, search, and login.

If you checked more than one box, treat it as a real priority, not a someday task.

How Developers Fix It (and How to Verify the Fix)

The fix is well-established: never let raw user input become part of the SQL command itself. Instead, the query structure is fixed in advance, and user input is passed in separately as a value — called a parameterized query or prepared statement.

Language / stack	Vulnerable pattern (avoid)	Safe pattern (use)
PHP + MySQL	`"SELECT * FROM users WHERE email='$email'"`	`mysqli_prepare()` / PDO with `?` placeholders and `bindParam`
Node.js + MySQL	Template string built into `query()`	`connection.query('...WHERE email = ?', [email])`
Python + PostgreSQL	f-string built into `cursor.execute()`	`cursor.execute("...WHERE email = %s", (email,))`
WordPress plugins	Raw `$wpdb->query()` with variables inline	`$wpdb->prepare()`

On top of parameterized queries, a solid fix also includes:

Least-privilege database accounts — the account your website uses shouldn't be able to DROP tables or read databases it doesn't need.
A WAF as a second layer that blocks obvious injection payloads before they reach your app.
Generic error pages — never show raw database errors to visitors; log them internally instead.
Regular patching of your CMS, plugins, and frameworks, since many public SQL injection reports are tied to specific vendor versions.

Verifying this properly — confirming every form actually uses parameterized queries rather than just "looking fine" in a browser — is genuinely a job for a human reviewing the code and testing each input field, not a five-minute self-check. That's the gap between an automated scanner glancing at your site and someone actually trying the payloads by hand; our guide on manual vs. automated penetration testing explains the difference in plain terms if you want to understand what you're paying for either way.

Key takeaways

SQL injection happens when user input (search terms, login fields) gets executed as a database command instead of being treated as plain text — a decades-old, still-common flaw per OWASP.
One vulnerable search box or login field can expose your entire customer and orders database — no password-guessing required.
Automated bots scan for this constantly and don't care how small you are; "too small to target" is not a defense.
The real fix is parameterized queries everywhere user input touches the database, plus least-privilege DB accounts, a WAF, and hidden error messages.
A quick self-check (try typing ' into your forms) can flag obvious problems, but only a human review can confirm every field is actually safe.

Not sure where you stand?

You don't need to take our word for any of this — start with the free passive security check, which gives you a quick yes/no read on critical issues with no card and no login. If you want someone to actually try these payloads against your forms and hand you a plain-English report of exactly what's exposed and how to fix it, that's what our $49 manual audit is for — a real engineer testing your site by hand, not another automated scan.

Domain Blacklisted? How to Delist and Recover

Bug Circuit — Fri, 31 Jul 2026 20:42:16 +0000

Originally published on the Bug Circuit blog.

A blacklisted domain almost always means your site or your email sending was compromised and abused for spam or malware — the fix is to clean up the actual security hole first, then request delisting directly from Spamhaus, Barracuda, and/or Google Safe Browsing through their official removal tools. Skipping straight to the delisting request without fixing the cause is the single biggest reason domains get re-listed within days.

This is for small business owners, indie SaaS founders, and agencies who got a bounced-email notice mentioning "blocked" or "blacklisted," or who opened their site in Chrome and saw a red "Dangerous site" warning. You'll get the exact delisting steps for the three blacklists that cause the most real-world pain, plus the root-cause checklist that actually keeps you off the list.

Why domains get blacklisted in the first place

Blacklists (also called blocklists or RBLs — real-time blackhole lists) exist so email providers and browsers can automatically reject traffic from known-bad sources. Your domain or IP doesn't get flagged at random. It's almost always one of these:

A compromised website is sending spam through a mail script, a hacked contact form, or a webshell an attacker installed.
Malware or a phishing kit got uploaded to your site (often through an outdated plugin or theme), so Google Safe Browsing flags visitors before they load the infected page.
Weak email authentication — no SPF, DKIM, or DMARC — let someone spoof your domain to send phishing or spam, which mail providers then trace back to you.
A shared host or reused password got breached elsewhere, and the same credentials were reused to log into your site or hosting panel.

The OWASP Top 10 guidance on security misconfiguration covers exactly the kind of default settings, exposed admin panels, and unpatched software that lead to this chain of events. If you're not sure which of these applies to you, our guide on whether your site is actually hackable walks through the common entry points.

Step 1: Confirm which blacklist you're actually on

Don't guess — check first, because each list has a different removal process. Two free ways to check:

MXToolbox Blacklist Check (mxtoolbox.com/blacklists.aspx) — enter your domain or mail server IP and it queries dozens of blacklists at once, including Spamhaus and Barracuda.
Google Safe Browsing Transparency Report (transparencyreport.google.com/safe-browsing/search) — enter your domain to see if Google currently flags it as unsafe and why.

If you got a specific bounce message from a mail server, read it carefully — it usually names the exact list (e.g., "550 5.7.1 blocked by Spamhaus SBL") and often includes a lookup link.

How to delist from Spamhaus

Spamhaus runs several lists — the most common for small businesses are the SBL (IP-based, spam sources) and the DBL (Domain Block List, for domains used in spam links or phishing).

Go to Spamhaus's own lookup tool at check.spamhaus.org and enter your domain or IP.
If listed, click through to the specific listing page — it explains why you were listed (spam trap hit, phishing URL, compromised host, etc.).
Fix the underlying issue (see the root-cause checklist below) before submitting removal — Spamhaus explicitly asks you to confirm the problem is resolved.
Submit a removal request through the link on that listing page. Spamhaus's official FAQ on the Domain Block List explains what evidence they expect and how long review typically takes.

Spamhaus removals are usually processed within a few hours to a couple of days once you've genuinely fixed the cause.

How to delist from Barracuda (BRBL)

Barracuda's Reputation Block List is common on corporate mail servers and G Suite/Microsoft 365 gateways that use Barracuda filtering.

Check your status at barracudacentral.org/lookups.
If listed, go to Barracuda's official removal request form.
Enter the flagged IP or domain and submit. Barracuda's system runs an automated re-check; if your mail server no longer shows spam-like behavior, it's typically delisted within a few hours.
If it relists shortly after, that's a strong signal the compromise wasn't actually fixed — go back to the root-cause checklist.

How to delist from Google Safe Browsing

This is the one that shows visitors a full-page red warning, so it hurts the most visibly.

Verify your site in Google Search Console (search.google.com/search-console) if you haven't already.
Open the Security Issues report in the left sidebar. Google lists exactly what it found — injected spam content, malware, or a phishing page — and often the specific infected URLs.
Remove the malicious code, files, or redirects (see checklist below).
Back in Search Console, click Request a Review and describe what you fixed.
Google typically re-crawls and clears flagged sites within a few days if the issue is genuinely resolved; see Google's own "Fix hacked pages" guide for the full remediation walkthrough they expect before you request review.

Blacklist comparison at a glance

Blacklist	What it flags	Where to check	Where to request removal	Typical turnaround
Spamhaus SBL/DBL	Spam-sending IPs, spammy/phishing domains	check.spamhaus.org	Listing page → removal link	Hours–2 days
Barracuda BRBL	Spam-sending mail servers	barracudacentral.org/lookups	barracudacentral.org/rbl/removal-request	Hours–1 day
Google Safe Browsing	Malware, phishing pages on your site	Search Console → Security Issues	Search Console → Request Review	1–5 days

Fix the root cause first — or you'll be back on the list

This is the step people skip, and it's why the same domain shows up on these lists again and again. Before requesting delisting, work through this checklist:

[ ] Scan every file on the server for unexpected PHP/JS files, especially in /uploads, /tmp, and theme/plugin folders (webshells often hide with names close to legitimate files).
[ ] Check for unauthorized admin accounts or unfamiliar users in your CMS.
[ ] Rotate every credential: hosting panel, CMS admin, database, FTP/SFTP, and any API keys stored in config files.
[ ] Update the CMS core, all plugins, and the theme to the latest versions — most compromises come through a known, already-patched vulnerability.
[ ] Check .htaccess, wp-config.php, and any cron jobs for injected redirects or scheduled scripts you didn't add.
[ ] Restore from a known-clean backup if one exists from before the compromise, then re-apply only the legitimate changes since.
[ ] Check outbound mail logs for a spike in sent volume — that's usually the smoking gun for spam-based blacklisting.

If you found active malware or a defaced page, our hacked website recovery guide covers the full incident-response sequence in more detail.

Stop it from happening through email spoofing

A lot of domain blacklisting isn't from a hacked website at all — it's from a domain with no email authentication, which lets attackers send phishing mail that looks like it's from you. Three DNS records fix this:

SPF — lists which servers are allowed to send mail for your domain.
DKIM — cryptographically signs your outgoing mail so it can't be forged in transit.
DMARC — tells receiving mail servers what to do with mail that fails SPF/DKIM, e.g.:

 v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com;

Without DMARC, spoofed mail sent "from" your domain can trigger spam-trap hits that get your domain blacklisted, even though you never sent it. Run your domain through our email spoofing and DMARC checker to see your current exposure — it's free and takes under a minute.

How long full recovery actually takes

Delisting itself is usually fast once the cause is fixed — hours to a few days per list. The part that takes longer is confirming the compromise is fully gone: checking logs for persistence mechanisms, verifying no backdoor survived the cleanup, and monitoring outbound mail and file integrity for a week or two afterward. Rushing the delisting request before that confirmation is exactly how domains bounce on and off the same list.

Key takeaways

Blacklisting is a symptom — find and fix the actual compromise (hacked files, phishing malware, or spoofed email) before requesting removal.
Spamhaus, Barracuda, and Google Safe Browsing each have their own free lookup and removal tools — use the official one, never a paid "instant delisting" service.
Rotate every credential and update every plugin/theme as part of cleanup, not just the file that looked obviously malicious.
Add SPF, DKIM, and DMARC so spoofed phishing mail can't get your domain flagged for something you didn't send.
If you're not sure your cleanup was complete, a second set of eyes on the actual codebase is worth it before you declare victory.

If you want confirmation that the compromise is actually gone — not just that the warning page disappeared — a real person manually auditing your site catches backdoors and leftover malware that automated scanners miss. Circuit is a $49 one-time manual audit with a full written report of what's still wrong and exactly how to fix it, and you can start with a free passive security check if you just want a first read on your risk.

Host Suspended Your Site for Malware? Do This

Bug Circuit — Fri, 31 Jul 2026 02:35:33 +0000

Originally published on the Bug Circuit blog.

If your host suspended your site for malware, the fastest way back online is: get the exact scan report from your host, remove the malicious files (not just disable the infected plugin), rotate every password and secret key, update everything, run a clean third-party scan, and send your host proof of all of it before you ask for reinstatement. Skipping the "proof" step is the single biggest reason sites get re-suspended within days.

This is for site owners staring at a "suspended due to malicious content" email from GoDaddy, Bluehost, SiteGround, Hostinger, WP Engine, or a similar host, with no idea what to do next. By the end you'll have a step-by-step process to identify the infection, clean it properly, and get your host to turn the site back on — plus what to do so it doesn't happen again.

What "suspended for malware" actually means

Hosts don't suspend sites to be difficult. Malware on your site can spam other customers' shared servers, get the host's whole IP range blocked by email providers, or trigger Google Safe Browsing warnings that make the host's network look untrustworthy. Suspension is the host protecting its own infrastructure — your reinstatement path exists, but you have to do the cleanup, and you usually have to prove it.

Common triggers: a hidden backdoor script uploaded through an outdated plugin, injected spam links or redirects, a cryptomining script, or your site being used to host a phishing page. All of these get caught the same way — by a scanner (the host's own, or Google's) flagging known malicious patterns.

Step 1: Get the exact reason from your host

Don't start deleting files yet. Open a support ticket and ask specifically for:

The scan report or list of flagged files and paths
The date/time the infection was detected
Whether they've already quarantined or restored anything
Their exact reinstatement requirements (some hosts want a signed statement, some want a specific scanner's clean report, some will rescan themselves)

Many hosts (GoDaddy, Bluehost/EIG-family brands, SiteGround) run automated malware scanners on shared hosting and will hand you a file list on request — this saves you hours of guessing.

Step 2: Check how bad it looks from the outside

Before touching code, check what the internet already knows:

Search site:yourdomain.com in Google — spammy titles or foreign-language pages you didn't write are a strong signal of injected content.
Check your domain's status at Google's Safe Browsing site status tool.
Log into Google Search Console and check the Security Issues report if the site is verified — it often names the exact malware type (e.g., "injected content," "harmful downloads").

If you're not sure whether the site is actually compromised or just misflagged, our free website security check can give you a quick read before you spend hours digging.

Step 3: Find and remove the malicious code

This is the part people rush and get wrong. Disabling the plugin the malware came in through does not remove a backdoor the attacker already planted elsewhere.

If you have a clean backup from before the infection date, restoring it is usually faster and safer than manual cleanup — as long as you also patch the entry point (Step 5) before putting it back online.

If you don't have a clean backup, look for:

Obfuscated PHP: eval(base64_decode(...)), gzinflate(...), str_rot13(...) inside theme or plugin files that shouldn't contain them
Files with recent modified dates you don't recognize, especially in /wp-content/uploads/ (uploads folders shouldn't contain .php files at all)
Extra admin accounts you didn't create (check Users in your CMS admin, or the database wp_users table directly)
Unfamiliar entries in .htaccess, especially RewriteCond/RewriteRule blocks that redirect mobile visitors or search-engine bots to a different site
Scheduled tasks (cron jobs) you didn't set up, in your hosting control panel or via a plugin like WP Crontrol

Compare core CMS files against a fresh download of the same version — any core file that differs from the official release is suspect. Google's own "Clean up your hacked site" guide walks through this file-by-file comparison process in more detail.

Step 4: Lock the doors — rotate every credential

Attackers who got in once often leave themselves a way back in. Before you reopen the site:

Change your hosting/cPanel password, database password, FTP/SFTP password, and every admin account password
Regenerate WordPress secret keys via api.wordpress.org/secret-key/1.1/salt/ and paste them into wp-config.php
Delete any admin user you don't recognize
Revoke and reissue API keys for any connected services (payment processors, email senders, CDNs)

Step 5: Update everything before you reopen

Outdated, unpatched software is how most of these infections start — it's consistently one of the top causes tracked in the OWASP Top 10 under vulnerable and outdated components. Update your CMS core, every theme, and every plugin to their latest versions, and remove anything inactive you're not using — an unused plugin can still be exploited even if it's switched off.

Step 6: Get a clean scan your host will accept

Most hosts won't take your word for it. Run one (ideally two) of these before you file for reinstatement:

Scanner	Good for	Notes
Sucuri SiteCheck (free)	Quick outside-in check	Scans the live site remotely, no login needed
Wordfence / MalCare (WordPress)	Full file-system scan	Checks every file against known-malware signatures
Host's own scanner	Reinstatement requirement	Some hosts only accept their own rescan as proof

Keep a screenshot or exported report of the clean result — you'll attach it to your reinstatement request.

Step 7: Ask for reinstatement — and prove it's clean

Reply to your original support ticket with:

What the infection was and where it was (referencing their scan report)
What you removed and what you patched (be specific: "deleted wp-content/uploads/2024/xx.php, updated Plugin X from 4.1 to 4.9")
Your clean scan report or screenshot
Confirmation that passwords and keys were rotated

After reinstatement, if Search Console showed a Security Issues warning, submit a review request there too — that's a separate step from your host unsuspending you, and it's what actually clears the browser warning for visitors.

DIY cleanup vs. professional help

	DIY	Host's paid cleanup	Manual audit ($49)
Speed	Hours to days, depends on skill	Usually 24–72 hrs	2–4 business days
Finds the root cause, not just the file	Sometimes — easy to miss backdoors	Varies by host	Yes, plus a written report of every issue found, with fixes
Ongoing protection	You're on your own	Ends after cleanup	Can pair with Signal for 3 months of cover + fixes to critical issues
Cost	Free (your time)	Often $100–$300+	$49 one-time

If you cleaned it yourself and just want a second set of eyes to confirm nothing was missed before you tell your host it's fixed, that's exactly the kind of check a manual audit is good for — it's not a substitute for the cleanup itself, but it catches what automated scanners and a rushed manual pass often miss. Compare that to a full penetration test cost if you're weighing options, and see how manual review differs from automated scanning if you're deciding which route fits.

How to stop this from happening again

Turn on automatic updates for your CMS core and plugins where your host supports it
Set up basic security headers — they won't stop every attack, but they close off easy wins like clickjacking and some injection vectors
Keep offsite backups on a schedule your host doesn't control, so a future infection doesn't wipe your only clean copy
Run a free security check periodically, and read how to tell if your site is hackable before the next scare

For background on the general categories of attacks hosts are scanning for, CISA's malware, phishing, and ransomware overview is a solid plain-English primer if you want to understand the bigger picture beyond your own incident.

Key takeaways

Get the host's exact scan report first — don't guess at what's infected
A clean backup restore plus patching the entry point beats manual file-by-file removal when you have one
Rotate every password and secret key, not just the CMS admin password
Run a clean third-party scan and attach the report to your reinstatement request — hosts rarely reinstate on your word alone
Fix the update/backup habits that let it happen, or expect a repeat

If you'd rather have a person confirm the infection is fully gone (and check for anything else an attacker could come back through) before you go back to your host, a Circuit audit is a $49 manual review with a written report — a second, human set of eyes on exactly this kind of situation.

Website Redirecting to Spam? How to Stop It

Bug Circuit — Fri, 31 Jul 2026 02:29:37 +0000

Originally published on the Bug Circuit blog.

If your website sends visitors to a spam, scam, or gambling site, you've almost certainly been hacked — and the redirect is hiding in one of four places: your .htaccess file, injected JavaScript, your WordPress database or a rogue plugin, or your DNS records. The fix depends entirely on which one it is, so guessing (or just reinstalling your theme) usually doesn't work.

This is for site owners — WordPress, Shopify, or a hand-built site — who've noticed weird redirects, gotten a "this site may be hacked" warning in Google, or had a customer say "your link took me somewhere sketchy." You'll get a step-by-step way to find exactly where the redirect is firing from, plus how to close it, including the sneaky version that only redirects mobile visitors or people coming from Google.

Why "website redirecting to another site" is almost always a hack, not a bug

A legitimate site doesn't randomly start sending people to pill ads, fake tech-support pages, or spam text in another language. When that happens, it's almost always malware planted after your site, a plugin, or your hosting account got compromised — commonly through a stolen FTP/hosting password, an outdated plugin with a known vulnerability, or a compromised admin account. Google's own guidance on hacked sites confirms this pattern and calls out redirect hacks specifically as a common attack type (Google Search Central: hacked sites overview).

The attacker's goal is usually SEO spam or ad fraud: they want your site's existing traffic and search ranking to funnel visitors to their pages, without you noticing for as long as possible. That's why these redirects are almost never "always on" — they're built to hide from you, the owner, while still firing for real visitors and search engines.

The 4 hiding spots, compared

Where it hides	How it usually triggers	Who notices it first
`.htaccess` (Apache config file)	Rewrite rules that check the visitor's User-Agent or Referer	Google Search Console, mobile users
Injected JavaScript	Obfuscated `<script>` in a theme file or footer that runs on page load	Desktop visitors, browser warnings
WordPress database / rogue plugin	Malicious `siteurl`/`home` value, or a fake plugin registering a redirect hook	Everyone, all the time (often the noisiest one)
DNS records	A/CNAME record repointed to attacker infrastructure	Everyone, but looks like the "whole site is down or moved"

Step 1: Rule out DNS first — it's the fastest check

Before you touch any files, confirm your domain is actually pointing at your own server. If your DNS was hijacked (usually via a compromised domain registrar or DNS provider account, not your website itself), no amount of file cleanup will fix it.

dig example.com A +short
dig example.com NS +short
whois example.com

Compare the A record IP against the IP your host gives you in your hosting control panel. If it doesn't match, or the nameservers (NS records) aren't the ones your registrar or DNS host assigned you, your DNS has been changed — go straight to your registrar, reset that account's password, and revert the records. This is a domain-account problem, not a website problem, so cleaning WordPress won't help.

Step 2: Check if the redirect is conditional (mobile-only or Google-only)

This is the step people miss. Many redirect hacks are deliberately conditional — they only fire for mobile users or for visitors arriving from a search engine, so the site owner checking it on a desktop browser sees nothing wrong. Test it the way an attacker built it to be tested:

# Simulate a normal visit
curl -I https://example.com

# Simulate Googlebot
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I https://example.com

# Simulate someone clicking through from a Google search on mobile
curl -e "https://www.google.com/search?q=example" -A "Mozilla/5.0 (Linux; Android 10; Mobile)" -I https://example.com

Look at the response headers. If the Googlebot or Google-referrer request returns a 301 or 302 with a Location: header pointing somewhere unfamiliar, but your plain request doesn't, you've confirmed a conditional redirect — and you now know it's checking User-Agent and/or Referer, which narrows the search to .htaccess or JavaScript (the next two steps).

Also check Google Search Console's Security Issues report (Search Console → Security & Manual Actions) — Google flags this exact "cloaked redirect" pattern when it crawls your site, per their hacked-site cleanup guide.

Step 3: Search .htaccess for User-Agent or Referer rules

Open .htaccess in your site's root directory (via FTP/SFTP or your host's file manager) and look for RewriteCond lines referencing HTTP_USER_AGENT or HTTP_REFERER, especially ones mentioning "google," "bing," "yahoo," or "mobile." A legitimate rule rarely needs to check for search engine names. A malicious block often looks like this:

RewriteCond %{HTTP_REFERER} google\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Mobile
RewriteRule ^(.*)$ http://spam-domain.example/landing.php [R=302,L]

Delete any block you don't recognize, save, and re-run the curl tests from Step 2 to confirm it's gone. Keep a backup copy of the file before editing, in case you need to compare it later.

Step 4: Search for injected JavaScript

If .htaccess is clean but the redirect still fires (especially only on desktop, or only after a delay), the payload is likely JavaScript stuffed into a theme file, a widget, or a compromised plugin's assets. Search your theme folder for obvious obfuscation:

grep -rl "eval(" wp-content/themes/
grep -rl "base64_decode\|gzinflate\|String.fromCharCode" wp-content/themes/ wp-content/plugins/

Real theme code almost never uses eval() combined with base64_decode — that combination is a near-universal signature of injected malware, because it lets the attacker hide the real payload from casual inspection. Also check footer.php and header.php for <script> tags you didn't add. OWASP's guidance on unvalidated redirects and forwards is a good primer on why these injections work so well (OWASP Top Ten): browsers and users trust redirects that appear to come from a site they already trust.

Step 5: Check the WordPress database and plugins

If you're on WordPress, the hack often lives in the database itself, not the files. Two places to check, using WP-CLI:

Site URL hijack — run wp option get siteurl and wp option get home. If either points to a domain that isn't yours, that's your redirect source.
A rogue or disguised plugin — run wp plugin list and look for anything you don't recognize, or a "legit-looking" plugin name you never installed. Also compare your core files against the official versions with wp core verify-checksums, a built-in WP-CLI command that flags any modified core file.

Malicious code also frequently gets planted directly in the wp_posts or wp_options table as a serialized PHP snippet that runs on init. This is harder to spot by eye than a file, which is one reason a manual, human-led review tends to catch what a quick automated scan misses.

Fix checklist, in order

[ ] Confirm DNS A/NS records match your actual host (Step 1)
[ ] Test with curl using Googlebot and mobile User-Agents to catch conditional redirects (Step 2)
[ ] Remove suspicious RewriteCond/RewriteRule blocks from .htaccess (Step 3)
[ ] Grep theme/plugin files for eval(, base64_decode, and obfuscated <script> blocks (Step 4)
[ ] Check wp option get siteurl/home and run wp core verify-checksums (Step 5)
[ ] Change all passwords — hosting, FTP, WordPress admin, registrar — since redirects usually mean broader access was gained, not just one file
[ ] Update every plugin, theme, and WordPress core to the latest version
[ ] Re-check Search Console's Security Issues report after cleanup and request a review

Run our free website security check after cleanup to confirm the redirect and any related malware are actually gone, not just hidden again.

When to stop DIY-ing it

If you've been through all four checks and the redirect keeps coming back, or you're not comfortable editing .htaccess and database values on a live production site, that's the point to bring in a second pair of eyes. Automated scanners are good at flagging known malware signatures but routinely miss custom, hand-placed redirects like the ones above — that gap is exactly why manual review exists; see our comparison of manual vs. automated penetration testing for why it matters here. It's also worth reading is my website hackable to understand what let the attacker in, so you're not just cleaning the symptom and leaving the door open.

Key takeaways

A spam redirect almost always means compromise, not a bug — and it hides in .htaccess, injected JavaScript, your WordPress database/plugins, or DNS.
Test with curl using a Googlebot User-Agent and a Google referrer before assuming your site is clean — many redirects are deliberately conditional and invisible on a normal desktop visit.
Rule out DNS first with dig — if the A or NS records are wrong, no file cleanup will fix it.
eval() combined with base64_decode in theme or plugin files is a near-certain sign of injected malware.
After cleaning up, change every password tied to the site (hosting, FTP, WordPress, registrar) — the redirect was a symptom of broader access, not an isolated glitch.

If you've gone through this checklist and still aren't fully sure it's clean — or you'd rather have someone find the exact injection point for you — Bug Circuit's Circuit audit is $49 for a human security engineer to manually trace it, document exactly what was changed and where, and hand you the precise fix. No card needed to start with the free check first.

Fix the 'Not Secure' Warning on Your Website

Bug Circuit — Fri, 31 Jul 2026 02:29:21 +0000

Originally published on the Bug Circuit blog.

The "Not Secure" warning means your site either has no SSL certificate, an expired one, or is loading some content over an insecure http:// connection — and you fix it by installing (or renewing) a certificate, forcing every page to load over https://, and cleaning up any leftover http:// links.

This is for any small business owner, blogger, or shop owner who opened their site and saw "Not Secure" next to the address bar — and now customers are asking about it (or worse, leaving). You don't need to be technical. Below is the exact sequence: diagnose, fix, verify, in about 20-40 minutes depending on your platform.

What "Not Secure" actually means

Every browser checks whether your site is using HTTPS — the encrypted version of the web address protocol. HTTPS relies on an SSL/TLS certificate, a small file that proves your domain is who it says it is and encrypts the connection between your visitor's browser and your server. Chrome explains its address-bar security indicators directly here: Chrome's "Not secure" warning explained.

You'll see the warning for one of three reasons:

No certificate at all — your site is still served over plain http://.
A broken certificate — expired, self-signed, or issued for the wrong domain (e.g., it covers example.com but not www.example.com).
Mixed content — the page itself loads over HTTPS, but it's pulling in an image, script, or stylesheet from an http:// address, so the browser can't call the whole page secure.

All three are fixable without touching code. Here's the order to work through them.

Step 1: Diagnose which one you have

Before fixing anything, find out exactly what's broken:

Click the padlock or "i" icon in your browser's address bar and choose Certificate is not valid or Connection is not secure to see the reason.
Run your domain through Qualys SSL Labs' free SSL Test — it grades your certificate and flags expired, mismatched, or misconfigured setups in plain terms.
If the padlock looks fine but you still see a warning or a "not fully secure" icon, open your browser's developer console (F12 → Console tab) and look for lines mentioning "Mixed Content" — that confirms issue #3 above.

Write down which case you're in; it determines which step below actually applies to you.

Step 2: Install or renew the SSL certificate

If you have no certificate or an expired one, get a new one. Most hosts now offer this for free:

Platform	How to get/renew the certificate
WordPress (shared hosting)	Host's control panel → SSL/TLS → "Enable free SSL" (usually powered by Let's Encrypt)
Shopify	Settings → Domains — SSL is automatic and free; if it's missing, remove and re-add the domain
Squarespace / Wix	Settings → Domains → SSL — toggle on; provisioning can take up to 24-48 hours
Cloudflare (in front of any site)	SSL/TLS tab → set mode to "Full" or "Full (strict)", not "Flexible"
Custom server / VPS	Install Certbot for free Let's Encrypt certificates, set to auto-renew every 90 days

Let's Encrypt certificates expire every 90 days by design, specifically so renewal gets automated rather than forgotten — that's the single most common cause of a site suddenly going "Not Secure" after working fine for months. Confirm your host has auto-renewal turned on, not a manual reminder on someone's calendar.

One more gotcha: make sure the certificate covers every version of your domain you actually use — example.com, www.example.com, and any subdomains. A certificate issued for only one of those will show "Not Secure" on the others.

Step 3: Force every visitor onto HTTPS

Having a certificate isn't enough if your site still lets people load the http:// version. You need a redirect that automatically bumps every visitor to https://.

WordPress: install the free plugin Really Simple SSL — it detects your certificate and forces the redirect with one click, no code.
Cloudflare: SSL/TLS → Edge Certificates → turn on "Always Use HTTPS."
Apache (.htaccess): add this to the top of your .htaccess file:

  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx: in your server block:

  server {
      listen 80;
      server_name example.com www.example.com;
      return 301 https://$host$request_uri;
  }

Once the redirect works, add one more header to tell browsers to always use HTTPS for your domain from now on, even if someone types http:// again later: Strict-Transport-Security: max-age=31536000; includeSubDomains. This is called HSTS, and OWASP's cheat sheet covers exactly how to set it safely: OWASP HSTS Cheat Sheet. You can check whether yours (and other security headers) are already in place with our free security headers checker.

Step 4: Clean up mixed content

If the padlock shows a warning icon even after Steps 2-3, some element on the page is still loading over plain http://. Browsers block or flag this because an attacker on the same network could tamper with that one insecure file and use it to attack the rest of the page — Mozilla's developer docs explain the mechanics here: MDN: Mixed content.

Common culprits and fixes:

Old image or script tags hardcoded as http://yoursite.com/logo.png — change them to https:// or, better, a protocol-relative //yoursite.com/logo.png.
Embedded content (YouTube videos, fonts, ad scripts, widgets) pulled from a third party still on http:// — check the embed code and swap to the provider's https:// version.
Database-stored links in WordPress posts/pages from before you had SSL — use the plugin Better Search Replace (or Really Simple SSL's built-in "Mixed Content Fixer") to bulk-update http://yoursite.com to https://yoursite.com across your database.

After fixing, reload the page and re-check the browser console — no more "Mixed Content" warnings means you're done.

Step 5: Verify the fix actually stuck

Check all of these before calling it fixed:

[ ] https://yourdomain.com loads with a padlock, no warning
[ ] http://yourdomain.com automatically redirects to https://
[ ] http://www.yourdomain.com and https://www.yourdomain.com also redirect correctly
[ ] Browser console shows zero mixed-content errors on your homepage and top 2-3 pages
[ ] SSL Labs test shows grade A or A+, not a warning
[ ] Certificate expiry date is at least a month out, and auto-renewal is confirmed on

If any box stays unchecked after these steps, the underlying cause is usually a caching layer (CDN or browser cache serving an old version) — clear your CDN cache and hard-refresh before troubleshooting further.

Key takeaways

"Not Secure" almost always means one of three things: no certificate, a broken/expired certificate, or mixed content — diagnose which one first.
Get a free certificate from Let's Encrypt (via your host or Certbot) and confirm auto-renewal is on, since 90-day expiry is the #1 cause of recurring warnings.
Force HTTPS with a 301 redirect (plugin, Cloudflare toggle, or a few lines in .htaccess/Nginx config), then add an HSTS header.
Hunt down and update any leftover http:// links in images, embeds, or your database — that's what causes mixed-content warnings even after the certificate is fixed.
Re-test with SSL Labs and your browser console before considering it closed.

If you've fixed the padlock but you're still wondering what else on your site might be exposed, that's worth a second look — our guide on what makes a website hackable covers the other common gaps. And if you'd rather have a person confirm everything is actually locked down (not just the padlock, but the whole site), Bug Circuit's Circuit audit is a one-time $49 manual review by a real security engineer, with a full report of anything else worth fixing. You can also start with a free passive security check — no card, no login — before deciding if you need more.

12 Signs Your Website Has Been Hacked

Bug Circuit — Fri, 31 Jul 2026 02:23:38 +0000

Originally published on the Bug Circuit blog.

If your site shows a browser warning, redirects visitors somewhere strange, has admin accounts you didn't create, or your emails are suddenly bouncing, treat it as hacked until you've checked and ruled it out. None of these signs alone is proof, but two or more together is a strong signal.

This is for any small business owner, freelancer, or agency running a WordPress site, Shopify store, or small SaaS app who's noticed something "off" and wants to know if it's a hack or a glitch. You'll get a plain-English checklist of the 12 most common symptoms, what each one actually means, how urgent it is, and the exact first steps to take.

Quick-scan checklist

Run down this table first. Anything in the Critical or High row means stop reading and act now — jump to "What to do right now" below.

Sign	What it usually means	Urgency
Browser or antivirus blocks your site	Malware or phishing content detected	Critical
Google flags you in Search Console	Confirmed malware, spam, or hacked content	Critical
Visitors get redirected to another site	Malicious redirect script injected	Critical
Homepage defaced or shows a ransom note	Active, confirmed compromise	Critical
New admin/user accounts you didn't create	Attacker has persistent access	Critical
Unknown PHP/script files in your file manager	A backdoor was uploaded	High
Site is suddenly slow or host suspends you	Server resources hijacked (e.g., crypto-mining)	High
Popups or ads only visitors see, not you	Cloaked malware showing different content to bots vs. humans	High
Emails from your domain bounce or land in spam	Domain blacklisted or used to send spam	Medium
Customers report fraud after buying from you	Payment page or card data possibly skimmed	Critical
Gibberish or spammy pages show up in Google	"SEO spam" injection targeting search rankings	Medium
Can't log in / login page looks different	Credentials changed or a fake login page installed	High

The 12 signs, explained

1. Your browser or antivirus blocks the site

If Chrome, Safari, or your antivirus shows a "Deceptive site ahead" or "This site may harm your computer" warning, Google or another security vendor has already detected malware or phishing on your pages. Check your status directly with Google's Safe Browsing site status tool — it's free and takes ten seconds.

2. Google Search Console shows a Security Issues warning

If you have Search Console set up, go to Security & Manual Actions > Security Issues. A message here ("hacked content," "harmful content," or "URL injection") is Google's own confirmation, not a guess. Google documents the common causes and cleanup steps in its hacked-sites help center.

3. Visitors get redirected to a random site

Someone lands on your homepage and ends up on a casino, pharmacy, or fake-prize site instead. This is almost always a malicious redirect injected into your theme files, .htaccess, or a compromised plugin. It often only fires for visitors coming from Google, so you may not notice it browsing directly — test in an incognito window from a search result, not by typing your URL.

4. Gibberish or spammy pages show up in your Google results

Search site:yourdomain.com in Google. If you see pages you never wrote — often in Japanese, Chinese, or stuffed with pharmacy/gambling keywords — that's "SEO spam injection." Attackers create thousands of hidden pages on your domain to piggyback on its search authority.

5. There's an admin account you didn't create

Check Users > All Users in WordPress, or run wp user list --role=administrator if you have WP-CLI access. An unfamiliar admin (sometimes with a generic name like "support" or "admin2") means an attacker created persistent access — even if you change your password, they can still log back in through that account.

6. Unfamiliar files appear in your file manager

Look in wp-content/uploads/, your theme folder, or your site root for .php files that don't belong there — uploads folders should never contain executable scripts. A quick way to spot recently added files via SSH: find . -type f -mtime -14 -name "*.php". These are frequently backdoors that let an attacker back in even after you "clean" the visible hack.

7. Your site is suddenly slow, or your host suspends it for "resource abuse"

A hosting email about excessive CPU use, or a site that crawls to a halt, can mean an attacker installed a script that mines cryptocurrency or sends spam email using your server's resources. Check your hosting control panel's resource-usage graph for an unexplained spike.

8. Emails from your domain bounce or land in spam

If customer emails suddenly bounce, or your own test emails land in spam, your domain may have been used to send spam and gotten blacklisted, or your SPF/DKIM/DMARC records were tampered with. Run a free check with our email spoofing and DNS checker to confirm your records are intact and your domain isn't blacklisted.

9. Popups, fake update prompts, or ads appear — but only for visitors

If customers report seeing "Your Flash Player is out of date" popups or unexpected ads, but you see nothing when you visit, that's likely cloaking: malicious code detects it's talking to a real visitor (not a search bot or the site owner) and serves different, malicious content. This is a classic technique to avoid detection while still infecting visitors — OWASP's guidance on detecting and responding to this kind of compromise is a solid technical reference if you want the deeper mechanics.

10. You can't log in, or the login page looks different

A changed login URL, a login form that looks slightly off, or a password reset that silently fails can mean an attacker replaced your login page with a fake one to harvest credentials, or locked you out after taking over the account.

11. Customers report fraud charges right after buying from you

This is one of the most serious signs on this list. If several customers report card fraud shortly after a purchase, your checkout page or payment integration may have been tampered with (a "web skimmer") to capture card details in real time. Treat this as a critical, drop-everything incident — it can trigger real financial harm to real people.

12. The homepage is defaced, or there's a ransom note

The most obvious sign: your homepage is replaced with a message, a flag, a group's logo, or a ransom demand. This confirms an active compromise with write access to your files. CISA's incident reporting guidance explains when and how to report an incident like this, particularly if customer data may be involved.

What to do right now

If two or more of the signs above match, work through this in order:

Take a backup of the current (compromised) state first — you'll want evidence, and a clean restore point may need comparison.
Change every password: hosting account, CMS admin, database, FTP/SFTP, and any team logins. Use unique, long passwords for each.
Check for accounts and files you didn't create (signs #4 and #5 above) and remove anything unfamiliar.
Ask your host for their malware scan/cleanup tool — most reputable hosts have one, and can also tell you if other sites on shared hosting were the entry point.
Verify your DNS and email records haven't been changed using our email spoofing checker.
Request a review in Google Search Console once you're confident the site is clean, so the browser warnings and search flags get lifted.
If money, customer data, or payment details were involved, document everything and consider your legal/regulatory notification obligations.

If you're not confident doing this yourself — and most non-technical owners aren't — that's exactly the gap a manual audit closes. For the full step-by-step process (not just the checklist), see our complete guide to what to do when your website's been hacked. If you just want a free first read before spending anything, our free website security check will tell you, no card required, whether something critical is actually going on.

Key takeaways

Two or more signs from the checklist above (especially anything marked Critical) means you should act now, not "when you get a chance."
A hacked site almost always has a hidden backdoor file or extra admin account — cleaning the visible symptom without finding that is why sites get re-hacked within days.
Bounced email and blacklisting are DNS-level symptoms; check your SPF/DKIM/DMARC records, don't just resend the email.
Google Search Console's Security Issues report is the most reliable free confirmation you can get in under a minute.
If fraud is involved, or you're not sure what you're looking at, a second pair of trained eyes beats guessing — a $49 manual audit finds and documents the actual cause instead of you chasing symptoms in the dark.

Bug Circuit's $49 Circuit audit has a real engineer manually go through your site, confirm which of these signs are real, find the backdoor or root cause, and hand you a plain-English report with exact fixes — see pricing if you want a professional to confirm and fix it rather than guess.