The Security Spec That's Actually a WordPress Problem List

Website security specifications tend to look impressive. Detailed requirements. Specific technical measures. Named plugins and configuration steps. It all reads like a thorough set of best practices.

Until you look at what each item is actually doing.

Most of the security specs we see in website briefs aren't lists of universal security best practices. They're lists of WordPress-specific mitigations. Damage control for known weaknesses in one platform, presented as though they apply to every website.

The distinction matters, especially if you're choosing a platform for a new build.

Walking through the typical spec

Change the admin URL. WordPress uses /wp-admin as its login page. Every automated bot on the internet knows this. Changing it to something less predictable reduces brute-force attempts. This is a WordPress-specific fix. On platforms that don't use a predictable, publicly documented admin path, it's not an issue.

Disable XML-RPC. XML-RPC is a legacy feature WordPress ships with by default. It was designed for remote publishing but it's now primarily used as a brute-force attack vector because it allows multiple login attempts in a single request. The standard advice is to disable it via a plugin or server config. On platforms that don't have XML-RPC (because why would they?), this line in the spec is meaningless.

Disable the file editor. WordPress includes a built-in code editor in the admin panel that lets anyone with admin access edit theme and plugin files directly. If an attacker gains admin access, they can inject malicious code through this editor. The standard advice is to disable it. On platforms that don't ship with an in-admin code editor, the attack vector doesn't exist.

Install a security plugin. Wordfence, iThemes Security, Sucuri. WordPress needs a plugin to provide basic security features like brute-force protection, file integrity monitoring, and malware scanning. The fact that a security plugin is considered essential rather than optional tells you something about the platform's baseline security posture.

Change the database prefix. WordPress uses "wp_" as the default database table prefix. Changing it makes certain SQL injection attacks harder to execute. This is a WordPress-specific hardening step that's irrelevant on platforms with different database architectures.

Limit login attempts. WordPress doesn't limit login attempts by default. Without a plugin or server-level configuration, an attacker can try as many username and password combinations as they like. Most modern platforms include rate limiting and account lockout as standard.

Universal vs platform-specific

To be fair, some items you'll find in security specs are genuine universal best practices. Using HTTPS. Keeping software up to date. Using strong passwords. Implementing proper user permissions. Running regular backups. These apply to every platform.

But the items listed above? They're not universal. They're specific to WordPress. They exist because WordPress has design decisions and legacy features that create attack surfaces other platforms don't have.

That's not a criticism of WordPress itself. It's a content management system that powers a huge share of the web, and its openness is part of what made it successful. But that openness comes with trade-offs, and a security spec should make those trade-offs visible rather than treating them as industry-standard requirements.

What security looks like on a different platform

On the CMS we've built and maintain, most of the items in a typical WordPress security spec are irrelevant because the attack vectors they address don't exist.

There's no XML-RPC. There's no in-admin file editor. There's no plugin marketplace bringing third-party code with unpredictable security standards. Content Security Policy (CSP) headers are set on every response. Brute-force protection with per-account lockout and per-IP rate limiting is built in. Automatic alert emails fire when login thresholds are exceeded. IP blocking is available from the admin panel with one click. Login attempts are logged. Media uploads are validated with MIME checking. Sessions can be terminated across all devices if a compromise is suspected. And there's a full audit log for settings changes.

None of this required a plugin. It's part of the platform.

Laravel's security model (which underpins our CMS) handles CSRF protection, SQL injection prevention, and XSS protection at the framework level. Statamic, another Laravel-based CMS, takes a similar approach and adds the benefit of flat-file storage, which further reduces the attack surface by removing the database as a target entirely.

What this means for your next brief

If you're writing a security specification for a new website, or reviewing one, ask this question for each line item: is this a universal security requirement, or is this fixing a known weakness in a specific platform?

If most of your spec is in the second category, it might be worth considering whether the platform is the right starting point. Not because WordPress is insecure when properly maintained. But because a significant portion of the effort and cost of making it secure is dealing with problems that don't exist on other platforms.

If you're writing a security spec for a new site, or reviewing one, and you'd like a second opinion on whether the requirements match the platform, get in touch. We're happy to take a look. You can also see how we approach web projects.