WordPress security that pays for itself on day one

The threat Critical

Brute-force attacks are the single most common vector against WordPress. Automated tools cycle through thousands of username/password combinations per minute. A default WordPress install will happily serve every one of those requests, giving attackers unlimited attempts to guess their way in.

Most plugins address this with a simple lockout counter. Lock after 5 failed attempts, wait 15 minutes, repeat. The problem? Attackers simply rotate IP addresses. A thousand different IPs each making 4 attempts never trigger the threshold.

How Bulwark handles it

Bulwark layers three mechanisms: progressive delays that make each successive failure slower (not just locked out), IP-based lockout with configurable thresholds, and username-based tracking that catches distributed attacks from multiple IPs targeting the same account.

The threat Critical

Passwords are fundamentally broken. They get reused across sites, stored in plaintext by careless services, phished through fake login pages, and leaked in data breaches. Even a strong, unique password can be stolen by a keylogger or shoulder-surfing.

The reality: 81% of data breaches involve weak or stolen credentials. If your only defence is "they need to know the password," you've already lost.

How Bulwark handles it

TOTP-based two-factor authentication adds a second proof-of-identity that changes every 30 seconds and lives on the user's physical device. Even if an attacker has the password, they need the user's phone to generate the current code.

Bulwark's implementation includes per-user enforcement (mandate 2FA for admins while leaving subscribers optional), one-time backup codes for lockout recovery, and a setup wizard that works with any standard authenticator app — Google Authenticator, Authy, 1Password, Bitwarden.

The threat

Once someone logs in, WordPress creates a session cookie and trusts it completely. If that cookie is stolen — through XSS, network sniffing, shared hosting, or browser extension malware — the attacker inherits the full session. They don't need the password. They don't need the 2FA code. They are the user.

Worse: WordPress allows unlimited concurrent sessions by default. An admin can be logged in from London while an attacker uses the same session from Moscow, and WordPress won't notice or care.

How Bulwark handles it

Every session is fingerprinted against the browser, operating system, and network characteristics of the device that created it. If a session cookie suddenly appears from a different browser or a different country, it's terminated immediately.

Concurrent session limits prevent an attacker from silently riding alongside a legitimate session. Configurable idle timeouts ensure forgotten sessions don't stay open indefinitely. And session rotation on privilege escalation means a session token used pre-login can't be replayed post-login.

The threat

A correct password from an unusual location is still suspicious. Traditional security treats authentication as binary — right password, you're in; wrong password, you're out. But context matters enormously.

If your admin normally logs in from Birmingham at 9am and suddenly a login appears from Vladivostok at 3am using the correct credentials, something is very wrong. But most security plugins will wave it through because the password was correct.

How Bulwark handles it

The risk engine scores every authentication attempt against multiple contextual signals: geographic location (using IP geolocation), time-of-day patterns, device familiarity, network characteristics, and impossible travel detection.

Impossible travel is the crown jewel. If a user logs in from London at 14:00 and an attempt appears from Tokyo at 14:30, Bulwark calculates the physical impossibility — you cannot travel 9,500km in 30 minutes — and blocks or challenges the attempt regardless of whether the credentials are correct.

The threat

The most dangerous moment in a breach isn't the initial entry — it's what happens after. Attackers inject backdoors into theme files, modify core WordPress files to create persistent access, plant web shells in upload directories, and alter plugin code to redirect traffic or skim payment data.

Without file monitoring, these changes are invisible. The attacker's backdoor survives password resets, plugin updates, and even most "security scans" because the malicious file is the scan target's own codebase.

How Bulwark handles it

Bulwark maintains a cryptographic hash baseline of every monitored file. On each scan, it recalculates hashes and compares against the baseline. Any modification, addition, or deletion is flagged immediately with precise detail: which file, what changed, and when.

Core WordPress files are verified against official checksums from wordpress.org. Custom files are tracked against their own baseline. Scans run on a configurable schedule and can be triggered manually after deployments.

The threat

Your WordPress database holds everything: user accounts, passwords, customer data, order history, payment tokens, private content, configuration secrets. A SQL injection vulnerability in any plugin — and WordPress sites average 20+ active plugins — is a direct line to all of it.

Beyond injection, the database is vulnerable to table prefix guessing (WordPress defaults to wp_), unauthorized enumeration of user data through REST API endpoints, and information disclosure through error messages that reveal table structures.

How Bulwark handles it

Bulwark hardens the database layer from multiple angles: custom table prefix enforcement (eliminating the default wp_ that every attack tool targets), database error suppression in production (no more stack traces revealing your table schema), and monitoring for suspicious query patterns.

User enumeration protection blocks the classic ?author=1 scan and REST API user listing that attackers use to harvest valid usernames before launching credential attacks.

The threat

Every response your server sends includes HTTP headers that tell the browser what's allowed. Without the right headers, your site is vulnerable to: cross-site scripting (XSS) where attackers inject malicious scripts, clickjacking where your pages are embedded in invisible frames, MIME-type confusion attacks, and information disclosure that reveals your server software and versions.

The frustrating part? These are free defences. Adding the right headers costs nothing and blocks entire categories of attack. Yet the majority of WordPress sites ship without them because they require manual server configuration that most users can't do.

How Bulwark handles it

Bulwark injects a comprehensive security header suite into every response: Content-Security-Policy to control script sources, X-Frame-Options to prevent clickjacking, X-Content-Type-Options to stop MIME sniffing, Referrer-Policy to control information leakage, Permissions-Policy to restrict browser API access, and HSTS to enforce HTTPS.

WordPress version numbers, PHP version disclosure, and server software identification headers are stripped — removing the reconnaissance information attackers use to select exploits.

The threat

When something goes wrong — and eventually it will — the first question is always "what happened?" Without comprehensive logging, you're investigating in the dark. Who logged in? What did they change? When did the modification occur? Which plugin was activated? What settings were altered?

WordPress has no built-in audit trail. None. An admin could delete every page, install a malicious plugin, and create a backdoor account, and the only trace would be the damage itself. For any business handling customer data, this isn't just a security gap — it's a compliance failure.

How Bulwark handles it

Every significant action is logged with full context: who performed it, what was changed, when it happened, and from where (IP and geolocation). This covers login/logout events, content changes, user modifications, plugin/theme management, settings changes, file uploads, and all Bulwark security events.

Logs are stored in a dedicated database table with retention policies and export capabilities. For businesses subject to GDPR, PCI-DSS, or other compliance frameworks, the audit trail provides the evidence needed to demonstrate security controls are in place and functioning.

The threat Growing fast

Bot traffic now accounts for nearly half of all web requests — and the majority of it is hostile. Content scrapers duplicate your articles and outrank you. Credential stuffing bots test stolen password lists against your login page. AI training crawlers hoover your content without permission. Inventory scalpers hit WooCommerce stores. And all of them consume your hosting resources, inflate your bandwidth bills, and pollute your analytics.

The AI boom has made this dramatically worse. Every new language model needs training data, and your content is being harvested at industrial scale by crawlers that ignore robots.txt entirely.

How Bulwark handles it

Six integrated modules working together. The Bot Firewall maintains a database of 50+ known AI crawlers, scrapers, and attack tools with per-bot allow/block/tarpit controls. Honeypot Tracker plants invisible trap URLs that real users never see but bots follow — permanently flagging the IP. Robots Guard tracks which bots actually read your robots.txt and flags those who ignore it.

The Request Rate Limiter enforces sliding-window rate limits with separate thresholds for anonymous visitors, authenticated users, and REST API calls. The Request Signature Scorer analyses HTTP header anomalies — missing Accept headers, suspicious user-agent strings, impossible browser configurations — and feeds scores into the risk engine. And the Fail2Ban Emitter writes structured log entries that integrate with Fail2Ban at the server level for IP-level blocking before requests even reach PHP.