WordPress security writing throws around a lot of terms without ever quite stopping to explain them, WAF, brute force, zero-day, nonce, thrown into a sentence as if everyone already knows exactly what they mean. This is the page that actually explains them, properly, not a one-line dictionary entry but enough depth to understand why each thing exists and what it actually does.
Grouped by theme rather than strict alphabetical order, since most of these terms make more sense next to their neighbors than sandwiched between unrelated ones.
Attack Types
Brute force attack. An attacker, almost always an automated bot rather than a human, tries a large number of username and password combinations against a login form until one works. WordPress has no built-in limit on login attempts, an attacker can try 10,000 guesses in a row and the software will happily process every single one. This is why login attempt limiting exists as a standard feature in nearly every WordPress security plugin, it turns an unlimited automated attack into a slow, impractical one by temporarily locking out an IP after a handful of failures.
Credential stuffing. A specific variant of brute forcing that uses real username/password pairs leaked from a completely different, unrelated breach, betting that people reuse passwords across sites. Unlike a generic brute force attempt, credential stuffing often succeeds on the first or second try, because the password genuinely was correct somewhere once. This is the strongest practical argument for unique passwords per site and for two-factor authentication, which stops a correctly guessed (or stolen) password from being enough on its own.
SQL injection. An attack where malicious SQL code gets inserted into a data input (a form field, a URL parameter) in a way that tricks the underlying database into executing it. It’s consistently ranked among the most serious web application risks by OWASP’s Top 10, the industry-standard reference for web security risks. WordPress’s own core APIs ($wpdb->prepare(), for instance) are built to prevent this by properly escaping user input before it ever reaches the database, so most modern SQL injection vulnerabilities in the WordPress ecosystem come from poorly written plugins or themes that bypass those safe APIs and build raw SQL queries by hand.
Cross-site scripting (XSS). Also a perennial fixture on that same OWASP list, an attack where malicious JavaScript gets injected into a page and then runs in another visitor’s browser, often used to steal session cookies or perform actions as a logged-in user without their knowledge. WordPress core sanitizes and escapes output extensively to prevent this, but a plugin or theme that outputs user-submitted content without escaping it (a comment field, a custom field, a URL parameter reflected back onto the page) can reopen the door.
Object injection. A more obscure but genuinely dangerous class of attack, where attacker-controlled data reaches PHP’s unserialize() function, and a class already loaded on the site has a __wakeup() or __destruct() method that can be abused as part of what’s called a gadget chain, doing something the code was never intended to do. WordPress’s own coding standards specifically discourage passing serialized data through request parameters for exactly this reason. Detecting this reliably is trickier than most attack types, since which specific classes have exploitable chains changes depending on exactly what’s installed on a given site, so a fixed list of “known bad classes” goes stale fast, better detection looks for the structural signature itself (a serialized PHP object header, distinct from a serialized array) appearing somewhere it shouldn’t.
Botnet. A large network of compromised devices, often ordinary consumer routers, IoT devices, or other hacked servers, controlled remotely and used collectively to carry out attacks at a scale no single machine could manage alone. Most of the automated traffic hitting any given WordPress site’s login page, from brute-force login attempts to credential-stuffing to reconnaissance scans probing for known vulnerable plugins, comes from botnets rather than a single attacker sitting at one machine. This matters practically: since the traffic originates from thousands of different, genuinely distinct residential and hosting IPs rather than one obvious source, IP-based blocking alone struggles against a real botnet attack, catching one address does nothing to stop the next thousand. It’s part of why aggregate anomaly detection, comparing a site’s total failed-login rate against its own historical baseline rather than relying on any single IP crossing a threshold, exists as a separate layer from simple per-IP rate limiting.
DDoS attack (Distributed Denial of Service). An attempt, frequently carried out using a botnet (see above), to overwhelm a site’s server with sheer volume of traffic, from many sources at once, until it can no longer respond to legitimate visitors. This is fundamentally different from most attacks on this list because it’s not trying to get in, it’s trying to take the site down. A WordPress plugin, running inside WordPress itself, can’t stop traffic that’s already consumed the server’s bandwidth before WordPress even loaded, that’s genuinely a job for an edge/DNS-level service like Cloudflare, which filters at the network edge before traffic ever reaches the origin server.
Zero-day vulnerability. A security flaw that’s actively being exploited before a patch exists, or before the software’s developers even know about it. The name refers to the fact that developers have had zero days to fix it. Real-world zero-day exploitation and known vulnerability data across software generally, WordPress included, gets tracked and cataloged in resources like MITRE’s CVE database, the standard reference most vulnerability scanners (including WordPress-specific ones) draw from. This is the hardest category of threat to defend against by definition, since it’s unknown, but layered defenses (a firewall catching the exploit attempt itself, a scanner catching the resulting file change) can still catch the consequences even when the specific vulnerability wasn’t known in advance.
Malware and Compromise
Malware. Malicious code planted on a site, usually after some other vulnerability has already been exploited to gain write access. On WordPress specifically, this commonly takes the form of a backdoor file disguised as a legitimate plugin or theme file, injected code that redirects visitors to spam or scam sites, or a script that sends spam email from the compromised server.
Backdoor. A specific type of malware built to give an attacker continued, hidden access to a site even after the original vulnerability that let them in gets patched. A backdoor is often a small, deliberately unremarkable-looking PHP file, sometimes with a name close to a legitimate WordPress file, that accepts commands from the attacker without needing to log in through the normal admin path at all.
Uploads folder PHP execution. Not a specific attack but a specific, very common weakness that enables one. WordPress core has never needed to execute PHP files inside wp-content/uploads/, that folder is meant for media, not code. A malicious PHP file disguised as an image, uploaded through a form or a vulnerable plugin, then requested directly to actually execute, is one of the most common real-world compromise routes. Blocking PHP execution in that one folder specifically closes off an entire category of exploit regardless of which plugin vulnerability got the file uploaded in the first place.
File integrity monitoring. The practice of comparing a site’s actual core WordPress files against the official, known-good checksums published by WordPress.org, to detect when a file has been modified without authorization. A mismatch doesn’t automatically mean a hack, sometimes it’s a host patching core files for its own reasons, but it’s the single most reliable signal that something changed outside the normal update process. Auto-restoring a mismatched file is powerful but genuinely risky if done carelessly, a responsible implementation backs up the file currently on disk before overwriting it, so a false positive doesn’t turn into permanent data loss.
Authentication and Login Security
Two-factor authentication (2FA). Requiring a second piece of proof beyond a password before granting access, typically a time-based code from an authenticator app, or increasingly, a passkey. The security value is specific: even a correctly guessed or stolen password stops being enough on its own. NIST’s digital identity guidelines, the US government’s own standard reference for authentication security, specifically call out SMS-delivered codes as a weaker method than an authenticator app or a hardware-bound credential, since a SIM-swap attack can redirect someone’s phone number to an attacker without ever touching the account itself. For a deeper look at how this actually works and how different implementations compare, see WordPress 2FA plugins compared.
Passkey. A cryptographic key pair built on the WebAuthn/FIDO2 standard. The private half never leaves the user’s device, the public half is the only thing the site ever stores. Because the credential is cryptographically bound to the site’s exact domain, a phishing page, even a pixel-perfect fake, structurally can’t capture anything reusable from it. For the technical detail on how this actually gets implemented, see WordPress passkey login explained.
WebAuthn. The web standard, developed jointly by the W3C and the FIDO Alliance, that passkeys and hardware security keys are built on. It defines exactly how a browser, a website, and an authenticator (a device’s fingerprint sensor, Face ID, a physical USB key) communicate to prove possession of a private key without that key ever leaving the device or being transmitted anywhere.
FIDO2. The umbrella name for the broader passwordless authentication initiative that WebAuthn is the web-facing part of, developed by the FIDO Alliance. In practice, “FIDO2” and “WebAuthn” get used almost interchangeably in WordPress plugin descriptions, WebAuthn is technically the specific browser API, FIDO2 is the wider standard it belongs to.
Session hijacking. Once someone’s already logged in, whether legitimately or through a stolen session, an attacker who can obtain that active session (through a stolen cookie, an unsecured network, malware on the device) can act as that user without ever needing their password or 2FA code again. This is a genuinely different problem from login security, since it happens after authentication has already succeeded, most 2FA implementations stop caring the moment the second factor is verified, and a session hijacked five minutes later is invisible to them. A more complete defense monitors for characteristics of a hijacked session after login too, not just at the login moment itself, with the option to force a logout if something looks wrong.
Nonce. In WordPress specifically, a “number used once,” a token generated per-request to verify that a form submission or an action actually came from a legitimate page the user was shown, not a forged request from somewhere else (see CSRF, below). WordPress’s nonce system is built around an already-authenticated user context, which creates a genuine gap during multi-step login flows, between a correct password and a completed 2FA check, there isn’t an authenticated session yet, so the standard nonce system doesn’t apply, and that specific gap needs its own CSRF-equivalent protection, typically a separate random token issued server-side and checked with a timing-safe comparison function rather than a simple equality check, since comparing secrets with == can leak timing information a patient attacker could exploit.
CSRF (Cross-Site Request Forgery). An attack that tricks a logged-in user’s browser into submitting a request they never intended to make, by exploiting the fact that browsers automatically attach cookies to requests regardless of which site technically initiated them. WordPress’s nonce system exists specifically to prevent this for authenticated actions.
Detection and Defense Mechanisms
WAF (Web Application Firewall). Software that inspects incoming requests and blocks ones matching known attack patterns, before they ever reach the application itself. WAFs come in two structurally different shapes, worth understanding the difference: a DNS-level (edge) WAF like Cloudflare sits in front of the server entirely, filtering traffic before it consumes any server resources at all, while an application-level WAF is a plugin running inside WordPress, inspecting requests after they’ve already arrived. Neither is strictly better, they solve different problems, an edge WAF can absorb a volumetric attack an application-level one structurally can’t, while an application-level plugin can see WordPress-specific context (which user is logged in, which file just changed) an edge service has no visibility into.
Rate limiter. A mechanism that tracks how many requests a given IP has made in a time window and temporarily blocks it once a threshold is crossed. The implementation detail that actually matters for performance: many rate limiters rely on WordPress’s built-in transients, which silently fall back to the database whenever the host has no external object cache configured, meaning the very feature meant to protect a site from a flood of requests can itself become a database query on every single request, competing with the queries a site’s actual content needs to load. A well-built rate limiter tries a fast in-memory store first (APCu, common even on budget shared hosting, though worth verifying it’s actually functional with a real store-and-fetch test rather than just checking the function exists), falls back to file-locked counters in the system temp directory if that’s unavailable, and only touches the database as a genuine last resort.
Honeypot. A fake, non-functional entry point built specifically to be found only by something scanning or probing, never by a legitimate visitor following the site’s real navigation. Because there’s no legitimate reason to ever interact with one, a honeypot has close to a zero false-positive rate, unlike a heuristic pattern match, which can occasionally flag genuine traffic, hitting a honeypot has essentially no innocent explanation.
Canary trap. A close relative of the honeypot, specifically planting fake versions of paths attackers commonly probe for directly, /wp-config.php.bak, /.env, /backup.zip, /.git/config, files that would be genuinely damaging if they were real, but don’t actually exist on a properly configured site. Nobody, not a real visitor, not a search engine, not a legitimate integration, has any reason to ever request one of these. A hit is about as close to a zero-false-positive signal as exists in this field.
Threat intelligence. Data about known-malicious IPs, domains, or infrastructure, gathered and shared across many sites or organizations, used to block traffic before it’s even had a chance to do anything suspicious on this specific site. The value is speed, an IP already flagged as malicious elsewhere can be blocked here immediately, without needing to wait for it to misbehave first. This works best as one signal among several rather than the sole basis for blocking, a shared blocklist can occasionally include a stale or misattributed entry, so pairing it with site-specific signals (an actual failed login, an actual canary trip) keeps a single bad data point from being the entire basis for a decision.
Geo-blocking (country blocking). Restricting access based on the visitor’s apparent country of origin, determined from their IP address. Useful when a site genuinely has no legitimate audience or customers in certain regions, since a large share of automated attack traffic originates from a relatively small number of countries and hosting/datacenter ranges. Not a complete defense on its own, a determined attacker can route through a VPN or a server in an allowed country, but it does meaningfully reduce the volume of blind, automated probing a site sees.
Audit log. A record of security-relevant events, logins, file changes, setting changes, kept specifically so a site owner can reconstruct what actually happened during or after an incident. A genuinely trustworthy audit log needs to be tamper-evident, meaning an attacker who gains access can’t simply edit the log to cover their tracks, typically achieved by hash-chaining each entry to the one before it, so any retroactive edit breaks the chain and becomes detectable.
XML-RPC. A remote communication protocol built into WordPress, used by things like the WordPress mobile app, the Jetpack plugin, and some third-party publishing tools to interact with a site without going through the normal web login form. It’s also a common target for brute-force and amplification attacks, since a single XML-RPC request can sometimes attempt multiple login combinations at once (the system.multicall method being the classic example). If nothing on a given site actually uses XML-RPC, disabling it removes a real, commonly-targeted attack surface for no functional cost.
Why This Matters More Than It Sounds
None of these terms exist in isolation, most real WordPress compromises involve several of them chained together: a credential-stuffed login, followed by a backdoor upload, followed by malware redirecting traffic, discovered eventually through file integrity monitoring. Understanding each piece individually is what makes the whole picture, and the actual defenses worth having, make sense.
It’s also worth noticing which of these terms describe an attack and which describe a defense, because the honest mapping between the two isn’t always one-to-one. A single defense, like a composite threat-scoring system that weighs multiple weak signals together, can meaningfully raise the cost of several different attack types at once (a brute-force attempt, a reconnaissance sweep, a botnet-driven credential-stuffing run) without any one of those signals being reliable enough to act on alone. Conversely, some attacks, object injection being the clearest example, resist any single clean defense entirely, and instead get addressed by removing the conditions that make them possible in the first place (not passing serialized data through request parameters) rather than trying to detect the attack itself after the fact.
That’s the actual shape of WordPress security in practice: not one silver-bullet feature, but a set of layered, individually imperfect defenses that together make a compromise meaningfully harder, slower, and more likely to be caught, even though no single one of them, on its own, would stop a determined attacker.
SecondGate implements a genuine version of most of what’s covered above. Passkeys, standard 2FA, brute-force lockout, and country blocking are free forever. The more advanced layer, canary traps, file integrity monitoring with backed-up auto-restore, tamper-evident audit logging, and threat intelligence, sits in a Pro tier at £39.99/year.
