DEV Community: Bug Circuit

Squarespace Hacked or Redirecting to Spam? Fix It

Bug Circuit — Mon, 28 Sep 2026 15:38:46 +0000

Originally published on the Bug Circuit blog.

If your Squarespace site is redirecting to spam or showing a "deceptive site" warning, the fix depends on whether the problem is in your domain's DNS settings or inside your Squarespace account itself — and you can usually tell which one it is in under five minutes.

This is for Squarespace site owners who opened their site (or had a customer tell them) and found it redirecting somewhere else, showing spam content, or triggering a Google Chrome "Deceptive site ahead" warning. Unlike WordPress, you can't SSH in and inspect server files — everything you can fix lives in two dashboards: your Squarespace account and your domain registrar. This guide walks through both, in order, so you stop the bleeding first and clean up second.

Domain problem or account problem? Run this check first

Squarespace gives every site a free built-in preview address that looks like yourname.squarespace.com. You can find it under Settings > Domains in your dashboard. This one link tells you almost everything:

What you see	What it means
`yourname.squarespace.com` loads your real site fine, but your custom domain (`yoursite.com`) redirects to spam	Domain/DNS-level issue. Your Squarespace content is untouched — traffic is being hijacked before it ever reaches Squarespace's servers.
Both the `.squarespace.com` link AND your custom domain show spam, blank pages, or unfamiliar content	Account-level compromise. Someone got into your Squarespace login and changed something inside your site.
Chrome/Safari shows a "Deceptive site ahead" warning but everything looks normal when you're logged in	Often cloaking — injected code that shows spam only to search engine crawlers or first-time visitors, not to logged-in admins. Still an account-level compromise.
A WHOIS lookup (whois.com) shows a registrar, expiry date, or owner you don't recognize	Your domain itself may have expired and been re-registered by someone else, or your registrar account was compromised — this isn't a Squarespace hack at all.

Keep this table open while you work through the steps below — it decides which section applies to you.

If it's domain-level: your DNS or registrar was hijacked

A domain hijack happens when someone gets into the account that controls your domain's DNS records — the settings that say "send visitors of this domain to this server." If they change those records, your domain points to a spam or phishing server while your actual Squarespace site sits completely untouched.

This is common when your domain is registered with a third party (GoDaddy, Namecheap, Google Domains/Squarespace Domains, etc.) rather than through Squarespace directly, because it's a separate login with its own password and security settings that people forget about.

Do this now:

Log in to your domain registrar directly (not Squarespace) and check your DNS records. If your domain points to Squarespace, the A records and CNAME should match what Squarespace's own DNS instructions specify — anything else was added by someone else.
Check your nameservers (NS records). A more serious hijack replaces your nameservers entirely, moving DNS management to an attacker-controlled service. If your nameservers aren't the ones you originally set, that's the root cause.
Change your registrar password immediately and enable two-factor authentication (2FA) on the registrar account — this is separate from your Squarespace account password and is very often the weaker link.
Enable a registrar/transfer lock on the domain to stop it from being moved to another registrar without your approval.
If your domain is a "Squarespace Domain" (bought through Squarespace itself), there's no separate registrar — everything lives under Settings > Domains in your Squarespace account, so go straight to the account-level steps below and contact Squarespace support.
If you don't recognize the registrar account at all, or can't log in, contact that registrar's support immediately and explain the account may be compromised — most have a dedicated recovery process for exactly this.

If it's account-level: someone logged into your Squarespace account

Squarespace is a fully hosted platform, so there's no theme file or plugin for an attacker to plant malware in like on WordPress. Instead, a compromised account gets abused through Squarespace's own legitimate features — which is why it can be easy to miss.

Work through this checklist in order:

[ ] Change your Squarespace password right away, using a unique password you don't reuse anywhere else, and turn on two-factor authentication under Account Settings > Security.
[ ] Check Settings > Permissions & Ownership for any contributor or admin you don't recognize — remove them immediately.
[ ] Check Settings > Advanced > Code Injection. This is the most common injection point: attackers paste malicious JavaScript into the Header or Footer fields, which then redirects visitors or loads spam content on every page. Copy out anything you didn't add (for later review), then delete it.
[ ] Check Settings > Advanced > URL Mappings. This feature is meant for legitimate redirects (e.g., old page to new page), but attackers can add a rule that 301-redirects your entire domain to a spam or phishing site.
[ ] Scan your Pages panel for pages you didn't create — spam campaigns often add "doorway pages" stuffed with keywords and links, built purely to manipulate search rankings.
[ ] Check Settings > Advanced > External Services / Connected Accounts for any integration or API connection you don't recognize, and revoke it.
[ ] Contact Squarespace Support through your dashboard's Help panel and flag it explicitly as a security/account compromise. Their team can check account access logs, confirm whether the login came from an unfamiliar location, and help you verify the account is fully clean — something you can't fully do from the front end alone.
[ ] For a single hijacked page, Squarespace's version history (available in the page editor on most 7.1 sites) lets you roll back that page's content to an earlier version — useful for undoing a specific vandalized page rather than the whole site.

For a broader walkthrough of the mindset and order of operations when any site gets compromised, see our general guide on what to do when your website is hacked.

Clearing a Google security warning after you've fixed it

If visitors are seeing a "Deceptive site ahead" or "This site may be hacked" warning, that's coming from Google Safe Browsing, not Squarespace. You can check your domain's current status there directly.

Once you've removed the malicious code or fixed the DNS records:

Re-check the Safe Browsing Transparency Report for your exact domain.
If your domain is verified in Google Search Console, go to Security Issues in the sidebar and click Request a Review after confirming the issue is resolved.
Warnings typically clear within a few days once Google's crawler re-visits and confirms the site is clean — there's no fixed guarantee on timing, so don't repeat the review request more than necessary.

Preventing this from happening again

Turn on 2FA on both your Squarespace account and your domain registrar account — two separate logins, two separate weak points.
Use a password manager so you're not reusing a password that leaked in an unrelated breach; credential reuse is one of the most common ways accounts get taken over (OWASP: Credential Stuffing).
Set a calendar reminder for your domain renewal date — a surprising number of "hijacked domain" reports turn out to be an expired domain re-registered by a squatter, not an actual break-in.
Periodically glance at Code Injection and URL Mappings even when nothing looks wrong — they're the two places a compromise would most likely hide on a Squarespace site.
Be alert for phishing emails pretending to be from Squarespace or your registrar asking you to "verify your account" — this is the most common way these logins actually get stolen in the first place (CISA: Avoiding Social Engineering and Phishing Attacks).
If you're not sure whether your setup has other soft spots — old integrations, exposed forms, weak account permissions — a free passive security check will give you a quick yes/no on anything critical, no login required.

FAQ

My Squarespace site is hacked — what do I do first?
First confirm whether it's account-level or domain-level using the yourname.squarespace.com preview link test above — that determines whether you're fixing things inside Squarespace or inside your domain registrar. Then immediately change your Squarespace password, enable 2FA, and check Code Injection and URL Mappings for anything you didn't add.

Why is my Squarespace site redirecting to another website?
The two most common causes are malicious JavaScript pasted into Code Injection, or an unauthorized rule added under URL Mappings — both require someone to have your account login. If your .squarespace.com preview link still loads correctly while your custom domain redirects, the cause is DNS, not your Squarespace account.

Can a Squarespace domain actually be hijacked?
Yes — if your domain's DNS or registrar account is compromised, attackers can point your domain to a completely different server without ever touching your Squarespace account. This is especially common when the domain is registered with a third party you log into separately and rarely check.

Will Squarespace restore my site if it's hacked?
Squarespace support can review account access logs, help you confirm the login history, and guide you through securing the account, and page-level version history can roll back individual pages. There isn't a one-click "restore the whole site" button, which is why removing the malicious Code Injection or URL Mapping entries yourself is usually the fastest fix.

How do I get rid of a Google "deceptive site" warning on Squarespace?
Fix the underlying cause first (bad code injection, rogue redirect, or hijacked DNS), confirm the site is clean, then request a review in Google Search Console under Security Issues if your domain is verified there. Clearance isn't instant, but it follows Google re-crawling a genuinely fixed site.

Key takeaways

Use the yourname.squarespace.com preview link as your fastest triage tool: if it's clean but your custom domain redirects, the problem is DNS, not your Squarespace account.
Account-level compromises almost always show up in Settings > Advanced > Code Injection or URL Mappings — check both first.
Domain-level hijacks are fixed at your registrar, not inside Squarespace — log in there separately and lock the domain once you're back in.
Enable 2FA on both your Squarespace account and your registrar account; they're two separate weak points attackers rely on.
Once you're clean, use the Safe Browsing Transparency Report and Search Console's Request a Review to clear any Google security warning.

If you've locked things down but want a second set of eyes confirming there's nothing else exposed — an old integration, a leftover admin, a form that shouldn't be public — a real engineer manually checking your whole site for $49 through Bug Circuit's Circuit audit is a fast, honest way to be sure before you call it done.

Fix NET::ERR_CERT_AUTHORITY_INVALID: Owner's Guide

Bug Circuit — Fri, 25 Sep 2026 20:52:43 +0000

Originally published on the Bug Circuit blog.

If your own website shows NET::ERR_CERT_AUTHORITY_INVALID, the cause is on your server, not your visitor's browser — and it's almost always one of three things: a missing intermediate certificate, a Let's Encrypt renewal that silently failed, or the wrong certificate installed for that domain. All three are fixable in under 30 minutes without special tools.

Who this is for

This is written for the person who owns the site — not a visitor wondering whether it's safe to click "Advanced" and proceed. If that's you, skip the reassurance and go straight to the diagnosis below. You'll come away knowing exactly which of the three causes you have and the commands or settings to fix it, whether you're running WordPress on shared hosting, a Shopify custom domain, or your own Nginx/Apache server.

What this error actually means

Every SSL/TLS certificate is issued by a Certificate Authority (CA) — a company like Let's Encrypt, DigiCert, or Sectigo that browsers agree to trust. NET::ERR_CERT_AUTHORITY_INVALID means Chrome couldn't verify that chain of trust: either it can't find the CA that supposedly issued your certificate, or the certificate is self-signed (issued by your own server, not a real CA). Google's own explanation of Chrome connection errors covers this family of warnings and why the browser blocks the page instead of just showing a note (Chrome Help: Fix connection errors).

This is different from a hostname mismatch, which throws NET::ERR_CERT_COMMON_NAME_INVALID instead — more on that below, since owners often mix the two up after a migration.

Cause 1: Missing intermediate certificate

This is the most common cause by far. Your certificate isn't signed directly by a root CA that's built into every browser — it's signed by an intermediate certificate, which is in turn signed by the root. If your server only serves your certificate and skips the intermediate, browsers and command-line tools can't complete the chain, even though the certificate itself is perfectly valid.

How to check:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

If this hangs, errors, or a fuller openssl s_client run reports Verify return code: 21 (unable to verify the first certificate), your chain is incomplete.

How to fix it:

Nginx — your config must point to the fullchain file, not the bare certificate: ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; (not cert.pem). Reload with sudo nginx -t && sudo systemctl reload nginx.
Apache — make sure SSLCertificateChainFile (older Apache) or a combined SSLCertificateFile that includes the intermediate is set, then run sudo apachectl configtest && sudo systemctl reload apache2.
cPanel / shared hosting — go to WHM → SSL/TLS → Install an SSL Certificate and paste the full bundle your CA gave you (certificate + intermediate), or simply re-run AutoSSL under WHM → Manage AutoSSL.
Managed WordPress hosts (SiteGround, Kinsta, WP Engine, Bluehost) — toggle SSL off and back on in the hosting dashboard. These hosts manage the chain for you, and forcing a re-issue usually clears it within minutes.

Cause 2: Your Let's Encrypt certificate didn't renew

Let's Encrypt certificates are only valid for 90 days by design, specifically so renewal gets automated instead of forgotten (Let's Encrypt: why ninety-day lifetimes). If the renewal cron job or systemd timer silently broke — a common cause is a firewall change, a moved webroot, or a full disk — the old certificate simply expires and the browser correctly refuses it.

How to check:

sudo certbot certificates

This lists every certificate Certbot manages and its expiry date. If it's expired or marked "INVALID," that's your answer.

How to fix it:

Run a dry run first so you don't hit issuance rate limits: sudo certbot renew --dry-run
If that succeeds, renew for real: sudo certbot renew
Reload your web server: sudo systemctl reload nginx (or apache2)
Confirm the renewal timer is actually active: systemctl list-timers | grep certbot

On shared hosting you likely don't run Certbot yourself — the host does. Contact support or re-trigger the SSL section of your control panel; a stuck AutoSSL job is the shared-hosting equivalent of a broken cron job.

Cause 3: Wrong certificate for the domain (a related, easily confused error)

If you recently migrated hosts, added www, or moved to a new server, and the installed certificate doesn't actually list your current domain, Chrome shows NET::ERR_CERT_COMMON_NAME_INVALID — a sibling error, not the same one, but people search for them interchangeably. This is exactly the "connection not private after renewing hosting" scenario: the new host issued a certificate before DNS had fully pointed at it, or issued one for the wrong subdomain, and visitors end up seeing a certificate meant for a different server.

How to check: open your site in Chrome, click the "Not secure" warning, then "Certificate is not valid," and compare the domain names listed on the certificate to the domain in your address bar.

How to fix it:

Confirm DNS is fully propagated to the new host before re-issuing (dig yourdomain.com should return the new host's IP everywhere you check).
Re-issue the certificate explicitly for every hostname you serve, including both yourdomain.com and www.yourdomain.com if visitors reach both.
Check for a CAA DNS record blocking issuance — if one exists, it must explicitly allow your CA, e.g. yourdomain.com. CAA 0 issue "letsencrypt.org".

Cause 4: A leftover self-signed or staging certificate

If a developer, migration script, or a default Nginx/Apache install left a self-signed certificate active — or you tested with Let's Encrypt's staging environment and forgot to switch to production — the certificate is technically valid but issued by something no browser trusts. Re-issue a real production certificate and remove the placeholder; there's no configuration fix for a self-signed cert other than replacing it.

Quick diagnostic checklist

[ ] Run the openssl s_client command above — does the chain complete without errors?
[ ] Run sudo certbot certificates (or check your host's SSL panel) — is the certificate expired?
[ ] Open the certificate details in Chrome — does the "Issued to" domain match your actual domain?
[ ] Check the "Issued by" field — is it a real CA (Let's Encrypt, DigiCert, Sectigo) or does it show your own server name?
[ ] Check DNS with dig — does your domain currently point at the server you believe issued the certificate?

Symptom	Likely cause	Fastest fix
`Verify return code: 21` in openssl	Missing intermediate cert	Serve `fullchain.pem`, not `cert.pem`
Certificate expired today or recently	Failed Let's Encrypt renewal	`certbot renew`, check the systemd timer
Certificate lists a different domain	Wrong cert for new host/domain	Re-issue after DNS fully propagates
Issuer shows your own server name	Self-signed/staging leftover	Replace with a real production cert

After you fix it: confirm it actually worked

Don't just trust that your own browser stopped complaining — it may have cached the old certificate. Test from a clean environment with the Qualys SSL Labs test, which shows the full chain, expiry, and any remaining issues a browser would catch. It's free and doesn't require an account.

While you're checking your site's security setup, it's worth a broader pass — a missing intermediate certificate is exactly the kind of small, easy-to-miss configuration gap that tends to show up alongside other issues, like missing security headers. Our free website security headers checker flags those in about ten seconds, and our guide to spotting hackable configuration issues covers the other common gaps we see on small business sites.

Key takeaways

NET::ERR_CERT_AUTHORITY_INVALID means the browser can't verify who issued your certificate — check the chain, the expiry date, and the domain it was issued for, in that order.
A missing intermediate certificate is the single most common cause; make sure your server serves fullchain.pem (or the equivalent combined bundle), not the bare certificate.
Let's Encrypt certificates expire every 90 days on purpose — confirm certbot renew --dry-run actually succeeds and the renewal timer is running, rather than assuming it is.
After a host migration, re-issue the certificate only once DNS has fully propagated, and cover every hostname (www and non-www) your visitors actually use.
Verify the fix with an independent tool like SSL Labs, since your own browser may still be showing you a cached, broken certificate.

If you'd rather have a human double-check the whole setup — not just the certificate, but the configuration issues that tend to travel with it — a Circuit audit is a one-time $49 manual review of your entire site with a full written report, or run a free passive check first if you just want a quick yes/no on anything critical.

SOC 2 vs ISO 27001: Which Needs a Pentest?

Bug Circuit — Thu, 24 Sep 2026 13:40:15 +0000

Originally published on the Bug Circuit blog.

Neither SOC 2 nor ISO 27001 says the words "you must run a penetration test" anywhere in their official text — but in practice, almost every company that gets certified pays for one anyway.

This is for founders who've been told by a customer, investor, or sales prospect "we need your SOC 2" or "we need your ISO 27001 certificate" and are now trying to figure out whether a pentest is actually a line item on that checklist, and when to budget for it. You'll get a plain breakdown of what each framework's actual text requires, what auditors realistically expect anyway, and a timeline for when to book the test so it doesn't delay your audit.

The short answer

Framework	Does the written standard require a pentest?	Will your auditor expect one anyway?
SOC 2 (AICPA Trust Services Criteria)	No — it requires ongoing vulnerability monitoring and detection, not a named "penetration test"	Almost always yes, especially for Type II reports and any company handling customer data
ISO 27001:2022	No explicit mandate, but Annex A control 8.29 ("Security testing in development and acceptance") is hard to satisfy without one	Yes — certification bodies routinely ask for evidence of security testing, and pentesting is the standard way to show it

Both frameworks are risk-based and outcome-based, not checklists of specific tools. That's the root of the confusion: they describe an outcome ("know your vulnerabilities," "test your security controls") and leave the how up to you. A penetration test just happens to be the most common, most credible way to produce that evidence.

What SOC 2 actually requires

SOC 2 is built on the AICPA's Trust Services Criteria, organized around five categories: security, availability, processing integrity, confidentiality, and privacy. Every SOC 2 report covers the Security category at minimum.

Two criteria within the Common Criteria ("CC") series are the ones that pull pentesting into scope indirectly:

CC4.1 (Monitoring Activities) — the organization must evaluate whether its controls are actually operating as designed.
CC7.1 (System Operations) — the organization must identify vulnerabilities in its systems on an ongoing basis.

Neither criterion names a penetration test. You could, in theory, satisfy them with automated vulnerability scanning, code review, and bug bounty findings alone. But in practice, most SOC 2 auditors will flag the absence of an independent, human-led penetration test as a gap — particularly for a Type II report, which covers your controls operating over a 3–12 month window rather than a single point in time. If your customers send security questionnaires (most B2B SaaS buyers do), "do you conduct annual penetration testing?" is one of the first questions, and a SOC 2 report without one raises eyebrows during due diligence even if it technically passed.

What ISO 27001 actually requires

ISO 27001 works differently: it's a certifiable management-system standard, not an audit of specific criteria. You build an Information Security Management System (ISMS), run a risk assessment, and then justify which of the 93 Annex A controls apply to you in a document called the Statement of Applicability (SoA).

The control most directly relevant to pentesting is Annex A 8.29, "Security testing in development and acceptance" — introduced in the 2022 revision. It requires you to define and implement a security testing process for new and changed systems. Alongside it, Annex A 8.8, "Management of technical vulnerabilities," requires you to obtain timely information about technical vulnerabilities in the systems you use and respond appropriately.

You can mark a control "not applicable" in your SoA if you have a documented, risk-based justification. But if you run a website, a customer-facing app, or any internet-exposed infrastructure, excluding 8.29 is very difficult to defend to a certification body auditor — they'll ask what alternative evidence proves your software is tested for exploitable flaws before it ships. For almost every SaaS company, a penetration test (or at minimum a structured vulnerability assessment) becomes the practical answer.

Side-by-side comparison

Question	SOC 2	ISO 27001:2022
Explicit pentest requirement in the text?	No	No
Closest control(s)	CC4.1, CC7.1	Annex A 8.8, 8.29
Can you avoid it entirely?	Rarely — auditors treat it as standard evidence	Only with a strong, documented risk-based exclusion
Typical expected frequency	Annually (aligned to Type II audit period)	Annually, or after significant system changes
Who checks the evidence	Your SOC 2 auditor (CPA firm)	Your ISO 27001 certification body auditor
Report becomes audit evidence?	Yes — attach or reference the pentest report and remediation	Yes — cited as evidence for the relevant Annex A controls

When to actually book the test

Don't wait until your auditor asks. Pentest reports take time to schedule, execute, and remediate findings from — and a fresh critical vulnerability sitting unfixed in your report looks worse than not having tested at all.

8–12 weeks before your audit kickoff — book the test. Manual testers (not just automated scanners) often have multi-week queues.
4–6 weeks before kickoff — receive the report, triage findings by severity, and fix anything high or critical.
2 weeks before kickoff — have your remediation evidence (tickets closed, patches deployed, retest confirmation) ready to hand your auditor.
Ongoing — re-test annually, and again after any major architecture change, new product launch, or when a customer contractually requires it.

If you're unsure whether your current setup even has obvious holes before you spend money on a formal audit-grade pentest, a free passive security check is a reasonable first pass — it won't replace what your auditor needs, but it'll tell you if there's something urgent to fix first.

What auditors actually accept as "a pentest"

Not every scan qualifies. Auditors for both frameworks generally want to see:

A human-led test, not purely automated (see our breakdown of manual vs. automated penetration testing for why the distinction matters to auditors)
A dated, written report with findings, severity ratings, evidence, and remediation guidance
Proof that high/critical findings were remediated or formally risk-accepted
Testing scoped to production or production-equivalent systems, not just a staging sandbox
A tester independent from the team that built the system

Methodology matters too. Testers commonly reference the OWASP Web Security Testing Guide and NIST SP 800-115 as recognized frameworks for how a test should be structured — citing one of these in your report adds credibility during audit review.

If you're budgeting for the first time, our guide on how much a penetration test costs breaks down typical pricing so you're not caught off guard by enterprise pentest firm quotes that assume a much larger scope than a single web app.

Key takeaways

Neither SOC 2 nor ISO 27001 explicitly mandates a "penetration test" by name — both are risk-based standards that require evidence of vulnerability testing and monitoring.
SOC 2's CC4.1 and CC7.1, and ISO 27001's Annex A 8.8 and 8.29, are the controls that make a pentest the practical, expected answer for almost every company.
Book your pentest 8–12 weeks before your audit so you have time to fix findings before the auditor sees them.
Auditors want a human-led test with a written report and proof of remediation — automated scans alone usually aren't enough.
Retest annually and after major changes; a stale pentest report is nearly as bad as none.

If you're not sure where your site actually stands before you commit to a full compliance push, Bug Circuit's $49 Circuit audit gets a real person manually testing your site with a full written report of what's wrong and how to fix it — a solid, honest starting point before you book a formal compliance-grade pentest.

DIY Scanner vs Manual Security Audit: What You Get

Bug Circuit — Wed, 23 Sep 2026 07:40:27 +0000

Originally published on the Bug Circuit blog.

A free scanner is a great first move but it only reliably catches known, signature-based issues — missing security headers, outdated software versions, weak TLS config, exposed files — while a professional manual audit is built to catch what scanners structurally can't: broken authentication logic, access-control flaws, and chained vulnerabilities specific to how your site actually works.

Who this is for: you run a small business website — WordPress, Shopify, or a custom app — and you're trying to decide whether a free scan is "good enough" or whether you should pay for a human to look at it. What you'll get: an honest breakdown of exactly what each approach finds and misses, a comparison table, and a step-by-step way to run a solid free scan yourself before deciding if you need more.

How a DIY scanner actually works

Automated scanners work by sending your site a large list of known test cases and pattern-matching the response. A scanner like OWASP ZAP or a hosted tool checks things such as:

Which HTTP response headers are present (e.g., Content-Security-Policy, Strict-Transport-Security)
Whether your TLS/SSL certificate is valid and uses modern protocols
Whether your software (WordPress core, plugins, themes, server software) matches a known-vulnerable version listed in a public database like NVD
Whether common files are exposed (.env, wp-config.php.bak, .git/)
Basic injection patterns — appending things like ' or <script> to input fields and watching how the response changes

This is genuinely useful work. It's fast, free or cheap, and it catches the low-effort issues that make a site an easy opportunistic target. Run one before you do anything else.

Try it yourself right now

Check your response headers: curl -I https://yoursite.com, or use our security headers checker to see what's missing at a glance.
Check your TLS setup with Qualys SSL Labs — aim for grade A.
Check whether your email domain can be spoofed with our email spoofing checker. You want a valid SPF record like v=spf1 include:_spf.google.com ~all and a DMARC record such as v=DMARC1; p=quarantine; rua=mailto:you@yoursite.com.
Comfortable with a terminal? Run a baseline OWASP ZAP scan: docker run -t zaproxy/zap-stable zap-baseline.py -t https://yoursite.com.
For a free, no-cost recurring scan, CISA runs a scanning service for organizations — details at CISA Cyber Hygiene Services.

What scanners structurally can't see

This is the part that matters most when you're asking whether a free scanner is enough. Scanners test patterns, not intent — they have no idea what your site is supposed to do, so they can't tell when it's doing something it shouldn't. OWASP's own testing guidance is explicit that this category, business logic flaws, generally can't be found by automated tools because each one is specific to how a particular application works (see the OWASP Web Security Testing Guide).

Concretely, an automated scanner will almost never catch:

Broken access control — e.g., changing /account?id=1042 to /account?id=1043 in the URL and viewing someone else's order or invoice. This is the #1 category in the OWASP Top 10.
Authentication logic flaws — a password reset token that never expires, or that leaks in a Referer header to a third-party script.
Privilege escalation through legitimate features — a "team member" role that can, through some multi-step form, quietly grant itself admin access.
Chained vulnerabilities — three individually low-severity issues that combine into a full account takeover.
Context-specific data exposure — an API endpoint that returns more fields than the page displays, including ones a scraper or competitor would want.
Payment or discount logic abuse — applying a coupon code twice, or editing a price field in the browser before checkout.

None of these trip a signature. They require a person who understands your specific site to think like an attacker and actually try to break the logic, not just scan the code.

Side-by-side: what each approach actually delivers

	Free/DIY scanner	Manual audit (e.g., Circuit, $49)
Missing security headers	Yes	Yes
Outdated software / known CVEs	Yes	Yes
Weak TLS/SSL configuration	Yes	Yes
Exposed config or backup files	Yes	Yes
Broken access control (viewing others' data)	Rarely	Yes
Authentication/session logic flaws	Rarely	Yes
Business logic abuse (pricing, coupons, roles)	No	Yes
Chained, multi-step exploit paths	No	Yes
False positives to sort through yourself	Often, several	Verified by a human first
Fix instructions	Often generic	Specific to your site, with evidence
Time to results	15–60 minutes, self-serve	You wait for the write-up
Typical cost	Free to ~$50/month for tools	$49 one-time

Is a free vulnerability scanner enough?

For a lot of very small, low-stakes sites — a brochure site with no login, no payments, no stored customer data — a good free scan plus fixing what it finds is genuinely enough. It'll catch the missing headers, the outdated plugin, and the weak TLS setting, which covers most of the realistic risk for that kind of site.

It stops being enough the moment your site has a login, stores customer data, takes payments, or has more than one user role — customer vs. admin, free vs. paid tier, and so on. That's exactly the point where the vulnerabilities that matter most — the ones that lead to an actual data breach rather than a cosmetic defacement — are the logic flaws a scanner structurally can't see. Our guide on manual vs. automated penetration testing goes deeper into where that line sits for different types of sites.

A realistic workflow, not a competition

Run a free scan first — headers, TLS, known CVEs, exposed files — and fix everything it flags. This is cheap, fast, and removes the low-hanging fruit an opportunistic attacker is scanning the whole internet for.
If your site only serves static content with no accounts, you're probably done for now. Re-scan every few months or after major changes.
If your site has logins, payments, customer data, or multiple user roles, get a human to look at the logic — that's the gap scanners can't close. A free passive check will also give you a quick yes/no read on whether anything critical is visible before you decide to pay for anything.
Not sure which category you're in? Our guide is my website hackable? walks through the questions to ask.

What a $49 manual audit actually includes

Scope matters for trust here. A $49 productized audit like Circuit is a real person manually reviewing your site's attack surface, authentication flows, and common business-logic paths, then handing you a written report — each finding with severity, evidence, and the exact fix. It is not a multi-week enterprise penetration test, and it is not a compliance certification (SOC 2, PCI-DSS, and ISO 27001 audits are separate, much longer engagements). For a small WordPress site, Shopify store, or indie SaaS, it's scoped to catch what actually threatens a business your size: account takeover, data leakage, and the issues a free scanner already surfaced but couldn't confirm were real.

Key takeaways

Run a free scanner first — it cheaply catches missing headers, outdated software, weak TLS, and exposed files.
Scanners test known patterns; they can't evaluate whether your site's specific logic — access control, auth, pricing, roles — can be abused.
If your site has no login, no payments, and no customer data, a good free scan is likely enough on its own.
The moment accounts, payments, or user roles exist, get a human to test the logic, since that's where real breaches happen.
Treat scanning and auditing as sequential, not competing: scan first, fix what it finds, then get a manual review for anything that handles real user data.

Run the free tools above yourself today — they cost nothing. If your site has logins or customer data and you want someone to actually try to break in the way an attacker would, Circuit is a $49 one-time manual audit from a real person, with a full written report — no card required to start with the free passive check first.

Internal vs External Pentest: Which You Need

Bug Circuit — Mon, 21 Sep 2026 14:28:04 +0000

Originally published on the Bug Circuit blog.

If you run a public-facing website with no private employee network to protect, you need an external penetration test — not an internal one. Internal pentesting is a different product for a different problem: it tests what happens if someone already has a foot inside your office network. Most small businesses selling online, running a SaaS app, or taking bookings through a website don't have that problem to solve, or don't have it yet.

Who this is for: owners of a website, online store, or small SaaS app who got a quote (or saw a menu) listing "internal" and "external" pentesting as separate line items and aren't sure which applies to them. What you'll get: a plain-English breakdown of the difference, a way to tell which one a vendor is actually selling you, and a clear answer for whether your website needs internal testing at all.

Internal vs External Penetration Testing: The Core Difference

The words "internal" and "external" describe the attacker's starting point, not the size or seriousness of the test.

External penetration testing simulates an attacker on the public internet who has no special access — no login, no VPN, no badge. They can only reach what's exposed to the world: your website, your login pages, your DNS records, your mail server, your open ports. This is what NIST's Technical Guide to Information Security Testing and Assessment (SP 800-115) calls testing from an "external" perspective — outside the organization's network perimeter.
Internal penetration testing simulates an attacker who is already inside — a malicious employee, a contractor with VPN access, or someone who successfully phished a staff laptop. The test starts on your internal network and asks: once someone is in, how far can they get? Can they reach the file server, the domain controller, the finance database?

Here's the distinction in one table:

	External Pentest	Internal Pentest
Attacker's starting point	Public internet, zero access	Already on your internal network
What it tests	Website, login forms, APIs, DNS, exposed ports, email spoofing	Employee workstations, internal servers, file shares, Active Directory
Who typically needs it	Anyone with a public website or web app	Companies with an office network, internal servers, or many employee devices
Common trigger	"Is my website hackable?"	A vendor security questionnaire, cyber insurance renewal, or compliance audit (SOC 2, ISO 27001)
Does a small business site need it?	Yes — this is the relevant test	Only if there's an internal network worth attacking

If You Just Have a Website, You Need External Testing

If your business is a WordPress site, a Shopify store, or a small SaaS app, the entire attack surface a stranger can reach is external by definition. There's no internal network for a random attacker to "already be inside" — the front door is the website.

An external test covers the things that actually get small sites hacked:

Authentication and login flows — weak password policies, missing rate limiting, exposed admin panels (/wp-admin, /wp-login.php).
Input handling — SQL injection, cross-site scripting (XSS), and other flaws in forms, search bars, and URL parameters. OWASP's Top 10 tracks these as the most common web app risks year after year.
Outdated software and plugins — old CMS versions, abandoned plugins with known CVEs.
Server and DNS exposure — open ports, misconfigured TLS, missing security headers (you can check yours for free with a security headers scanner).
Email spoofing risk — missing or weak SPF, DKIM, and DMARC records that let attackers send phishing email that looks like it's from your domain (check with an email spoofing checker).
Business logic flaws — things automated scanners miss, like a checkout that lets you apply the same discount code twice, or an account page that leaks another customer's data by changing a number in the URL.

That last category is exactly why a manual, human-led external test finds things a scanner-only "pentest" doesn't. See our breakdown of manual vs. automated penetration testing if you want the full comparison.

When Internal Pentesting Actually Applies

Internal testing earns its keep when there's real internal infrastructure to attack — not just a website. You likely need it if:

You run an office network with shared file servers, an internal wiki, or a domain controller (Active Directory).
Staff use VPN access to reach internal systems from home.
A customer's security questionnaire or vendor risk assessment specifically asks for internal testing evidence.
You're pursuing SOC 2, ISO 27001, or a similar compliance framework that scopes both internal and external testing.
You've had — or are worried about — an insider threat or a compromised employee device spreading further than it should.

CISA's guidance on choosing a penetration testing vendor is written for organizations sophisticated enough to be scoping both internal and external engagements together — that's usually a mid-size or larger company with IT infrastructure beyond a website, not a five-person shop running a Shopify store.

A Quick Way to Tell Which One You're Being Sold

Before you buy anything labeled "penetration test," ask the vendor these questions:

[ ] Where does testing start? From the public internet with no credentials (external) or from inside your network / VPN (internal)?
[ ] What's in scope? Just the website and domain, or also office Wi-Fi, employee laptops, and internal servers?
[ ] Is it manual or automated? A scan report alone isn't a pentest — a real pentest involves a person actively trying to break in and confirming what's exploitable.
[ ] Do you get a fix, or just a list? Some services stop at the report; others help you patch what's found.
[ ] Does the scope match what you actually have? If you don't have an internal network beyond a home Wi-Fi router and a laptop, paying for internal testing is paying to test nothing.

If a vendor can't answer the "where does testing start" question clearly, that's a sign the quote is generic and not scoped to your actual setup. For a broader gut-check on whether you even need testing right now, our guide on figuring out if your website is hackable walks through the warning signs.

What This Costs, and What "Manual" Actually Means

Pricing for external website testing varies a lot depending on whether it's automated-only or genuinely human-led — we cover the range in how much a penetration test costs. As a rough anchor: a productized manual audit of a small site runs well under what a scoped enterprise-style engagement (internal + external, multi-week) costs, because the attack surface is smaller and the engagement is standardized rather than custom-scoped.

At Bug Circuit, Circuit ($49, one-time) is exactly this: a human security engineer manually audits your public-facing site — external testing — and hands you a written report with severity ratings, evidence, and exact fixes for each issue. Signal ($299 / 3 months) adds the same audit plus we fix the high and critical issues ourselves, with three months of continued coverage. Neither product tests internal office networks — because for a website-only business, that's not the attack surface that matters.

If you're not sure where you stand, you can start with a free passive website security check — no card, no login required — which gives you a yes/no on whether anything critical is visible from the outside before you decide on a paid audit.

Key takeaways

External pentesting simulates an outside attacker with no access, testing your website, login pages, DNS, and email configuration — this is what almost every small business with a public site actually needs.
Internal pentesting simulates an attacker already inside your network, and only matters if you have real internal infrastructure — office servers, VPN access, Active Directory — beyond the website itself.
If a quote bundles both without asking what internal infrastructure you actually run, you may be paying for a test of something that doesn't exist.
A manual (human-led) external audit catches business-logic and access-control flaws that automated scanners routinely miss.
Start with a free passive check to see where you stand, then get a full manual audit if anything looks off.

If you've read this far because you're weighing whether to spend money on this at all: a $49 manual audit of your public-facing site is a low-risk way to find out exactly what's exposed, in writing, from a real person — no guessing, no upsell required.

Is My WordPress Site Hacked? Diagnostic Checklist

Bug Circuit — Wed, 16 Sep 2026 02:29:44 +0000

Originally published on the Bug Circuit blog.

If your site is throwing sudden errors, redirecting visitors, flagged by Google, or has a login you don't recognize, treat it as hacked until you rule each sign out below — this checklist tells you exactly where to look and which symptoms are near-certain versus just a false alarm.

This is for WordPress owners — store owners, bloggers, agencies managing client sites — who noticed something off and want a fast, concrete way to check for compromise, not a 40-page guide. You'll get a scannable checklist, the exact place to check each symptom, and what to do the moment you confirm one. If you'd rather have a person look instead of second-guessing your own site, the free website security check gives you a straight yes/no on critical bugs with no card and no login.

The 60-second checklist

Run down this table first. "Critical" means stop and act now; "worth checking" means it's a common false-alarm trigger too, so verify before you panic.

Symptom	What it usually means	Urgency
Chrome/Google shows "Deceptive site ahead" or "This site may harm your computer"	Google Safe Browsing flagged live malware or phishing code on your pages	Critical
Random pages ranking in Google you never wrote (e.g. pharmacy or replica-goods spam)	SEO spam injected into a compromised plugin, theme, or database table	Critical
Visitors get redirected to a casino, pharmacy, or ad domain	Malicious redirect in `.htaccess`, `functions.php`, or a rogue plugin	Critical
Sudden HTTP 500, 502, or 503 errors with no code changes on your end	Corrupted core files, a runaway cron script, or database injection	Worth checking
An Administrator account in Users you didn't create	Attacker planted a persistent backdoor login	Critical
Login redirects elsewhere, or `wp-login.php` behaves strangely	Core files or `.htaccess` tampered with	Critical
Customers report spam email that looks like it's from your domain	Site is being used as a spam relay via `wp_mail()`	Worth checking
CPU/bandwidth spikes with no matching rise in real visitors	Site running cryptomining, a botnet node, or a spam/DDoS script	Worth checking
Unfamiliar `.php` files inside `wp-content/uploads`	An uploaded web shell — a script giving remote file/command access	Critical
Your host emails you about "malware detected" or suspends the account	Their scanner matched a known malicious signature	Critical

Sudden 500/502/503 errors — don't assume the worst yet

A wave of server errors is the symptom most likely to have an innocent cause: an auto-update conflict, a PHP memory limit, or an expired SSL cert can all produce a 500. Before treating it as a hack, check wp-content/debug.log or your host's error log (cPanel → Metrics → Errors, or your hosting dashboard's log viewer).

What separates a bug from a break-in:

Plugin/config error — the log names a real file inside a known plugin folder, e.g. "Allowed memory size exhausted in .../woocommerce/includes/...". Ordinary bug.
Compromise — the log references a file you don't recognize, especially inside wp-content/uploads/ (which should never contain executable PHP) or a random string like wp-content/plugins/wp-tmp-cache/x942.php.

If you have WP-CLI access, compare your files against official checksums:

wp core verify-checksums
wp plugin verify-checksums --all

Any "file doesn't match" result on a file you didn't edit is a strong signal — that's exactly the check a manual audit runs by hand, cross-referenced against what the plugin should contain rather than just a checksum mismatch.

Google Safe Browsing and search warnings

Google, Chrome, Firefox, and Safari all share data from Google Safe Browsing, which scans public sites for malware and phishing code and warns visitors before they land on a flagged page. If your own browser (in incognito, with no cached override) shows a red warning screen, or a customer reports seeing one, your site is very likely serving malicious code right now — not just a possibility.

To check without waiting for a customer complaint:

Go to the Safe Browsing site status page and enter your domain.
Check Google Search Console → Security Issues — Google lists exactly which pages it flagged and why (e.g. "hacked with spam content" vs "malware").
Search site:yourdomain.com in Google and look for page titles you never wrote (Japanese/Russian spam-keyword titles are a classic signature of a hacked WordPress site).

Unauthorized admin accounts and logins

This is the single clearest sign on this list — WordPress doesn't create Administrator accounts on its own, ever.

In Users → All Users, sort by role and check every Administrator by name, email, and registration date.
Via WP-CLI: wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
If you're locked out or don't trust the dashboard, check the wp_users table directly in phpMyAdmin — look for accounts with a user_registered date you don't recognize.

A single account you didn't create is enough to confirm compromise on its own, since it means someone already has standing access to your site.

Unfamiliar or duplicated cron jobs

WordPress runs its own pseudo-cron (wp-cron.php) separately from any real server crontab, and attackers use both to keep a backdoor alive after you think you've cleaned up.

List WordPress's own scheduled events: wp cron event list --fields=hook,next_run,schedule. A hook name that isn't tied to any plugin you installed (random class-style names, not woocommerce_cleanup_sessions-style ones) is worth investigating.
Check the real server crontab via SSH (crontab -l) or your host's Cron Jobs panel. Anything that pipes to curl, wget, or php -r with a base64-looking string as the argument is a red flag, not a maintenance task.

Unexpected outbound traffic

A hacked site often "phones home" — sending spam email, connecting to a command-and-control server, or joining a botnet — which shows up as outbound traffic you didn't generate.

Compare your hosting bandwidth graph against your actual visitor count in analytics; a spike in outbound data with flat visitor traffic is the tell, not a spike in both.
On a VPS with shell access, ss -tnp or netstat -tnp lists active outbound connections; match the process ID back to a PHP worker connecting to an IP address that has nothing to do with your site's normal services (payment gateway, CDN, email provider).
If your host's abuse team emails you about outbound spam volume or a blocked IP, that's third-party confirmation, not a guess.

What to do the moment you confirm a sign

Change every password — WordPress admin, hosting account, FTP/SFTP, and the database user — from a device you trust, before doing anything else.
Put the site in maintenance mode or take it offline temporarily if it's actively redirecting visitors or serving malware.
Don't just delete the suspicious file and call it fixed. A single backdoor is rarely the only one; CISA's guidance on web shell malware notes that attackers commonly leave multiple redundant footholds once they've gained access.
Restore from a backup that predates the first symptom, if you have one, then patch whatever let the attacker in before putting it back online.
Get a second set of eyes. Automated scanners are good at catching known signatures but miss custom-coded backdoors and logic-based abuse; that gap is exactly why manual review finds things automated scans don't.

If you're still not sure after running through this list, our guide to telling whether a website is hackable in the first place covers the underlying weaknesses (outdated plugins, weak passwords, missing headers) worth checking regardless of whether you've been breached yet.

Key takeaways

A Google Safe Browsing warning or an admin account you didn't create is confirmation on its own — act immediately, don't wait for a second sign.
Sudden 500/502/503 errors are the most commonly misread symptom; check the error log for unfamiliar filenames before assuming a hack.
Check both WordPress's own cron (wp cron event list) and the real server crontab (crontab -l) — attackers use both to persist.
Outbound traffic spikes without matching visitor spikes are a stronger signal than raw bandwidth numbers alone.
Deleting one suspicious file isn't a fix — confirm the full extent before declaring the site clean.

If you've ticked even one "Critical" box above, the honest next step is a human looking at the actual code, not another automated scan. Circuit is a $49 one-time manual audit — a real person reviews your site and hands you a written report of every issue found, with severity and the exact fix, so you know precisely what an attacker did and what to close. There's no pressure to buy anything if the free check comes back clean.

Wix Security Checklist for Small Business Owners

Bug Circuit — Sun, 13 Sep 2026 20:28:46 +0000

Originally published on the Bug Circuit blog.

Wix's platform is genuinely secure on the back end — but "Wix is secure" and "my Wix site is secure" are two different claims, and the gap between them is entirely your responsibility. Wix patches servers, issues free SSL certificates, and runs a PCI-compliant payment system. It does not stop someone from guessing your password, does not vet every app you install from the App Market, and does not decide how much customer data your contact form quietly collects.

Who this is for: you run a small business, agency, or side project on Wix and you've never done a real security pass on it. What you'll get: a plain checklist of exactly what Wix already covers, what's on you, and the settings to check today — no code required.

What Wix Handles vs. What You Handle

Wix is a fully hosted (SaaS) platform, which means you never touch a server — Wix's own team owns patching, uptime, and infrastructure defense. That's a real advantage over self-hosted WordPress, where the site owner is on the hook for every plugin update. But "hosted" only covers the plumbing, not what you build on top of it.

Security area	Handled by Wix	Handled by you
Server patching & OS security	✅	—
SSL/TLS certificate (HTTPS)	✅ Auto-issued and renewed	—
DDoS protection & network infrastructure	✅	—
Payment processing (if using Wix Payments)	✅ PCI-compliant	—
Account password strength	—	✅
Two-factor authentication (2FA)	Available, opt-in	✅ You must turn it on
Who has editor/admin access	—	✅
Third-party apps you install	Wix reviews apps at listing, not their ongoing behavior	✅ You choose and audit them
What your forms collect and where it goes	—	✅
Embedded scripts (chat widgets, trackers, ads)	—	✅
Custom domain email security (SPF/DKIM/DMARC)	—	✅

Wix documents its platform-level commitments in its Trust Center — worth a five-minute read if you want the vendor's own claims, not just this checklist.

The Wix Security Checklist

Work down this list once, then revisit it every few months or whenever staff changes.

Turn on two-step verification. On wix.com, go to your account profile (top-right icon) → Settings → Security, and enable two-step verification. This is the single highest-impact change you can make — CISA recommends multi-factor authentication as one of the most effective defenses against account takeover, because it stops a stolen or guessed password from being enough on its own.
Use a unique password, not a memorized one. Reused passwords are the number one reason small-business accounts get taken over — one breach at an unrelated site hands over your Wix login too. Use a password manager to generate and store a unique one. NIST's password guidance actually recommends long, unique passphrases over the old "8 characters, one symbol, one number" rule — length and uniqueness beat complexity.
Audit who has access. Go to Dashboard → Settings → Roles & Permissions and review every collaborator. Remove former employees, freelancers, and agencies you no longer work with. Each person with editor access is a password that can be phished.
Review every installed app. Go to Dashboard → Apps → Manage Apps. For each one, ask: do we still use this, and what data does it request access to (site content, contacts, orders)? Delete anything unused — an abandoned app is still a live door into your site's data.
Check your forms for data you don't need. Open Dashboard → Contacts and each Forms submission setting. If you're collecting phone numbers, addresses, or IDs you don't actually use, remove those fields. Less collected data means less to leak if anything ever does go wrong.
Know where form submissions actually go. Wix Forms can email submissions, store them in Contacts, or both. Make sure whoever's inbox receives them isn't a shared/legacy account nobody checks or secures.
Set up account recovery correctly. Confirm the recovery email and phone number on your Wix account are current — if you're ever locked out or need to prove account ownership after a compromise, this is how you get back in.
Know how to use Site History. In the Wix Editor, the History icon lets you roll back to a previous saved version. If a page ever gets defaced or an app makes an unwanted change, this is your undo button — know where it is before you need it.
If you use a custom domain for email, check your DNS records. SPF, DKIM, and DMARC records stop attackers from sending phishing emails that look like they're from your domain. Run your domain through Bug Circuit's free email spoofing checker to see if these are set up correctly.
Review embedded third-party scripts. Chat widgets, ad pixels, and analytics tools you've pasted into your site's custom code (Dashboard → Settings → Custom Code) can read page data and, in some cases, form input. Remove any you no longer actively use — this mirrors the general risk OWASP flags around vulnerable and outdated third-party components: code you didn't write is still code you're responsible for.
Turn on notifications for account changes. Wix can alert you by email when your password or account details change — make sure that email actually reaches someone who'll notice.
Check what your site sends to browsers. Even on a hosted platform, you can inspect your live site's response headers with a tool like Bug Circuit's security headers checker to understand your baseline — useful context if you ever add custom code or a headless setup on top of Wix.

The Overlooked Risk: Third-Party Apps

Most Wix compromises small business owners run into don't come from Wix's core platform being broken — they come from what's installed on top of it. The Wix App Market reviews apps before listing them, but an app's behavior after installation (what it does with the data it can access, whether its own backend gets breached later) isn't something Wix continuously polices for you.

Treat every app install like handing someone a key: ask what it needs access to, whether you still use it, and whether the developer is still actively maintaining it. If an app hasn't been updated in over a year and you don't remember installing it, remove it.

Is Wix Secure Enough for My Business?

For most small businesses — a services site, a local shop, a simple online store — yes, Wix's infrastructure is a reasonable, well-maintained foundation. You're not managing a server, and you're not the one responsible for patching a zero-day in the platform's core code.

Where it gets more nuanced is scale and sensitivity: if you're collecting health information, processing large volumes of payment data outside Wix Payments, or need to answer a client's security questionnaire with specifics, "we use Wix" isn't a complete answer — you'll also need to show your side of the checklist above is handled. Our guide on manual vs. automated penetration testing explains the difference if a client or partner is asking for proof.

Signs Your Wix Site May Already Be Compromised

Wix's own protections mean full server compromise is rare, but account-level compromise still happens. Watch for:

Pages, products, or blog posts you didn't create
Apps installed that no one on your team recognizes
Customers reporting spam or phishing emails that look like they're from your domain
Unexpected redirects when visitors land on your site
A password reset email you didn't request

If you see any of these, change your password immediately, turn on 2FA if it isn't already on, and check our guide on what to do if your website's been hacked. If you're unsure whether something you're seeing is actually a problem, our free website security check gives you a fast yes/no on critical issues, no card required.

Key Takeaways

Wix secures the infrastructure (servers, SSL, DDoS, payments); you're still responsible for passwords, access, apps, forms, and embedded scripts.
Turning on two-step verification is the single highest-impact five-minute fix available to you.
Audit installed apps and collaborator access at least twice a year — remove what you don't actively use.
Minimize what your forms collect, and confirm where submissions actually go.
"Wix is secure" isn't the same claim as "my Wix site is configured securely" — this checklist closes that gap.

Running this checklist yourself covers the basics well. If you want a second set of eyes — someone who actually clicks through your app list, tests your forms, and checks your public-facing configuration the way an attacker would — that's exactly what a $49 manual audit from Bug Circuit does: a real person reviews your site and hands you a written report with fixes, not just a scan.

Scanner Found a Vulnerable Plugin? Do This Next

Bug Circuit — Fri, 11 Sep 2026 23:13:16 +0000

Originally published on the Bug Circuit blog.

If a scanner like WPScan or Wordfence just flagged a plugin, don't panic and don't touch anything yet — first confirm the version and CVE actually match your site, check whether that specific flaw is being exploited in the wild, then patch or deactivate based on severity, in that order.

This is for site owners who ran (or received) an automated scan that named a specific vulnerable plugin and now have three questions at once: is this real, is someone already inside, and what do I fix first? You'll get a step-by-step triage process, a priority table, and a way to tell a genuine emergency from scanner noise — no jargon, no scare tactics.

What the alert actually means

WPScan and Wordfence both work the same basic way: they read your site's visible plugin list and version numbers, then check that against a database of known, publicly disclosed vulnerabilities — things like the WPScan Vulnerability Database or the CVE records in the NVD (National Vulnerability Database). If your plugin's version matches a version range with a known flaw, you get a red flag.

That's it. The scanner hasn't checked whether anyone has actually tried to exploit it on your site, whether the vulnerable code path is even reachable in your configuration, or whether you already patched it manually without bumping the version number. It's a match against a list — a strong signal worth acting on, but not proof of compromise.

Step 1: Confirm the version is actually current

Before anything else, verify the scanner is looking at your real, live version.

In WordPress, go to Plugins > Installed Plugins and note the exact version number next to the flagged plugin.
Open the plugin's page on WordPress.org (or the vendor's site) and check the Changelog tab for the version where the fix landed.
Compare: if your installed version is equal to or newer than the fixed version, this is likely a false positive — the scanner's database may be a day or two behind, or it misread a cached/staging copy.
If your version is older than the fix, the flag is real and you're genuinely running vulnerable code.

If you use a staging site or a caching layer that serves an old copy of readme.txt, scanners sometimes read stale version strings from there too — check the live production files, not a cache.

Step 2: Check if this specific bug is being actively exploited

This is the step most people skip, and it's the one that actually tells you how urgent this is.

Look up the CVE ID the scanner gave you (something like CVE-2024-XXXXX) on the NVD and read the vulnerability type: SQL injection and remote code execution are far more dangerous than a low-severity information disclosure or a bug that requires admin-level access to trigger.
Check CISA's Known Exploited Vulnerabilities (KEV) catalog — cisa.gov/known-exploited-vulnerabilities-catalog. If your CVE is listed there, it means it's confirmed being used in real attacks right now, not just theoretically exploitable.
Search the plugin name + "exploit" or "in the wild" on a security news source like Wordfence's own threat intelligence blog or Sucuri's blog — they publish write-ups when a WordPress plugin flaw is actively being mass-scanned.
Check your own access logs for requests hitting the plugin's file paths (e.g. /wp-content/plugins/plugin-name/) with unusual parameters, especially POST requests you didn't make. Your host's control panel usually has a raw access log viewer, or ask support for the last 7 days of logs.

If the CVE requires "authenticated admin access" to exploit and you're the only admin with a strong, unique password, your real-world risk right now is much lower than a CVE that any anonymous visitor can trigger.

Step 3: Decide what to do, in order

Once you know the severity and exploit status, act in this order — don't skip straight to deleting things.

If a patched version exists: update the plugin immediately. This fixes the overwhelming majority of these alerts.
If no patch exists yet and the flaw is severe (RCE, SQLi, auth bypass): deactivate the plugin until a fix ships. A deactivated plugin's vulnerable code doesn't run.
If the plugin is abandoned (no update in 2+ years, removed from the WordPress.org directory): replace it with an actively maintained alternative that covers the same feature — don't wait for a patch that isn't coming.
If it's low severity and unexploited (e.g., a minor XSS needing a rare, non-default setting): schedule the update in your normal maintenance window rather than treating it as a fire drill.
Either way, check for signs of prior compromise before you consider the matter closed — a patch fixes the door, not anything that already walked through it. Look for unfamiliar admin users, new files in wp-content/uploads with .php extensions, and unexpected scheduled tasks (WP-Cron entries) you didn't create.

Triage priority: what to fix first

Situation	Priority	Action
Patch available, no signs of exploitation	High, but routine	Update now, monitor for 48 hours
No patch yet, listed in CISA KEV or "actively exploited"	Critical	Deactivate plugin immediately, update the moment a fix ships
No patch yet, low severity, requires admin access	Low-medium	Restrict admin accounts, update on next release
Plugin abandoned / removed from directory	High (long-term risk)	Replace plugin now, don't wait
You see unfamiliar admin users or unknown PHP files already	Emergency	Stop triage — this is likely a live incident

That last row matters: if you find evidence the site is already compromised, this stops being a "which vulnerability do I patch first" question and becomes incident response. Our guide on what to do when your website's been hacked walks through containment and cleanup in that scenario.

Is this a false positive? A quick gut-check

Run through this checklist before assuming the worst:

[ ] Installed plugin version is older than the changelog's "fixed in" version
[ ] The vulnerability type actually applies to how you use the plugin (e.g., a flaw in a contact-form add-on you never enabled doesn't apply to you)
[ ] The scanner ran against your live site, not a stale cache or staging copy
[ ] You've cross-checked the CVE on the NVD and it matches your plugin name and version range exactly (some scanners mismatch similarly-named plugins)
[ ] The exploit requires a role or setting you don't have (e.g., "requires contributor-level access" on a site where only you and one trusted editor have accounts)

If several of these are true, it's reasonable to treat this as low urgency rather than an emergency — but still fix it during normal maintenance rather than ignoring it indefinitely.

Why automated scanners can't give you the full picture

Automated tools are genuinely useful for exactly what they do: catching known, published CVEs by matching version numbers. What they can't do is confirm whether the vulnerable code path is actually reachable on your specific setup, whether your site has already been probed or compromised through it, or whether a different, undisclosed issue exists that no database has caught yet. The OWASP Top 10 explicitly separates "known vulnerable components" from the broader picture of exploitable weaknesses — a scanner covers one slice of that list.

That's the real difference between an automated scan and a manual review: a person can look at your actual site, confirm exploitability instead of guessing from a version string, and check the rest of the site the scanner didn't touch. Our breakdown of manual vs. automated penetration testing covers where each approach falls short. If you want a free starting point before paying for anything, our free website security check and security headers checker will tell you where else you're exposed at no cost.

Key takeaways

A scanner flag is a version match, not proof you've been hacked — confirm your installed version against the plugin's changelog before reacting.
Check the CVE on the NVD and cross-reference CISA's KEV catalog to see if it's actively exploited, not just theoretically possible.
Update first if a patch exists; deactivate immediately only for severe, unpatched, actively-exploited flaws.
Always check for signs of prior compromise (new admin users, unfamiliar PHP files, odd cron jobs) — patching doesn't undo an existing breach.
If you're unsure whether you're reading the report correctly, or the site handles customer data or logins, a second set of human eyes is worth it before you decide "false positive" on your own.

If you want that second set of eyes, Circuit is a $49 one-time manual audit — a real person confirms whether this specific finding (and anything the scanner missed) is actually exploitable on your site, with exact fixes. No subscription, no upsell pressure — just a straight answer on whether you need to act today or can relax.

WordPress Backup Strategy Before Disaster Strikes

Bug Circuit — Thu, 10 Sep 2026 17:13:48 +0000

Originally published on the Bug Circuit blog.

Back up your WordPress site automatically at least once a day (hourly or real-time if you take orders or leads), store copies offsite in at least two separate places, and actually test a restore every few months — a backup you've never restored isn't a backup, it's a guess.

This is for small business owners and site admins running WordPress — a shop, a blog, a local service site, an agency's client sites — who don't have an IT department and want a backup routine that will genuinely save them the day something goes wrong. You'll get a realistic cadence by site type, the "3-2-1" rule explained in plain terms, a short plugin comparison, and the exact steps for a disaster-recovery test you can run this month.

How often should you back up your WordPress site?

The honest answer is "it depends on how much you'd lose if today's backup were the last one you ever had." Work backward from that.

Site type	Backup frequency	Keep how long
Static/brochure site, rarely edited	Weekly	4 weeks
Blog or content site, posting regularly	Daily	30 days
WooCommerce store, bookings, or lead-gen forms	Real-time or hourly	30–90 days, plus a few monthly archives
Site under active development	Before every deploy, plus daily	Keep at least the last 5 releases

If you can't answer "what changed on my site since the last backup?" without checking, you're backing up too rarely. For a store taking orders all day, losing 24 hours of data means losing 24 hours of orders and customer records — that's the real cost, not an abstraction.

Do I need offsite backups?

Yes — a backup stored only on the same server as your live site isn't a real backup. If your host has an outage, your hosting account gets suspended, or an attacker gets into your WordPress admin, a local backup sitting in the same environment can be deleted, encrypted, or corrupted right along with everything else.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) makes this explicit in its ransomware guidance: organizations should "maintain offline, encrypted backups of data and regularly test your backups," specifically because attackers who get administrative access will look for and destroy backups they can reach (CISA #StopRansomware Guide). WordPress.org's own backup documentation makes the same point for site owners specifically — backups should live somewhere separate from the hosting account they protect (WordPress.org: WordPress Backups).

"Offsite" in practice means cloud storage that isn't tied to your hosting login — Dropbox, Google Drive, Amazon S3, or a backup service's own storage. Most backup plugins can push there automatically, so this isn't a manual chore once it's set up correctly.

The 3-2-1 rule, adapted for WordPress

CISA's data backup guidance popularized the 3-2-1 rule, and it maps cleanly onto a WordPress site:

3 copies of your data — the live site, plus at least two backups.
2 different storage types or locations — e.g., your host's built-in backup and a separate cloud storage account.
1 copy offsite — physically and logically separate from your hosting account, so a compromised host or hosting login can't take it out too.

For most small WordPress sites, a workable version looks like: your host's daily snapshot (convenient, fast to restore, but tied to your hosting account) + a backup plugin pushing a second copy to Dropbox or S3 on its own schedule, using its own login credentials.

Building a disaster recovery plan for a small WordPress business

A "disaster recovery plan" sounds like something only enterprises need, but for a small site it can be one page. NIST's contingency planning guidance frames it as answering four questions before you need the answers under pressure (NIST SP 800-34: Contingency Planning Guide):

What are we protecting? List the site's database, uploads/media folder, theme, plugins, and any files outside the CMS (invoices, exported leads, custom scripts).
Where do backups live, and who can reach them? Write down the storage location and who has the login — not just "the plugin handles it."
Who restores it, and how? Name a person (even if it's just you) and write the restore steps, including your host's support phone number or chat link.
How long can the site be down, and how much data can you afford to lose? These are two different numbers — recovery time and recovery point — and they should drive your backup frequency from the table above.

Put this on a single page in a shared doc. If you ever get hacked, you will not want to be researching your own backup setup while the site is down — check out this walkthrough on what actually happens (and what it costs) when a website gets hacked for a sense of how fast that clock runs.

What a real disaster-recovery test looks like

A backup file sitting in cloud storage tells you it exists — it doesn't tell you it works. Untested backups fail silently: a missing database table, an expired storage API key, a backup that only captured files and not the database (or vice versa). Test the restore, not just the backup job.

Here's a test you can run in under an hour, ideally every quarter:

Spin up a throwaway environment. Use a local tool like LocalWP, a free subdomain, or your host's built-in staging feature — never test a restore on your live site.
Pull your most recent offsite backup, not a fresh one — you want to know the backup you'd actually reach for in a real incident is good.
Restore both pieces: the database (via your plugin's restore button, or wp db import backup.sql with WP-CLI) and the files (theme, plugins, uploads).
Log in and check the details: does the homepage load without errors? Can you log into wp-admin? Are the last few orders, posts, or form submissions actually there?
Time it. Write down how long the whole restore took — that's your real recovery time, not the number on the plugin's marketing page.
Fix what broke, then repeat the test next quarter. A DR plan that's never been rehearsed is a guess wearing a plan's clothing.

Backup plugin options compared

Tool	Offsite storage	Automatic schedule	Best for
UpdraftPlus	Yes (free tier: Dropbox, Google Drive, S3, etc.)	Yes, on a schedule you set	Budget-friendly sites wanting real offsite storage without a subscription
Jetpack VaultPress Backup	Yes, built-in (paid)	Real-time, as changes happen	WooCommerce stores where losing even an hour of orders matters
BlogVault	Yes, built-in (paid)	Real-time or daily	Agencies managing several client sites from one dashboard
Duplicator	Manual export to your own storage	Manual on the free version; scheduled on Pro	One-off migrations and snapshots before a big change
Host-level backups (managed WordPress hosts)	Usually tied to the host's own storage	Yes, daily	A second layer — pair with a plugin backup for true offsite redundancy

None of these is "set and forget forever." Whichever you choose, put the quarterly restore test in a calendar reminder — that's the step people skip, and it's the one that actually matters.

Key takeaways

Match backup frequency to how much data you'd lose: weekly for a static site, daily for a blog, real-time or hourly for a store or lead-gen site.
A backup stored only on your hosting account isn't offsite — use the 3-2-1 rule: 3 copies, 2 storage types, 1 copy offsite.
Write your disaster recovery plan down as one page: what's backed up, where it lives, who restores it, and your acceptable downtime.
Test a full restore in a staging environment at least quarterly — an untested backup can fail exactly when you need it.
Backups protect your data after an incident; they don't stop the incident. Pair a solid backup routine with a free passive security check or a manual audit to catch the vulnerability before it's used.

Backups are your insurance policy — they won't tell you how someone could get in. If you want that answer, Bug Circuit's Circuit audit is a real person manually reviewing your WordPress site for $49, with a written report of every issue found, severity, and the exact fix. It's not a substitute for backups, and it's not a compliance certification — it's the honest next step once your safety net is actually in place.

Best Free WordPress 2FA Plugin & Setup Guide

Bug Circuit — Tue, 08 Sep 2026 23:13:08 +0000

Originally published on the Bug Circuit blog.

The best way to add 2FA to WordPress is a free, purpose-built plugin — the community-maintained "Two-Factor" plugin or Melapress's "WP 2FA" — set up to offer both an authenticator app and a no-app fallback like email codes or printed backup codes, so every staff member can actually use it.

This is for you if someone (a client, a security audit, or your own gut) told you to "just turn on 2FA" and you're not sure which plugin to trust, whether you need a fancy authenticator app, or how to set it up without locking your bookkeeper or shop manager out of the site. By the end you'll have a plugin picked, a login protected in under 10 minutes, and a backup option for people who don't want to install anything on their phone.

What 2FA actually does (in plain English)

Two-factor authentication (2FA) means logging in needs two things: something you know (your password) and something you have (a code from your phone, an email, or a physical key). If a hacker steals or guesses your password — which happens constantly through phishing emails and reused passwords from other data breaches — 2FA stops them cold because they don't have the second piece.

CISA, the U.S. government's cybersecurity agency, and OWASP, the nonprofit that writes the standard reference guides for web security, both list multi-factor authentication as one of the highest-value, lowest-cost defenses any website can add. Neither claims it makes a site "unhackable" — it doesn't stop a vulnerable plugin from being exploited or a server from being misconfigured — but it closes off the single most common way WordPress admin accounts get taken over: a stolen or guessed password.

The best free WordPress 2FA plugins

You don't need a paid tool to do this properly. Here's how the three most-installed free options compare:

Plugin	Cost	Authenticator app (TOTP)	No-app option	Enforce for other users	Best for
Two-Factor (WordPress core contributor team)	Free	Yes	Yes — email code, printed backup codes	Basic, per-user opt-in	Simplest setup, zero upsells, built by the people who maintain WordPress core
WP 2FA (Melapress)	Free (Pro adds SMS/Duo/policy reporting)	Yes	Backup codes	Yes — can force specific roles (e.g., all Editors and Admins) to set it up within a grace period	Agencies and site owners managing several staff logins
Wordfence Login Security	Free	Yes	Backup codes	Yes — can require it per role	Sites already running the Wordfence firewall plugin

All three are actively maintained, have no ads, and are available directly from the official WordPress plugin directory — always install from there or your dashboard's Plugins → Add New search, never from a random download link.

If you're picking one thing: install Two-Factor for a single-admin site, or WP 2FA if you have several staff accounts and want to force everyone to set it up rather than hoping they will.

How to add two-factor authentication to WordPress (step by step)

Using the Two-Factor plugin as the example — the steps are nearly identical in WP 2FA and Wordfence Login Security:

In your WordPress dashboard, go to Plugins → Add New Plugin, search "Two-Factor," and click Install Now, then Activate.
Go to Users → Profile (or Users → All Users and edit a specific person's account).
Scroll to the Two-Factor Options section.
Pick a primary method:
- Authenticator App (TOTP) — scan the QR code with Google Authenticator, Authy, or Apple's built-in Passwords app, then enter the 6-digit code it shows to confirm.
- Email — codes are sent to the account's email address at login; no app needed.
- Backup Verification Codes — a set of one-time codes you print or save somewhere safe, for when you're offline or your phone is dead.
Click Update Profile to save.
Log out and log back in to confirm the second step actually appears — don't skip this test.
Repeat for every account with Administrator or Editor access. A site is only as protected as its least-secured login.
If you're using WP 2FA instead, go to WP 2FA → Settings → 2FA Policy and set which roles must enable it and how many days they have (7 is reasonable) — the plugin will nag them with an on-screen notice until they comply.

Want to check your login page's other defenses at the same time? Run it through our free website security check — it flags exposed login pages, missing security headers, and other quick wins alongside 2FA.

2FA without an authenticator app: real options for non-technical staff

Not everyone wants to install Google Authenticator, and that's fine — it isn't the only valid form of 2FA:

Email one-time codes. The plugin emails a 6-digit code at login. Nothing to install; works on any device that can check email. Slightly weaker than an app (if someone's email is also compromised, this layer is bypassed too), but far better than a password alone.
Backup/recovery codes. A printed list of one-time-use codes, generated once and kept in a drawer or password manager. Good as a fallback for anyone, not just a primary method.
Passkeys or security keys (WebAuthn). Newer and app-free — the person taps a fingerprint reader, Face ID, or a physical USB key (like a YubiKey) instead of typing a code. The Two-Factor plugin supports FIDO U2F/WebAuthn keys if you want to go this route later.
SMS text codes. Some paid add-ons offer this. It works without an app, but SMS can be intercepted via SIM-swapping, so OWASP specifically recommends against relying on it as your only method — treat it as a last resort, not a first choice.

For a small team where one person genuinely won't use an app, email-based 2FA on the Two-Factor plugin is the pragmatic answer: it takes zero setup on their end beyond clicking "yes, that's my code."

Checklist: is your 2FA setup actually protecting you?

[ ] 2FA is enabled on every Administrator and Editor account, not just the main owner login
[ ] At least one backup method (backup codes or email) is set up per person, so nobody gets permanently locked out
[ ] You tested logging out and back in to confirm the code prompt actually shows up
[ ] Your WordPress admin username isn't literally "admin" (a leftover default that pairs badly with any login weakness)
[ ] You're still using unique, strong passwords — 2FA is a second layer, not a replacement for good password hygiene
[ ] Security headers and other basic hardening are in place — check with our security headers tool

What 2FA won't fix

2FA protects the login form. It does nothing for a vulnerable plugin, an outdated theme, a leaked database, or a misconfigured file permission — the kinds of issues that show up in most real WordPress compromises. If an audit or a client security questionnaire told you to "add 2FA," treat it as one item on a longer list, not the whole job. A proper site review looks at plugins, user roles, backups, and server configuration too — the difference between that kind of manual check and an automated scanner is explained in our guide to manual vs. automated penetration testing.

Key takeaways

Install a free, official plugin — Two-Factor for simplicity, WP 2FA if you need to enforce it across staff — directly from the WordPress plugin directory.
You don't need an authenticator app: email codes and printed backup codes are legitimate no-app 2FA options for less technical team members.
Turn it on for every Admin and Editor account, not just yours, and always set up a backup method so no one gets locked out.
2FA stops stolen or guessed passwords from being enough to break in, but it doesn't patch vulnerable plugins or fix server misconfigurations — it's one layer, not the whole defense.
Avoid SMS-only 2FA as your primary method if you have a choice; it's better than nothing but weaker than an app, email, or security key.

2FA is a genuinely good half-hour of work, and now you can do it yourself for free. If you want to know what else on your site actually needs fixing — plugins, headers, exposed files, the stuff a checklist alone won't catch — a real person can manually audit your whole site for $49 and hand you a plain-English report with exact fixes. See what's included on our pricing page, no pressure either way.

Stop WordPress Login Brute-Force Attacks

Bug Circuit — Sun, 06 Sep 2026 17:13:55 +0000

Originally published on the Bug Circuit blog.

The fastest fix is to install a login-limiting plugin (like Limit Login Attempts Reloaded) set to lock out an IP after 3-5 failed tries, then add a firewall or .htaccess rule to block the worst offending IPs outright. That stops the automated password-guessing script without you touching a single line of PHP.

This guide is for WordPress site owners who are getting a stream of "failed login" emails, noticed wp-login.php in their server logs getting hammered, or just want to lock the front door before it becomes a problem. By the end you'll know exactly which setting to change, which plugin to install, and how to tell WordPress to stop even answering the door for bots.

How to tell it's actually a brute-force attack

A brute-force attack is simply a script trying username/password combinations over and over, fast, hoping one works. You'll usually spot it through one or more of these signs:

Repeated "failed login attempt" emails, often several a minute, sometimes for usernames like admin, administrator, or your site name.
/wp-login.php or /xmlrpc.php showing up dozens or hundreds of times in your server's access log within a short window, often from different IPs.
The admin login page feels slow to load, or your host's CPU/resource usage graph spikes for no reason you can explain.
A hosting or security-plugin alert naming "brute force" or "credential stuffing" (the same technique, but using stolen username/password pairs instead of random guesses — OWASP explains the distinction).

If you're not sure whether what you're seeing is normal background noise or a real attack, our free website security check will scan for exposed login endpoints and obvious weaknesses at no cost — no card, no login required.

Why WordPress logins get targeted so often

wp-login.php is at a predictable URL on every default WordPress install, and xmlrpc.php (WordPress's legacy remote-publishing API) can be abused to test hundreds of password guesses in a single HTTP request. Automated bots crawl the web for exactly these two paths and throw lists of common passwords at them — this is listed by OWASP as one of the Automated Threats to Web Applications (Credential Cracking, OAT-007). It's not personal, and it doesn't mean your site was specifically chosen — it's the same script hitting millions of sites, yours included, because the door is in the same place on every WordPress install.

Step 1: Limit login attempts (do this first)

This is the single highest-value fix, and it takes about ten minutes.

In your WordPress dashboard, go to Plugins → Add New.
Search for and install Limit Login Attempts Reloaded (a free, actively maintained plugin — see its wordpress.org listing). WP Cerber and Wordfence's brute-force protection also work well if you want a plugin that bundles other security features.
Activate it, then go to Settings → Limit Login Attempts.
Set:
- Allowed retries: 3-4
- Lockout time: 20-60 minutes
- Increase lockout after repeated lockouts: on (this turns short bans into long ones for persistent attackers)
Turn on email notifications so you get one summary alert per lockout period, not one per attempt.

This alone won't stop determined attackers, but it kills the noise from unsophisticated bots almost immediately and buys you time to add the stronger layers below.

Step 2: Turn on two-factor authentication

Even a perfectly guessed password is useless to an attacker if they also need a rotating six-digit code from your phone. The Cybersecurity and Infrastructure Security Agency (CISA) recommends multi-factor authentication as one of the highest-impact, lowest-cost defenses against account takeover, and it fully neutralizes brute-force attacks on your admin account specifically.

Install Wordfence or WP 2FA (both free).
Require it for every account with an Administrator or Editor role — attackers don't need your account, just any account with publishing or plugin access.

Step 3: Block the attackers, not just the attempts

Limiting attempts slows a script down; blocking its IP address stops it cold. You have three realistic options, in order of effort:

Method	Effort	Blocks attacker before WordPress loads?	Good for
Plugin lockout list (from Step 1)	Low	No — WordPress still processes each request	Small sites, low attack volume
`.htaccess` deny rule for repeat-offender IPs	Medium	Yes	Sites on Apache with a fixed list of bad IPs
Web Application Firewall (Cloudflare, Sucuri, host-level WAF)	Low-Medium	Yes, at the network edge	Any site getting sustained or shifting-IP attacks

To block a specific IP via .htaccess (place near the top of the file in your site root):

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

Replace 203.0.113.45 with the offending IP from your logs. Repeat the Require not ip line for each address.

For a firewall-level fix (recommended if attacks are ongoing rather than a one-off), turn on a WAF like Cloudflare's free tier or your host's built-in firewall, and add a rate-limiting rule for /wp-login.php and /xmlrpc.php — e.g., "block for 1 hour if more than 5 requests to these paths in 1 minute from the same IP." This stops the request before it ever reaches your server, which also saves you hosting resources.

Step 4: Reduce what attackers can even reach

Disable XML-RPC if you don't use the WordPress mobile app or Jetpack (which rely on it). Most security plugins have a one-click toggle; otherwise your host or a plugin like Disable XML-RPC can block the endpoint entirely.
Change the login URL away from the default /wp-login.php using a plugin like WPS Hide Login. This isn't real security on its own (it's "security through obscurity"), but it removes your site from the pool of URLs that generic bots scan automatically.
Restrict wp-admin by IP if you or your team always log in from the same office or VPN IP — add an IP allowlist at the server or firewall level.

What not to rely on

A "strong password" alone. It helps, but a brute-force script doesn't get tired — pair it with 2FA and a lockout policy.
Renaming the login URL as your only defense. It reduces noise, not risk, if XML-RPC and REST API user-enumeration endpoints are still open.
A CAPTCHA with no rate limiting behind it. Some bots solve CAPTCHAs via cheap human-solving services; it should be one layer, not the whole strategy.

Quick checklist

[ ] Login-limiting plugin installed, set to lock after 3-4 tries
[ ] Two-factor authentication required for all Admin/Editor accounts
[ ] Repeat-offender IPs blocked at .htaccess or firewall level
[ ] XML-RPC disabled (unless actively used)
[ ] WAF or host-level rate limiting on /wp-login.php
[ ] Default admin username removed or renamed if still in use

If you're not sure your fixes actually closed the gap — or you want someone to check the rest of the site while they're in there — a manual security audit catches things automated scanners and default plugin settings miss, like leftover admin accounts or a misconfigured REST API still leaking usernames.

Key takeaways

Repeated failed-login emails and wp-login.php spikes in your logs mean an automated brute-force script has found your login page — this is extremely common and not a sign you've been personally targeted.
Install a login-limiting plugin (Limit Login Attempts Reloaded, WP Cerber, or Wordfence) and cap failed attempts at 3-4 before a lockout.
Two-factor authentication neutralizes brute-force attacks on your account even if a password is guessed correctly.
Block repeat-offender IPs at the .htaccess or firewall level, and rate-limit /wp-login.php and /xmlrpc.php for lasting protection.
Disabling XML-RPC and hiding the default login URL cut down the noise but should back up the layers above, not replace them.

None of this is complicated once it's set up, but it's easy to miss one open door — an old plugin, a forgotten admin account, an XML-RPC endpoint nobody remembered was on. If you want a second set of eyes, Circuit is a $49 one-time manual audit where a real security engineer checks your whole site, not just the login page, and hands you a plain-English report of anything else worth fixing.

GDPR for Small Websites: No-Legalese Checklist

Bug Circuit — Fri, 04 Sep 2026 05:13:30 +0000

Originally published on the Bug Circuit blog.

If your website has visitors, a contact form, or even just Google Analytics, and any of them could be in the EU or UK, GDPR applies to you — no matter how small your business is or where you're based.

Who this is for: small business owners, indie SaaS founders, and agencies running a marketing site, online store, or app with a contact form, newsletter signup, or login. What you'll get: a plain-English rundown of the four things that actually matter — cookies, your privacy policy, how you handle form data, and the security duty (Article 32) almost nobody reads — plus a one-page checklist you can work through in an afternoon.

This isn't legal advice — enforcement depends on your specific data flows, and a lawyer should sign off on anything customer-facing. But most small sites get compliance wrong in the same handful of predictable ways, and those are fixable without a law degree.

Does GDPR actually apply to your website?

GDPR (General Data Protection Regulation) is EU law, but it reaches well outside the EU. It applies to you if either is true:

You're based in the EU/UK, regardless of who visits your site, or
You're based anywhere else, but you offer goods or services to people in the EU/UK, or you monitor their behavior (analytics, ad tracking, cookies) — even if you never make a sale there.

In practice: if your contact form, newsletter, or checkout could realistically be used by someone in Europe, GDPR applies. "We don't think we have EU visitors" stops being a defense the moment you check your analytics and find you do.

The UK runs a near-identical "UK GDPR" post-Brexit, enforced by the ICO — everything below applies to both. Source: ICO guidance for small organisations.

The cookie banner: what you actually need

The banner requirement technically comes from the ePrivacy Directive (the "cookie law"), not GDPR itself — but GDPR defines what counts as valid consent, so regulators enforce them together. The rule is simple once you split cookies into two buckets:

Cookie type	Examples	Consent needed?
Strictly necessary	Session ID, shopping cart, login token, load balancer, CSRF/security token	No — but disclose them anyway
Everything else	Google Analytics, Meta Pixel, ad retargeting, A/B testing tools, embedded YouTube/social widgets	Yes — prior opt-in consent

Valid consent means:

Opt-in, not opt-out. No pre-ticked boxes for analytics or marketing cookies.
Specific and easy to refuse. "Accept all" as the only button isn't compliant without an equally easy "reject" or "manage preferences" option.
Before the cookie fires, not after. If Analytics loads on page load before anyone clicks anything, that's tracking without consent.
As easy to withdraw as to give — a "manage cookies" link in the footer, not a support ticket.

If your site only uses strictly-necessary cookies, you don't need a consent banner at all — just disclose them in your privacy policy.

Privacy policy checklist

A privacy policy isn't a formality — it's the document that proves you thought about what you collect. Under GDPR Article 13, it needs to disclose, in plain language:

Who you are and how to contact you (business name, email, physical address if you have one)
What personal data you collect (form fields, cookies, server logs, payment details)
Why you collect it and your legal basis (consent, contract, legitimate interest)
How long you keep it — a real retention period, not "as long as necessary"
Who you share it with — email provider, payment processor, host, analytics tools
Whether data leaves the EU/UK and how that transfer is protected
The visitor's rights: access, correction, deletion, restriction, objection, portability
Where to complain if they're unhappy — their local data protection authority

A policy copy-pasted from another site and never updated when you add a new tool (a chatbot, a new email platform) is one of the most common gaps we find during audits.

Contact and signup forms: collect less, store safer

GDPR's data minimization principle (Article 5(1)(c)) says you may only collect what you actually need for the stated purpose. Source: official GDPR text, Article 5.

Practical fixes for most small-site forms:

Drop fields you don't use. A contact form asking for phone number, company size, and job title when you only ever email people back is over-collecting.
Separate marketing consent from the form submission itself — an unticked "send me updates" checkbox, not a bundled agreement.
Never email form submissions containing sensitive data (ID numbers, health info) in plain text — route them to an encrypted CRM or ticketing system instead.
Set a real deletion schedule for old leads and abandoned carts — most email and CRM tools let you auto-purge inactive contacts.
Serve every form over HTTPS. A form on an unencrypted http:// page is both a GDPR problem and a basic security hole.

The clause almost every small business misses: Article 32

Most owners think GDPR is a paperwork exercise — write a policy, add a banner, done. But Article 32 ("Security of processing") is a legal obligation to actually secure the data you collect, and it's the part regulators focus on hardest after a breach. Source: GDPR Article 32, official text.

The regulation doesn't hand you a fixed checklist — it says measures must be "appropriate" to the risk. For a small business website, that translates to a concrete list:

Encrypt data in transit. Every page over HTTPS/TLS, not just checkout — an expired or missing certificate anywhere is a gap.
Keep software patched. Outdated CMS core, plugins, or themes are the most common way small sites get breached — see is my website hackable for how attackers actually find these.
Use strong authentication on admin accounts. Unique passwords plus two-factor authentication (2FA) for anyone with CMS, hosting, or database access.
Limit who has access. Not every staff member needs admin — use editor/contributor roles for people who don't manage plugins or settings.
Back up regularly, and actually test the restore. Article 32 explicitly calls out "the ability to restore availability... in a timely manner" after an incident — a backup you've never restored isn't one you can rely on.
Set basic security headers. Content-Security-Policy, Strict-Transport-Security, and X-Content-Type-Options cut down common attack surface — check yours free with our security headers tool.
Test it periodically. Article 32 requires "a process for regularly testing, assessing and evaluating the effectiveness" of these measures — the part a scanner alone can't fully judge, since it can't weigh context the way a person reviewing your actual site can.

This is what separates "we have a privacy policy" from actually meeting your GDPR security obligation — and it's the part a manual audit is built for, not a checkbox tool.

If you have a breach: the 72-hour clock

If personal data is exposed — a hacked database, a misconfigured form emailing submissions to the wrong place, a leaked backup — GDPR Article 33 gives you 72 hours from becoming aware of it to notify your supervisory authority, unless the breach is unlikely to risk people's rights and freedoms. If it's high-risk (passwords or financial data exposed), you may also need to tell the affected individuals directly.

Fines scale with severity: up to €10 million or 2% of global annual turnover for lesser infringements, and up to €20 million or 4% for the most serious ones — whichever is higher. Source: GDPR Article 83. For most small businesses, real enforcement is rare and usually follows a complaint or a breach, not a random audit — but "rare" isn't "never," and prevention is almost always cheaper than the incident.

One-page GDPR checklist

[ ] Cookie banner blocks non-necessary cookies until opt-in consent
[ ] "Reject" is as easy to click as "Accept"
[ ] Privacy policy lists what you collect, why, how long, and who it's shared with
[ ] Privacy policy names all third-party tools (analytics, email platform, payment processor)
[ ] Contact/signup forms only ask for fields you actually use
[ ] Marketing consent is a separate, unticked checkbox
[ ] All forms and pages served over HTTPS
[ ] CMS, plugins, and themes are up to date
[ ] Admin accounts use unique passwords + 2FA
[ ] Backups exist and have been test-restored in the last 6 months
[ ] You know who to notify within 72 hours if data is exposed

Key takeaways

GDPR applies based on your visitors' location, not your business's — check your analytics before assuming it doesn't apply to you.
The cookie banner only needs to gate non-essential cookies (analytics, ads); strictly necessary ones just need disclosure.
Your privacy policy should describe your actual current tools and data flows, not a copy-pasted template.
Article 32's "appropriate technical measures" is a real security requirement — HTTPS, patching, 2FA, and tested backups — not just a legal sentence.
A manual review catches the context-dependent gaps (over-collecting forms, unpatched plugins, missing headers) that automated scanners and legal templates both miss.

Where a manual audit fits in

None of this replaces legal advice on your specific data flows — but the security half of GDPR (Article 32) is exactly what a hands-on website review is built to check. Bug Circuit's Circuit audit is $49: a real person manually reviews your site and hands you a written report with fixes, including the headers, patching, and access issues that feed straight into your GDPR security obligations. Start with our free passive check if you just want a quick read on where you stand first.