Security Lessons from WordPress: Why Open by Default Breaks at Scale

Security Lessons from WordPress: Why "Open by Default" Breaks at Scale

WordPress didn't fail because it was extensible.

It succeeded because it was extensible.

But it also teaches a hard lesson that modern platform teams can't afford to ignore:

Unconstrained extensibility scales adoption faster than safety.

At small scale, that's survivable. At global scale, it becomes a systemic risk.

This post isn't a takedown. It's a case study.

Because if you're building a plugin ecosystem today—and especially if you're doing it in SaaS—you will face the same trade-offs, just in different clothes.

The uncomfortable stat that matters

Across years of ecosystem data, the overwhelming majority of serious WordPress security incidents did not originate in core.

They originated in plugins.

That's not because plugin authors were malicious. It's because the model allowed:

• arbitrary code execution,
• shared runtime and memory,
• broad access to the database,
• and little isolation between extensions.

In other words: maximum power, minimal containment.

At small scale, that feels empowering. At large scale, it becomes indefensible.

The core problem: shared blast radius

The fundamental architectural issue wasn't "plugins."

It was where plugins ran and what they could touch.

In the WordPress model:
• plugins run in the same process as core,
• share global state,
• execute on page load,
• and often run with database-level permissions.

So when a plugin fails, misbehaves, or is compromised:
• the entire site can be affected,
• sensitive data can be exposed,
• recovery is often manual and painful.

This is what "shared blast radius" looks like.

And it's the opposite of how modern platforms should behave.

Why "open by default" feels right—until it doesn't

Early on, "open by default" creates momentum:

• developers move fast,
• experimentation flourishes,
• barriers to entry are low,
• the ecosystem grows rapidly.

This is intoxicating. It feels like platform magic.

But there's a hidden cost curve.

As the ecosystem grows:
• review becomes harder,
• enforcement becomes slower,
• trust becomes fragile,
• and attackers gain leverage.

The same openness that helped you grow becomes the surface area attackers exploit.

The modern shift: from openness to containment

The most important evolution in extensible platforms over the last decade is this:

Power has not decreased.

Containment has increased.

Modern platforms didn't remove extensibility. They re-architected it.

Key shifts include:

1) From in-process code to isolated runtimes

Instead of running extensions inside the core application:
• extensions run in sandboxes,
• serverless functions,
• or isolated iframes/processes.

This ensures:
• crashes are contained,
• memory is isolated,
• performance budgets are enforceable.

Failure becomes local, not systemic.

2) From global access to scoped permissions

Rather than "full access or nothing," modern platforms use:
• explicit scopes,
• capability-based APIs,
• and permission prompts.

An extension can only touch what it's allowed to touch.

And users can understand the risk at install time.

3) From trust-by-install to trust-by-design

In older models, installing a plugin implied trust.

Modern models assume:
• plugins may fail,
• plugins may be compromised,
• plugins should be constrained accordingly.

Security is enforced by architecture, not by hope.

4) From reactive cleanup to proactive limits

Instead of chasing issues after they happen:
• rate limits prevent abuse,
• timeouts prevent runaway execution,
• kill switches enable rapid containment.

This is how you operate at scale without panic.

Why SaaS platforms can't repeat this mistake

If you're building a SaaS platform today, the WordPress-era trade-offs are no longer acceptable excuses.

Why?

Because:
• customers expect isolation,
• regulators expect controls,
• enterprises expect predictability,
• and incidents travel faster than ever.

You don't get to say:

"Well, it was a third-party plugin."

From the customer's perspective, it was your platform.

The paradox: stronger constraints enable more extensibility

This is the counterintuitive lesson most teams miss.

Strong containment doesn't reduce extensibility. It unlocks it.

Because when:
• customers trust the ecosystem,
• platform teams trust upgrades,
• developers trust the rules,

you can safely open more powerful extension surfaces.

Weak containment forces you to stay conservative forever. Strong containment lets you expand confidently.

A modern extensibility security checklist

If you're designing a plugin system today, you should be able to answer "yes" to most of these:

• Can extensions fail without affecting core?
• Are permissions explicit and minimal?
• Is runtime execution isolated?
• Can you revoke access instantly?
• Are resource limits enforced automatically?
• Can users see and understand risk at install time?
• Can you upgrade the platform without fear?

If not, your system may work at 10 plugins. It will not work at 1,000.

Forge's POV: openness without containment is technical debt

The lesson from WordPress isn't "don't be extensible."

It's:

Don't confuse openness with safety.

Modern platform leadership means:
• designing for failure,
• assuming compromise,
• and limiting blast radius by default.

Extensibility is still the future. But the future is contained, scoped, and observable.