DEV Community: Bug Circuit

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.

Webflow Security: Is Your Site Actually Safe?

Bug Circuit — Wed, 02 Sep 2026 17:13:20 +0000

Originally published on the Bug Circuit blog.

Webflow's hosting keeps your server safe — it doesn't check the code, forms, and integrations you added on top of it, and that's where most Webflow sites actually get compromised.

This is for agencies and freelancers running client sites on Webflow, and Webflow site owners who assume "Webflow is secure" means the whole site is covered. You'll get a plain-English breakdown of what Webflow's hosting actually protects, the four risk areas it doesn't touch, and a 10-minute checklist you can run on any Webflow site today — plus how to think about it if you resell security audits as part of your client work.

What Webflow's hosting actually protects

Webflow is a managed platform, and that buys you real security out of the box. Its hosting runs behind a CDN with automatic SSL/TLS, infrastructure-level DDoS mitigation, and automated backups — you don't manage a server, so there's no unpatched Linux box or outdated PHP version for an attacker to exploit the way there often is on a self-hosted WordPress install.

But "managed hosting" only covers the parts Webflow itself controls. Everything you build on top of that — custom code, forms, integrations, content — is your responsibility, same as on any platform.

Layer	Who's responsible	Covered by Webflow hosting?
Servers, SSL, CDN, uptime, DDoS	Webflow	Yes
Platform patching (no plugins to update)	Webflow	Yes
Custom code you embed (head/footer/embed blocks)	You / your agency	No
API keys and tokens pasted into embeds or integrations	You / your agency	No
Form spam and abuse settings	You / your agency	Partially — defaults exist but aren't complete
CMS collection data exposed via the API	You / your agency	No
Response security headers (CSP, HSTS, etc.)	You / your agency	Mostly no

This is the gap that shows up in almost every Webflow audit we run: the platform itself is solid, but the things a builder added — a Zapier webhook, a tracking script, a "quick fix" embed — are where the actual exposure lives.

The four risks Webflow hosting doesn't cover

1. Leaked API keys in custom code embeds

Webflow's Custom Code panel (Site Settings → Custom Code, or an Embed element on a page) is one of its most useful features — and one of the easiest ways to leak a secret. Anything typed into an embed is delivered as plain client-side HTML/JavaScript, meaning anyone can see it by right-clicking → View Page Source.

We regularly find live API keys for tools like Airtable, Google Maps, Mailchimp, Zapier, and CRMs sitting in plain view inside embeds — usually copy-pasted straight from a tutorial. A key with write access in the wrong hands can mean spam data injected into a CRM, a maxed-out API bill, or a foothold into a connected tool.

Hard-coding secrets into client-facing code is a well-documented anti-pattern: OWASP's Secrets Management Cheat Sheet and the CWE-798: Use of Hard-Coded Credentials weakness class both cover it directly. The fix: any key that needs to stay secret belongs in a server-side function or a proxy — never in an embed the browser can read.

2. Unprotected form submissions

Webflow Forms come with basic honeypot-style spam filtering, but that's not the same as rate limiting or bot protection. Left on defaults, a public form is an open door for:

Automated spam floods that fill your (or your client's) inbox and CMS
Bots probing form fields for weak input validation
Fake leads polluting sales data

OWASP catalogs this class of abuse under Automated Threats to Web Applications. To close the gap: turn on reCAPTCHA in the form element's settings, restrict what fields accept (no open file uploads unless genuinely required), and don't route submissions anywhere that could be used to spoof internal emails or phish your team.

3. CMS data exposed through the API

Webflow's CMS is genuinely well-built, but "CMS item" and "private data" aren't automatically the same thing. Two patterns show up repeatedly:

A collection meant for internal use (draft content, pricing tiers, internal notes) gets published because "unpublished" only hides it from the live site, not from anyone with the direct API access an integration might have.
A Webflow API token — used to power custom filtering, search, or a headless front end — gets embedded in client-side JavaScript instead of a backend, exposing read/write access to every collection it can reach.

Treat any Webflow API token the same as a database password: server-side only, scoped to the minimum access it needs, and rotated if you're ever unsure where it's been pasted.

4. Security headers you have to set yourself

Response headers like Content-Security-Policy, X-Content-Type-Options: nosniff, and Strict-Transport-Security tell the browser how to defend the page against things like clickjacking and script injection — but most Webflow plans don't give you a direct panel to set them. If your plan doesn't support custom headers, the practical fix is fronting the site with a service like Cloudflare, which can inject these headers at the edge without touching Webflow itself.

OWASP's Secure Headers Project is the reference for what each header does and recommended values. Run your live site through our security headers checker to see exactly which ones are missing — it takes about ten seconds and needs nothing installed.

A 10-minute self-check for any Webflow site

Run through this on your own site, or a client's, before assuming it's fine:

View source on every page with an embed. Search for key=, token=, apikey, or secret — anything that looks like a credential shouldn't be there.
Check every form's settings for reCAPTCHA or spam protection and confirm exactly where submissions get sent.
List every third-party integration (Zapier, Make, Airtable, Google Sheets, a CRM) connected to the site and confirm none of their keys live inside Webflow's custom code.
Scan for security headers using a header-check tool and note what's missing.
Review CMS collections for anything published that shouldn't be public — draft content, internal pricing, staff data.
Check for an orphaned staging subdomain (.webflow.io) still live and indexable after launch.

If more than one or two of these turn up something, it's worth getting a second pair of eyes on it rather than guessing at severity yourself.

Why "it's on Webflow, so it's secure" is a trap for agencies

If you build or manage sites for clients, "Webflow is secure" is a sentence clients repeat back to you — and it's true just enough to be dangerous. Webflow's hosting is genuinely solid infrastructure, but a client breached through a leaked Zapier key sitting in their homepage's embed code won't care that the servers were fine. The exposure was in what your team built, and that's exactly the layer an automated scanner tends to skim past, because scanners test infrastructure patterns, not the specific embed a designer pasted in eight months ago. Our guide comparing manual vs. automated penetration testing covers why a human reading the actual page source catches this class of issue that tooling alone tends to miss — it's why agencies increasingly bundle a manual pass into every Webflow handoff instead of a one-line "we use Webflow, so you're covered."

Key takeaways

Webflow's hosting secures the servers, SSL, and uptime — it does not check your custom code, forms, integrations, or CMS data for you.
Anything typed into a Custom Code embed is publicly visible via View Source, including any API key pasted there by mistake.
Turn on reCAPTCHA on public forms and never route form data anywhere an attacker could use it for phishing.
Treat Webflow API tokens like passwords: server-side only, minimum scope, never in client-facing JavaScript.
Missing security headers (CSP, HSTS, X-Content-Type-Options) are on you to add — usually via a proxy like Cloudflare if your plan doesn't support them directly.

If your self-check turned up a stray API key, a wide-open form, or you're just not sure what's actually exposed on a Webflow build you inherited, that's exactly what a manual audit is for. Circuit is a $49 one-time check where a real person reads the actual page source, tests the forms, and hands you a written report of what's exposed and how to fix it — not another automated scan re-flagging the same generic warnings. Or start with our free passive security check if you just want a quick read on where things stand.

What Is Clickjacking? The 1-Line Fix

Bug Circuit — Mon, 31 Aug 2026 23:13:12 +0000

Originally published on the Bug Circuit blog.

Clickjacking is an attack where a hacker hides your website inside an invisible frame on their own page, then tricks a visitor into clicking something they can't see — a "Buy Now" button, a "Follow" button, or an account-settings toggle that actually belongs to your site.

This is for anyone who owns or runs a website — WordPress, Shopify, or a custom app — and wants to know if clickjacking is something to worry about. In a few minutes you'll understand exactly how the invisible-overlay trick works, see the real damage it can do, and get the one HTTP response header (plus copy-paste code for the platforms people actually use) that shuts it down for good.

What is clickjacking, actually?

Clickjacking, also called a "UI redress attack," is a trick, not a break-in. The attacker doesn't steal a password or hack your server — they abuse a normal browser feature called an iframe, which lets one webpage embed another webpage inside it, like a window within a window.

Here's the setup:

The attacker builds their own page with something tempting on it — "Click to claim your prize," a fake video play button, a captcha.
Behind that visible content, they load your real website inside an iframe and set its transparency to zero, making it completely invisible to the visitor.
They line up your site's real button — say, "Confirm Purchase" or "Delete Account" — exactly under the fake button the visitor sees.
The visitor clicks what looks like the prize button, but the click actually lands on your invisible page underneath, in the visitor's real logged-in session.

Because the click happens on your real site with the visitor's real cookies, your server has no way to tell a genuine click from a hijacked one — the request looks completely normal. That's why the fix has to happen at the browser-framing level rather than inside your app's logic; see OWASP's Clickjacking Defense Cheat Sheet for the full technical breakdown. The technique was named and publicized by security researchers Jeremiah Grossman and Robert Hansen in 2008, and it's now formally tracked as CWE-1021: Improper Restriction of Rendered UI Layers or Frames.

What can an attacker actually make your visitors do?

Anything a logged-in user can do with a single click is fair game:

Force a purchase or subscription renewal on a checkout or "buy now" button
Change account settings — recovery email, password reset options, two-factor auth
Grant browser permissions, like "Allow" prompts for camera or microphone
Manipulate social proof — trick visitors into liking, following, or sharing something ("likejacking")
Trigger a donation or money transfer on sites with one-click payment buttons
Delete content or data behind a "Confirm delete" button that was never meant to be clicked blind

None of this needs stolen credentials. It just needs your pages to be frameable, and either a logged-in visitor or an action that doesn't require login at all, like a public donation form.

The 1-line fix: a frame-protection header

The fix is a single line in your server's response headers telling browsers "never let another site put my pages inside a frame." Once that header is present, the invisible-overlay trick can't render at all — the browser simply refuses to load your page inside the attacker's frame.

Two headers do this job. Set both if you can; if you only add one, make it the CSP version.

Header	The 1 line	What it does	Notes
Content-Security-Policy	`Content-Security-Policy: frame-ancestors 'self';`	Only your own site can frame your pages	Modern standard; can list multiple trusted origins
X-Frame-Options	`X-Frame-Options: SAMEORIGIN`	Same idea, older syntax	Reliable fallback for older clients; use `DENY` if nothing should ever frame the page

Both are documented on MDN: X-Frame-Options and CSP frame-ancestors.

Copy-paste it for your platform

Nginx — add inside your server block:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache — add to .htaccess or your vhost config:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

WordPress (no code needed): many security plugins expose a "Clickjacking protection" or "Frame options" toggle in settings. If your host or plugin offers it, that's the fastest route.

Node.js / Express — using the popular helmet middleware:

const helmet = require('helmet');
app.use(helmet.frameguard({ action: 'sameorigin' }));
app.use(helmet.contentSecurityPolicy({
  directives: { frameAncestors: ["'self'"] }
}));

Cloudflare (no origin access needed): Rules → Transform Rules → Modify Response Header → add both headers with the values above. This works even if you can't edit your hosting config directly.

How to check if you're actually protected

Don't take it on faith — verify the header is live on your production pages, not just sitting in a config file that never shipped:

Open your site, open browser DevTools → Network tab, click the main document request, and check the Headers.
Look for x-frame-options or content-security-policy in the response.
Or skip the manual digging and run your domain through Bug Circuit's free security headers checker — it flags missing frame protection alongside the other headers that matter, like HSTS and X-Content-Type-Options, in one pass.

Common mistakes that undo the fix

Setting it in code but not in production. A CSP meta tag in your HTML, or a header only set in your dev environment, doesn't help real visitors hitting your live, cached pages.
Using DENY when you legitimately embed your own content, like a payment widget or dashboard loaded from a subdomain. DENY blocks that too — use SAMEORIGIN, or list the specific trusted origin in frame-ancestors instead.
A CDN or proxy stripping the header. Some caches serve stale responses from before the header existed. After deploying, purge the cache and re-check.
Only testing the homepage. Checkout, account settings, and admin login are the actual targets — confirm the header is present sitewide, not just on the one page you happened to check.

Is this the only clickjacking-style trick?

Frame-based clickjacking is the classic version and by far the most common in the wild, but related tricks exist too — cursorjacking (offsetting the visible cursor from the real one), drag-and-drop hijacking, and tapjacking on mobile. The frame-ancestors/X-Frame-Options fix closes off the frame-based attack entirely. A full manual review checks for the less common variants too, and confirms your specific high-value pages — checkout, settings, delete-account — aren't exposed in ways a header alone can't catch.

When a header isn't the whole story

Adding this header takes minutes and shuts down an entire class of attack — but it's one line among dozens of things that can go wrong on a small business site: exposed admin panels, outdated plugins, weak session handling, misconfigured payment flows. If no one has actually looked at your site's security before, our guide on figuring out if your website is hackable is a good next stop, and if you're weighing an automated scanner against a real person checking your site, see manual vs. automated penetration testing for how they actually differ.

Key takeaways

Clickjacking hides your site in an invisible iframe so visitor clicks land on your buttons instead of the fake ones they see.
The fix is one HTTP header: Content-Security-Policy: frame-ancestors 'self'; — add X-Frame-Options: SAMEORIGIN too for broader compatibility.
Use SAMEORIGIN / 'self' instead of DENY if you ever embed your own pages inside your own site.
Verify the header on your live production pages, not just in config — CDNs can keep serving stale, unprotected responses.
Run a free check at Bug Circuit's security headers tool to confirm it's actually in place.

Frame protection is a five-minute fix once you know it's missing — the harder part is knowing what else might be. A Circuit audit is $49, done by an actual person, and comes back with every issue like this one spelled out with the exact fix, not just a scanner score.

What Is a Security Header? The 5 You Need

Bug Circuit — Sun, 30 Aug 2026 05:12:55 +0000

Originally published on the Bug Circuit blog.

A security header is a short instruction your web server sends to every visitor's browser telling it how to behave safely on your site — and most small sites are missing at least three of the five that matter most.

This is for anyone who runs a WordPress site, Shopify store, or small SaaS app and just got flagged by a security scanner, a client's vendor questionnaire, or our own free website security check for "missing security headers." By the end, you'll know what each header does, what it actually stops, and have copy-pasteable code to add all five today.

What is a security header, exactly?

Every time a browser loads your site, your server sends back more than just the page content — it also sends a set of HTTP response headers, small text instructions that ride alongside the page and never show up on screen. Most headers are boring plumbing (content length, cache rules). Security headers are the subset that tell the browser things like "only run scripts from my own domain" or "never load me inside someone else's frame."

The browser enforces these instructions itself — you're not installing anything, and visitors never see them. Think of it as handing the browser a short list of house rules before it starts rendering your page. The OWASP Secure Headers Project maintains the standard reference for which headers exist and what each one does, and it's the source most scanners (including ours) check against.

Missing headers don't automatically mean you've been hacked. They mean the browser is running your site with fewer guardrails than it could have — which matters most when something else on your site (an old plugin, a comment form, a third-party script) is already vulnerable.

The 5 security headers every small site needs

Header	What it stops	Example value
Content-Security-Policy (CSP)	Malicious scripts running on your page (XSS)	`default-src 'self'; frame-ancestors 'self';`
Strict-Transport-Security (HSTS)	Browsers being tricked into connecting over unencrypted HTTP	`max-age=31536000; includeSubDomains; preload`
X-Frame-Options (or CSP `frame-ancestors`)	Your site being loaded invisibly inside another site (clickjacking)	`SAMEORIGIN`
X-Content-Type-Options	The browser guessing a file's type and running it as something dangerous	`nosniff`
Referrer-Policy	Full page URLs (sometimes containing tokens or IDs) leaking to third-party sites	`strict-origin-when-cross-origin`

1. Content-Security-Policy (CSP) — the big one

CSP tells the browser which sources of scripts, styles, images, and fonts are allowed to load on your page. If an attacker manages to inject a malicious <script> tag — through a vulnerable comment form, a hacked plugin, or a compromised ad network — a strict CSP simply refuses to run it, because it didn't come from an approved source.

This is the header that stops cross-site scripting (XSS) from doing real damage, which is why OWASP's CSP guidance treats it as the highest-value header on the list. It's also the trickiest to set up, because a policy that's too strict will silently break embedded YouTube videos, Google Fonts, or chat widgets. Start with a Content-Security-Policy-Report-Only header (same syntax, but it only logs violations instead of blocking them) so you can see what would break before you enforce it.

2. Strict-Transport-Security (HSTS) — no downgrading to HTTP

Even if your site has an SSL certificate and redirects HTTP to HTTPS, a visitor's very first request can still go out over plain HTTP for a split second — long enough for an attacker on the same network (public Wi-Fi, a compromised router) to intercept it. HSTS fixes this by telling the browser, "never try HTTP for this domain again, for the next year," so it upgrades to HTTPS before sending anything.

Be careful with includeSubDomains: it applies the rule to every subdomain too, so confirm all of them actually support HTTPS first. Once you're confident, you can submit your domain to the HSTS preload list so browsers enforce HTTPS even on a user's very first visit, before your server has said anything.

3. X-Frame-Options / frame-ancestors — stop clickjacking

Clickjacking is when an attacker loads your live site inside an invisible iframe on their own page, then overlays fake buttons to trick visitors into clicking something on your site — like "delete account" or "transfer funds" — without realizing it. X-Frame-Options: SAMEORIGIN tells browsers your page may only be framed by itself. The modern equivalent is CSP's frame-ancestors directive; OWASP's Clickjacking Defense Cheat Sheet recommends sending both, since frame-ancestors isn't supported in a few older browsers still in the wild.

4. X-Content-Type-Options — stop MIME-sniffing tricks

Browsers sometimes try to be "helpful" by guessing a file's actual type instead of trusting what the server declared — this is called MIME-sniffing. Attackers have abused this to get a browser to treat an uploaded file (say, a user avatar) as executable JavaScript instead of a harmless image. X-Content-Type-Options: nosniff turns this guessing off entirely and forces the browser to trust the declared content type.

5. Referrer-Policy — stop leaking your URLs

When a visitor clicks a link from your site to another site, the browser can send the full URL of the page they came from in the Referer header — including anything in the URL itself, like a password-reset token, an internal search query, or a customer ID. Referrer-Policy: strict-origin-when-cross-origin limits what gets shared: your own site still gets full detail, but outside sites only see your domain name, not the full path.

How to check which headers your site already has

Before changing anything, see where you stand. Run our free security headers checker against your domain — it's passive (no login, no scanning your login forms) and shows exactly which of the five are present, missing, or misconfigured, in plain English.

How to add these headers

Exact syntax depends on your hosting setup. Here's the same five headers for the most common stacks.

Nginx (inside your server block):

add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'self';" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache (in .htaccess or your vhost config):

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; frame-ancestors 'self';"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Netlify (a _headers file in your publish directory):

/*
  Content-Security-Policy: default-src 'self'; frame-ancestors 'self';
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

WordPress: if you're on shared hosting without server access, a plugin like "HTTP Headers" or the security-headers module in a plugin such as Really Simple Security can add these without editing server config. Add one header at a time and reload your homepage between each to catch anything that breaks.

Cloudflare: use Rules → Transform Rules → Modify Response Header to add each header at the edge, without touching your origin server at all.

Common mistakes to avoid

Copy-pasting a CSP from another site. Every site loads different scripts (analytics, chat widgets, payment forms) — a policy built for someone else's stack will either break yours or leave gaps.
Turning on HSTS preload before confirming every subdomain works over HTTPS. Preload removal from browsers can take months.
Setting X-Frame-Options: DENY on a site that legitimately embeds itself (e.g., a widget meant to be iframed by customers) — use SAMEORIGIN or a specific frame-ancestors list instead.
Adding headers and never testing the site afterward. Reload every major page type — homepage, checkout, contact form — before calling it done.
Treating headers as the whole security picture. They reduce what a successful attack can do; they don't patch the vulnerable plugin, weak password, or exposed admin panel that let the attack start. For that, see our guide on how to tell if your website is hackable.

Key takeaways

A security header is an instruction your server sends to the browser — invisible to visitors, enforced automatically.
The five that matter most for a small site: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options (or frame-ancestors), X-Content-Type-Options, and Referrer-Policy.
CSP is the highest-value and highest-risk header to configure — test with Content-Security-Policy-Report-Only before enforcing.
Check your current headers for free before changing anything, then add them one at a time and reload the site to catch breakage.
Headers reduce the damage an attack can do — they don't replace patching the actual vulnerability that let an attacker in.

Headers are the easy, free part. The harder question — whether something on your site is actually exploitable right now — needs a person to look, not just a scanner. That's what our $49 manual audit is for: a real security engineer checks your headers along with everything else and hands you a plain-English report of what to fix and how.

Fix Chrome's "Deceptive Site Ahead" Warning

Bug Circuit — Thu, 27 Aug 2026 17:12:24 +0000

Originally published on the Bug Circuit blog.

The red "Deceptive site ahead" screen means Google's Safe Browsing system found phishing or social-engineering content on your site — you fix it by removing that content and then filing a review request in Google Search Console.

This is for site owners who've just seen the full-page red Chrome warning (not the small gray "Not Secure" label in the address bar, and not Search Console's "This site may be hacked" message — those are different problems). You'll get: exactly what triggers this specific warning, how it differs from the other two, and the step-by-step review-request process to get it lifted — including what to check first if you run WordPress.

What "Deceptive site ahead" actually means

This warning comes from Google Safe Browsing, a service Chrome (and Firefox, and Safari) checks against before loading a page. It isn't one generic "your site is bad" flag — Safe Browsing has separate categories, and each produces a different warning screen:

"Deceptive site ahead" — social engineering content: phishing pages, fake login forms, deceptive download buttons, scareware popups
"The site ahead contains malware" — the site tries to install malicious software on visitors' devices
"This site is dangerous" — a general catch-all Chrome uses when multiple threat types are detected

Google's own definition of social engineering content is content that "tricks users into doing something dangerous... such as revealing confidential information or downloading software" — for example a page that impersonates a bank, Google, or Microsoft login, or a popup that claims the visitor's device is infected. See Google's social engineering (phishing) content policy for the exact criteria. This is the same category OWASP describes as phishing: tricking a user into handing over credentials or money by impersonating something trustworthy.

Importantly, this often isn't content you put there. It's usually a symptom of a hack: an attacker planted a phishing page or malicious redirect somewhere on your site, and Safe Browsing's crawlers found it.

How this differs from "Not Secure" and "This site may be hacked"

These three warnings look similar but come from completely different systems, and mixing them up leads to the wrong fix.

Warning	Where it appears	What triggers it	Who issues it
Deceptive site ahead	Full-page red interstitial in the browser, before the page loads	Phishing / social-engineering content found on your domain	Google Safe Browsing
Not Secure	Small gray/red label in the address bar	Page loaded over plain HTTP, or has mixed content (HTTP resources on an HTTPS page)	Chrome itself, based on the connection, not content
"This site may be hacked"	A gray label under your listing in Google Search results	Googlebot found spam, injected links, or malicious code while indexing your pages	Google Search (reported via Search Console's Security Issues report)

Fixing a "Not Secure" label means installing or fixing an SSL/TLS certificate — it says nothing about malicious content. Fixing "This site may be hacked" means cleaning spam/injected code Googlebot found in your indexed pages. "Deceptive site ahead" is the most urgent of the three because it actively blocks visitors from reaching your site at all, and it's specifically about content designed to deceive, not just insecure or spammy content. If you're unsure which category your problem falls into, our guide to whether your site is hackable walks through the warning signs for each.

What actually triggers this warning

The content Safe Browsing looks for typically falls into one of these patterns:

A fake login page planted somewhere on your domain (often in an unused subfolder) mimicking PayPal, Microsoft 365, a bank, or a crypto wallet
Deceptive popups or overlays — fake "your device is infected" alerts, fake browser update prompts, or "you've won a prize" popups, often injected via a compromised ad network or a malicious script
Cloaked redirects — a script that sends normal visitors to your real site but redirects search engines or specific referrers to a phishing page, making the problem harder to spot
A hacked plugin or theme on WordPress, Shopify apps, or similar CMS platforms that silently drops phishing files into an uploads or cache directory
A compromised third-party embed — an ad unit, widget, or iframe you didn't author, serving deceptive content you don't directly control but that still lives on your page

For a WordPress site specifically, the usual entry point is an outdated plugin or theme with a known vulnerability, a weak admin password, or a leftover admin account nobody remembers creating. If you want a fuller picture of how sites get compromised in the first place, see our guide on what to do when your website is hacked.

Step-by-step: fix it and request removal

Confirm what Google found. Go to Search Console's Security Issues report, or check your domain directly with the Safe Browsing site status tool — it will tell you the flagged pages and the date detected.
Take the site into maintenance mode if you can, so no visitors hit the deceptive content while you work. This isn't required, but it limits harm and buys you time.
Find and remove the malicious content. Check recently modified files (find /path/to/site -mtime -14 -type f on a Linux host is a good start), unfamiliar folders under wp-content/uploads, unexpected .htaccess redirect rules, and any admin users or plugins you don't recognize.
Close the entry point. Update WordPress core, every plugin, and every theme. Change all passwords — WP admin, hosting control panel, SFTP/FTP, and database. Remove any admin account you didn't create. If you use WordPress security salts, regenerate them via wp-config.php.
Rescan to confirm it's clean. Run the site through the Safe Browsing site status tool again, plus an independent scanner like Sucuri SiteCheck, before you submit anything to Google.
Request a review. In Search Console, open the Security Issues report for your verified property and click "Request Review." Briefly describe what was wrong and what you did to fix it — Google's own request-a-review guide covers the exact form fields.
Wait it out. Reviews commonly clear within a day or two once the site is genuinely clean, though Google doesn't publish a fixed turnaround time — resist the urge to resubmit repeatedly, which can slow things down rather than speed them up.

Before you hit submit: a quick checklist

[ ] Your domain is verified in Search Console (Domain or URL-prefix property)
[ ] The specific flagged pages/files are gone, not just hidden
[ ] All passwords (WP admin, hosting, FTP, database) have been changed
[ ] Core, plugins, and themes are fully updated
[ ] A fresh scan (Safe Browsing status + a second scanner) comes back clean
[ ] You've noted what caused it, so it doesn't happen again

Skipping any of these is the most common reason a review request gets rejected and the warning reappears a few days later.

Preventing a repeat

Once you're clean, a few habits make this much less likely to happen again:

Keep plugins/themes updated and delete ones you're not actively using — each one is a potential entry point
Turn on strong security headers (our security headers checker shows what's missing on your site)
Use a web application firewall (Wordfence, Sucuri, or Cloudflare's proxy) to block common exploit attempts before they reach your code
Require two-factor authentication for every admin account
Run periodic malware scans rather than waiting for Google to tell you something's wrong

A free automated scanner catches known signatures, but the phishing pages and cloaked redirects that trigger Safe Browsing are often hand-placed by an attacker specifically to avoid detection — which is exactly the kind of thing a manual review is built to catch that an automated pass misses. If you want a second set of eyes, our free website security check gives you a fast yes/no read on whether anything critical is currently exposed, no card or login required.

Key takeaways

"Deceptive site ahead" is a Google Safe Browsing flag for phishing/social-engineering content — different from the address-bar "Not Secure" label (HTTPS issue) and Search Console's "This site may be hacked" (indexed spam)
The usual cause is a hacked plugin, theme, or third-party embed that planted a fake login page, deceptive popup, or cloaked redirect
Fix the content, patch the entry point, and rotate every credential before you request review — partial fixes are the top reason review requests fail
Submit the review through Search Console's Security Issues report; don't resubmit repeatedly while waiting
Add ongoing scanning and a WAF afterward so the same hole doesn't get exploited again

If you'd rather have a human confirm the site is actually clean before you file the review — or trace exactly how the attacker got in — a Bug Circuit manual audit starts at $49: a real engineer checks the whole site and hands you a written report with evidence and exact fixes, not just a scanner printout.

Is Wix or Squarespace Secure? What They Do & Don't Cover

Bug Circuit — Mon, 24 Aug 2026 23:12:15 +0000

Originally published on the Bug Circuit blog.

Yes, Wix and Squarespace are secure at the infrastructure level — but that only covers part of the risk, and the rest is on you. Both platforms patch servers, run your site over HTTPS, and guard against the classic hosting-level attacks. Neither one protects a weak login password, a sketchy embedded script, a missing email record, or a page you forgot was still public.

This is for owners running a small business, portfolio, or online store on Wix or Squarespace who want a straight answer: what's actually covered, what isn't, and what to check this week. You'll walk away with a concrete hardening checklist, not just reassurance.

What Wix and Squarespace Actually Secure For You

Both companies run closed, managed platforms — you don't touch a server, install patches, or configure a firewall, because they do it centrally for every site on the platform. That buys you real protection:

Automatic HTTPS/SSL on every domain, including custom domains, with certificates renewed for you.
Server and software patching handled centrally — you're never running an outdated CMS core like you would with self-hosted WordPress.
DDoS mitigation and network-level filtering at the hosting layer.
PCI DSS-compliant payment processing if you use their built-in checkout, so you're not storing card numbers yourself.

Wix publishes its practices at wix.com/about/security and Squarespace at squarespace.com/security — both are worth a skim if a client ever sends you a security questionnaire.

What this buys you is protection against the kind of attack that hits self-hosted CMS platforms hardest: an unpatched plugin or core file getting exploited directly. That specific risk mostly disappears on Wix or Squarespace. It does not mean the site can't be compromised — it means the compromise happens somewhere else.

Where the Real Risk Actually Sits

Risk area	Covered by Wix/Squarespace?	Who's responsible
Server patching, SSL certificates	Yes	Platform
DDoS protection at the network layer	Yes	Platform
Payment card data (built-in checkout)	Yes (PCI DSS)	Platform
Your account password & login security	No	You
Two-factor authentication (2FA) being turned on	No — it's optional	You
Third-party embeds, widgets, and tracking scripts	No	You
DNS records (SPF/DKIM/DMARC) for your domain	No	You
Unlisted, password-protected, or old draft pages	No	You
Team member / collaborator access levels	No	You

The pattern: the platform secures its own infrastructure. Everything you configure on top of it — accounts, embeds, DNS, page visibility — is yours to lock down. That's true of every hosted builder, not a knock against Wix or Squarespace specifically.

Your Account Is the Weakest Point, Not Their Servers

Most real-world Wix and Squarespace compromises don't involve hacking the platform at all — they involve someone getting into your account. Attackers don't need to break encryption if they can just log in.

Turn on two-factor authentication (2FA). In Wix, go to Account Settings → Sign In & Security → Two-Factor Authentication. In Squarespace, it's under Account → Security → Two-Step Verification. This single step blocks the most common account-takeover method: a reused or leaked password.
Use a unique, long password for your builder account — not one shared with any other site. NIST's password guidelines recommend length over complexity: a random 16+ character passphrase beats "P@ssw0rd1!".
Audit collaborator access. Both platforms let you add team members with different permission levels. Remove ex-contractors and freelancers as soon as a project ends — check Wix's Roles & Permissions or Squarespace's Contributors list.
Watch for phishing emails that mimic Wix or Squarespace login pages. These platforms are common phishing targets precisely because so many small businesses run on them.

Risky Embeds and Third-Party Apps

Wix's App Market and Squarespace's extensions let you bolt on chat widgets, booking tools, review plugins, and marketing pixels in a couple of clicks. Convenient — and also the most common way a hosted site gets something malicious injected into it.

An embedded third-party script runs in your visitors' browsers with the same trust as your own content. If that script is compromised, outdated, or was never legitimate to begin with, it can skim form data, redirect visitors, or inject unwanted content — a pattern OWASP documents broadly under cross-site scripting (XSS), where injected script runs in the context of a trusted page.

Before adding any embed or custom code block:

Only install apps from the official Wix App Market or Squarespace Extensions — never a script copy-pasted from a random tutorial or forum post.
Check the app's last update date and review count. Abandoned apps are a common weak point.
Remove embeds you no longer use — a dead chat widget or old A/B testing script is still a live piece of code running on every page.
If you use a custom Code Injection block (Squarespace) or embed HTML widget (Wix), know exactly what every line does, or have someone who does review it.

Our security headers checker will show you what protections your live site is actually sending, including whether a Content-Security-Policy is limiting what third-party scripts can do.

DNS and Email Spoofing: The Silent Risk

This is the part almost every small business owner misses, because it has nothing to do with the website itself — it's about your domain's email records.

When you point a custom domain at Wix or Squarespace, you also control DNS records that determine who's allowed to send email as your domain. If those records are missing or misconfigured, anyone can forge an email that appears to come from you — invoicing your customers, phishing your team, or damaging your domain's reputation.

The three records that matter:

SPF — lists which mail servers are allowed to send for your domain (e.g. v=spf1 include:_spf.google.com ~all).
DKIM — a cryptographic signature proving an email wasn't altered in transit.
DMARC — tells receiving mail servers what to do with messages that fail SPF/DKIM checks, e.g. v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com.

CISA has directed U.S. federal agencies to enforce DMARC specifically because unauthenticated domains are so easy to spoof — see CISA Binding Operational Directive 18-01. The same logic applies to any business domain. Run our email spoofing checker to see in under a minute whether your domain can currently be impersonated.

Pages You Forgot Were Public

Wix and Squarespace make it easy to spin up draft pages, staging content, old landing pages, or "unlisted" pages that aren't in your navigation menu. Unlisted is not the same as private — an unlisted page is still reachable by anyone who has or guesses the URL, and can still get indexed by search engines or found by an automated scanner.

Quick check:

Search site:yourdomain.com in Google and skim every result — anything you don't recognize needs a look.
In your site editor, review the full page list (not just the nav menu) for anything old, unfinished, or duplicated.
Password-protect or delete pages containing pricing drafts, internal notes, or test content instead of just unlisting them.
Check for old subdomains or preview URLs (like a *.wixsite.com staging link) that are still live after you launched the real domain.

If you're not sure what's currently exposed, our free website security check scans the live, public-facing surface of your site — no login or card required — and gives you a plain-English yes/no on anything critical.

Key takeaways

Wix and Squarespace secure the servers, SSL, and payment processing — they do not secure your account, embeds, DNS, or forgotten pages.
Turn on two-factor authentication today; weak or reused passwords are the most common way hosted sites actually get compromised.
Audit every third-party app and embed for legitimacy and remove ones you no longer use.
Add or verify SPF, DKIM, and DMARC records so nobody can spoof email from your domain.
Search site:yourdomain.com periodically to catch unlisted or forgotten pages before someone else finds them.

If you've worked through this list and want a second, human set of eyes — someone who actually clicks through your site the way an attacker would rather than running an automated scan — that's exactly what Circuit is: a $49 one-time manual audit with a full written report of what's wrong and exactly how to fix it. If you're still not sure whether your setup needs a closer look, start with our guide on whether your website is hackable or, if something already looks off, see what to do if your website's been hacked.

What Is CSRF? The Attack Using Your Login

Bug Circuit — Sat, 22 Aug 2026 23:13:15 +0000

Originally published on the Bug Circuit blog.

Cross-site request forgery (CSRF) is an attack that tricks your browser into sending a real, authenticated request to a site you're logged into—like your admin panel—without you meaning to, so the attacker can change settings, add a user, or redirect a payout using your own login session. No password is stolen. No malware is installed. Your browser just does what it's told, because it still thinks it's you.

Who this is for

This is for the owner or admin of a small business site—WordPress, Shopify, a custom-built dashboard, an indie SaaS—who wants a plain-English answer to "what is cross-site request forgery (CSRF)" and, more importantly, wants to know if their own admin panel is exposed. By the end you'll know exactly how the attack works, what a real one looks like, and the specific fix (a CSRF token) that makes it stop working.

How CSRF actually works, step by step

CSRF abuses one basic fact about browsers: when you're logged into a site, your browser holds a session cookie—a small file that proves "this browser belongs to a logged-in user"—and it attaches that cookie automatically to every request sent to that site, no matter which page told the browser to send it.

Here's the attack in practice:

You log into your site's admin panel—say, yourstore.com/admin—and leave the tab open, or close it but your session cookie stays valid.
An attacker sends you a link, or you land on a page they control, containing a hidden form or image tag that points at an action on your own site, like adding a new admin user or changing a payout bank account.
Your browser loads that hidden request. Because it's a request to yourstore.com, your browser automatically attaches your valid session cookie—it has no way of knowing the request wasn't something you meant to click.
If your site's admin panel doesn't check where the request actually came from, it processes the request as if you clicked "save" yourself.

A minimal hidden form might look like this, sitting invisibly on an attacker's page:

<form action="https://yourstore.com/admin/add-user" method="POST" id="f">
  <input type="hidden" name="username" value="attacker2">
  <input type="hidden" name="role" value="admin">
</form>
<script>document.getElementById('f').submit();</script>

You never see a form. You never click "submit." The page just loads, the script fires, and if you were logged in as an admin at that moment, attacker2 is now an admin on your site.

Three things CSRF can actually do to your site

Change a setting silently — flip your store's shipping rules, disable two-factor authentication, or change the email address that receives password resets (redirecting future account recovery to the attacker).
Add a new user or admin — the example above; once the attacker has their own admin account, they don't need your credentials at all going forward.
Redirect a payout or refund destination — on payment or invoicing dashboards, a forged request to "update bank details" or "update payout email" can quietly reroute money on the next payment cycle.

Notice what's missing from all three: your password never left your head, and no malware touched your device. This is why CSRF is easy to underestimate—it doesn't look like a "hack" from the outside. It looks like an admin action, because technically, it was one—your browser just didn't ask you first.

Why this is possible: the same-origin gap

Browsers enforce a rule called the same-origin policy, which normally stops one website from reading data from another. The problem is that same-origin policy doesn't stop a page from sending a request to another site—it only stops it from reading the response. A hidden form submission or an <img> tag pointed at a URL is a one-way request, and cookies get attached regardless of which page triggered it. OWASP's community page on CSRF has a good technical breakdown of this gap: OWASP: Cross-Site Request Forgery.

This is also why CSRF has its own entry in the industry's standard weakness catalog, tracked as CWE-352, maintained by MITRE: CWE-352: Cross-Site Request Forgery.

The actual fix: CSRF tokens (and why they work)

A CSRF token is a random, unpredictable value the server generates and embeds in every form on your own site, tied to your current session. When the form is submitted, the server checks that the token in the request matches the one it issued.

Here's why this stops the attack cold: the attacker's hidden form on their own page has no way to read the token, because reading it would require loading your admin page and inspecting its contents—which same-origin policy does block. They can forge the request, but they can't forge a valid token to go with it.

A typical implementation looks like this in the HTML your server renders:

<form action="/admin/add-user" method="POST">
  <input type="hidden" name="csrf_token" value="f3a9c1e7b2d84a...">
  <input type="text" name="username">
  <button type="submit">Add user</button>
</form>

On the server side, that token is checked against the value stored in the user's session before the action runs. No match, no action—regardless of whether the cookie was valid.

Other real defenses worth knowing about

Defense	What it does	Where to check it
CSRF tokens	Per-session random value required on every state-changing form	Custom code, most modern frameworks by default
`SameSite` cookie attribute	Tells the browser not to send the cookie on cross-site requests	`Set-Cookie: session=...; SameSite=Lax; Secure; HttpOnly` in response headers
Re-authentication for sensitive actions	Requires re-entering a password before changing payout/bank details or admin roles	Payment dashboards, account settings pages
Checking the `Origin`/`Referer` header	Server rejects requests that didn't originate from your own domain	Server-side middleware or WAF rules
No state-changing GET requests	Actions like "delete user" or "add admin" require POST, never a plain link	Code review of admin routes

None of these alone is bulletproof—SameSite=Lax still allows some top-level navigation requests through, for instance—which is why a real audit checks for CSRF tokens and cookie attributes and how sensitive actions are gated, rather than assuming one setting covers everything. You can check your current cookie and header configuration for free with our security headers scanner.

Is your site actually exposed? A quick self-check

You can spot obvious red flags yourself in a few minutes:

[ ] Open your admin panel's "add user" or "change settings" form and view the page source (right-click → View Page Source). Look for a hidden input with a name like csrf_token, _token, or authenticity_token. If you don't see one, that form may be forgeable.
[ ] Check whether any admin action can be triggered by just visiting a URL (a plain GET link) rather than submitting a form—those are especially easy to forge.
[ ] If you're on WordPress, confirm you're not running custom form handlers or plugins that skip WordPress's built-in wp_nonce_field() protection—this is a common source of CSRF gaps in older or poorly maintained plugins.
[ ] If you use a custom-built admin dashboard, ask your developer directly whether CSRF tokens are implemented on every state-changing route, not just login.

If any of this is unclear, that's exactly the kind of thing a manual review is built to catch—automated scanners often miss CSRF because they can't tell a legitimate form submission from a forged one without understanding your app's logic. Our guide to manual vs. automated penetration testing walks through why that distinction matters here specifically.

Key takeaways

CSRF doesn't steal your password—it hijacks your already-logged-in browser session to submit a real, authenticated request on your behalf.
The tell-tale sign of exposure is a state-changing form (add user, change payout, disable 2FA) with no hidden CSRF token and no re-authentication step.
CSRF tokens work because the attacker's page can never read a value they'd need same-origin access to see.
SameSite=Strict or SameSite=Lax cookies add a strong second layer, but shouldn't be your only defense—check your current settings with our security headers tool.
If you're not sure your admin panel or payment dashboard is protected, that uncertainty is worth resolving before an attacker finds it first.

If you want a straight answer on whether your specific site is exposed to this—not a generic checklist, but someone actually testing your login flows and forms—that's what a manual audit is for. Circuit is a one-time $49 human review of your whole site with exact fixes, or you can start with our free website security check if you just want a fast yes/no first.

Is Shopify Secure? What You Still Own

Bug Circuit — Fri, 21 Aug 2026 17:12:38 +0000

Originally published on the Bug Circuit blog.

Yes, Shopify's core platform is secure — but that only covers Shopify's servers, checkout, and payment processing. Everything you install, write, or click on top of it (apps, themes, staff logins, custom code) is your responsibility, and that's where most Shopify stores actually get breached.

This is for Shopify store owners, admins, and freelancers who assume "Shopify handles security" and want to know exactly where that stops. You'll get a plain map of the shared-responsibility line, a table you can point to when a client or investor asks, and a self-check you can run in the next 10 minutes.

The short answer: yes, and no

Shopify's own infrastructure is genuinely well-built. It runs as a PCI DSS Level 1 service provider, which means the servers, checkout, and card processing meet the strictest tier of the payment card industry's security standard — the same tier as major banks and processors. You don't need to manage firewalls, patch servers, or encrypt card data yourself; Shopify does that layer for you, and merchants inherit much of that compliance automatically when they use Shopify Payments and hosted checkout (Shopify's PCI compliance guide).

But "the platform is secure" and "my store is secure" are two different claims. Shopify draws a clear line, common to every cloud platform: they secure the platform, you secure what you build on it. That's the same shared-responsibility model AWS, Google Cloud, and every SaaS vendor uses — it's just rarely explained to small merchants in plain terms.

What Shopify actually secures

Servers and network infrastructure — DDoS protection, uptime, patching the underlying systems.
Checkout and payment processing — encrypted card data, PCI DSS Level 1 compliance, fraud-detection signals on Shopify Payments.
Platform-level vulnerabilities — bugs in Shopify's own core code (the admin, storefront engine, checkout) are Shopify's to find and patch.
HTTPS on your storefront — Shopify auto-provisions and renews SSL certificates for your myshopify.com and connected domains.

That's real, meaningful security — and it's why Shopify stores don't need to worry about the things a self-hosted store (say, raw WordPress with WooCommerce) has to manage manually, like server patching or SSL renewal.

What you still own

Here's where the myth breaks. Everything below sits outside Shopify's platform boundary, and a vulnerability in any of them can expose customer data, redirect checkout, or hand an attacker your admin panel — even though "Shopify" never had a bug.

Apps

Every app you install gets a scope of permissions — often read/write access to customers, orders, or even your theme code. A poorly coded or abandoned app is a door Shopify can't close for you; it's not part of Shopify's own codebase. This mirrors the exact risk category OWASP calls out as "Vulnerable and Outdated Components" — third-party code you didn't write but now depend on.

Audit installed apps quarterly under Settings → Apps and sales channels. Remove anything not actively used.
Check what data scope an app requests before installing (visible on the install screen) — a countdown-timer app doesn't need customer PII access.
Favor apps still receiving updates; an app last updated three years ago is a red flag, not a bargain.

Themes and custom Liquid

Liquid is Shopify's templating language for building themes. Custom .liquid code, injected third-party scripts (chat widgets, pixels, upsell snippets), and hardcoded API keys in theme files are all your responsibility. A common real mistake: a developer pastes a private API key into theme.liquid for a "quick fix," and it ships to every visitor's browser, publicly readable in page source.

Never hardcode API tokens or secrets in theme files — use app proxy or backend calls instead.
Remove old third-party scripts you no longer use; each one is an extra piece of code with checkout-adjacent access.
If you use Checkout Extensibility or Shopify Functions for custom logic, keep that code in a private repo with a review step before deploy, not edited live in the admin.

Staff access

Every staff account is a potential entry point. Shopify supports granular admin permissions — most stores don't use them, defaulting everyone to broad access instead.

Go to Settings → Users and permissions and give each staff member only the permissions their job needs (e.g., a support rep doesn't need "Manage settings" or theme access).
Turn on two-step verification for every staff login — Shopify has required it for account owners since 2022, and you should require it for staff too.
Remove access immediately when someone leaves — an ex-contractor with a live login is one of the most common, least glamorous breach paths.

Phishing and social engineering

Attackers don't need a Shopify vulnerability if they can just ask nicely. Fake "Shopify Support" emails asking you to "verify your account" or install a "required" app are a known pattern targeting merchants — CISA's general guidance on recognizing these tactics applies directly here: never click login links from email, always type admin.shopify.com directly, and verify unexpected requests through a second channel (CISA: Avoiding Social Engineering and Phishing Attacks).

Bookmark your admin URL instead of clicking email links to log in.
Set up SPF, DKIM, and DMARC on your sending domain so attackers can't easily spoof "you" in phishing emails to your customers — check yours with our email spoofing checker.
Train staff that Shopify will never ask for your password by email or DM.

The shared-responsibility line, at a glance

Layer	Who secures it	Real examples
Servers, network, uptime	Shopify	DDoS protection, patching, infrastructure hardening
Checkout & payment processing	Shopify	PCI DSS Level 1 compliance, card data encryption
Storefront SSL/HTTPS	Shopify	Auto-issued and renewed certificates
Installed apps	You	Permission scopes, app vulnerabilities, abandoned apps
Theme & custom Liquid code	You	Hardcoded keys, injected scripts, insecure customizations
Staff accounts & permissions	You	Weak passwords, over-broad access, ex-employee logins
Domain, DNS, email	You	SPF/DKIM/DMARC, registrar account, domain lock
Phishing awareness	You	Fake support emails, credential theft, malicious app links

10-minute Shopify security self-check

[ ] Two-step verification is on for every staff account, not just the owner.
[ ] Staff permissions in Settings → Users and permissions match actual job needs.
[ ] You've reviewed installed apps in the last 3 months and removed unused ones.
[ ] No API keys or secrets are hardcoded in your theme's .liquid files.
[ ] SPF/DKIM/DMARC are set up on your store's sending domain.
[ ] You always type your admin URL directly instead of clicking email links to log in.
[ ] Response headers on your storefront (CSP, X-Frame-Options, etc.) are reviewed — run a free check with our security headers scanner.

If you checked all seven, you're ahead of most stores. If you're not sure about several, that uncertainty is itself the finding — it usually means no one has actually looked at the store-level risks since launch. Our guide on whether your website is hackable walks through the warning signs in more depth.

When a manual look actually helps

An automated scanner can flag a missing security header in seconds, but it can't tell you that a marketing app has write access to your customer list it doesn't need, or that a staff account from a former employee is still active, or that a snippet a freelancer added two years ago is quietly loading a script from a domain that no longer exists. Those are judgment calls a human reviewer makes by actually looking at your store's configuration — the difference we cover in manual vs. automated penetration testing.

Key takeaways

Shopify secures the platform (servers, checkout, PCI compliance) — you secure everything layered on top of it: apps, themes, staff access, and your team's judgment.
Audit installed apps and their permission scopes quarterly; remove anything unused or unmaintained.
Turn on two-step verification for every staff login and scope permissions to the job, not the person.
Never click email links to log into your admin — type the URL directly, and set up SPF/DKIM/DMARC so attackers can't spoof your domain.
A missing header or an unused app with broad access won't show up by guessing — a manual review of your actual store configuration will.

If you've read this far and you're not fully sure where your store stands on the checklist above, that's exactly what a manual audit is for. Circuit, our $49 one-time review, has a real person go through your store's apps, theme code, and configuration and hand you a plain-English report of what's actually exposed — not a certification, not a guess, just what's true about your specific store right now.

WooCommerce Security Checklist for Stores

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

Originally published on the Bug Circuit blog.

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

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

The real risk isn't your server holding credit cards

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

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

The checklist: do these in order

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

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

Update discipline: the single biggest lever

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

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

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

Lock down who can log in

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

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

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

Keep card data off your server entirely

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

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

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

Add security headers your browser already understands

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

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

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

Back it up before anything else breaks

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

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

Key takeaways

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

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

How to Stop Brute-Force Attacks on WordPress Login

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

Originally published on the Bug Circuit blog.

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

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

What a brute-force attack on WordPress actually looks like

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

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

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

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

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

Step 1: Limit login attempts and lock accounts out

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

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

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

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

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

Step 3: Disable or restrict XML-RPC

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

Apache (.htaccess):

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

Nginx:

location = /xmlrpc.php {
    deny all;
}

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

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

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

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

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

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

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

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

What's mostly theater

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

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

Quick setup checklist

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

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

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

Key takeaways

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

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