“WordPress is insecure.” You’ve heard this a hundred times. But here’s a question: If WordPress is so insecure, why does the White House use it? Why does NASA? Why do banks and governments worldwide? Let’s separate myth from reality.
I have had this argument in more procurement meetings than I can count, usually with a CTO who has already decided and wants me to confirm it. So let me be direct about where I land before I show my work: the platform is almost never the thing that gets a site breached. The way it is run is. Get that backwards and no technology on earth will save you.
The Big Myth
The myth goes like this: WordPress is open-source, so hackers can see the code and find vulnerabilities. Custom software is secret, so it’s safer.
This is backwards.
Open-source software is reviewed by thousands of security researchers. Vulnerabilities are found and fixed quickly. Custom software hides its bugs until a hacker finds them.
“Security through obscurity is not security at all.”
— Security industry saying
I Watched “Closed Means Safe” Die With Flash
I am old enough to have built a career on a closed, proprietary runtime, so let me tell you how that argument actually ends. For years I shipped interactive work in Macromedia Flash with ActionScript — multi-user games, CD-ROM front ends, the lot. Flash was the opposite of open source in every way the “obscurity is safer” crowd would love: closed player, closed format, one vendor holding the keys. And it became one of the most relentlessly exploited pieces of software the consumer web ever ran. The source being secret did not stop attackers. It only stopped everyone else from helping.
What killed Flash in the end was not fashion, it was the security patch treadmill — an endless drip of zero-days that a single vendor had to chase alone, until the browsers simply stopped waiting. That is the whole lesson in one story. Obscurity did not make Flash safe; it made Flash a single point of failure with nobody outside the building reviewing the code. When people tell me open source is a liability because “hackers can read it,” I think of Flash, and I remember that the readers who mattered most were the ones patching it, not the ones exploiting it.
Where Do WordPress Vulnerabilities Come From?
Here’s the most important statistic you need to know:
97% of WordPress vulnerabilities come from plugins and themes — not WordPress core.
WordPress core is extremely secure. It’s maintained by Automattic and a dedicated security team. It receives regular updates. It follows security best practices.
The problem is third-party code. A free plugin made by one developer in their spare time is not the same as WordPress core. This is the number I make clients sit with, because it reframes the whole conversation: the platform is not your attack surface. Your plugin folder is.
| Source | % of Vulnerabilities |
|---|---|
| Plugins | ~90% |
| Themes | ~7% |
| WordPress Core | ~3% |
The White House Uses WordPress
The official White House website has been built on WordPress. This is the digital presence of the President of the United States.
Do you think the White House would use insecure software? They have:
- The Secret Service reviewing security
- The NSA providing guidance
- Constant attacks from nation-state hackers
- Zero tolerance for security failures
If WordPress was truly insecure, the White House would not use it. Full stop.
NASA Uses WordPress VIP
NASA uses WordPress VIP for their blogs and microsites. WordPress VIP is the enterprise-grade hosting platform that powers some of the world’s biggest sites.
WordPress VIP includes:
- 24/7 security monitoring
- Automatic security patches
- Code review for all plugins
- DDoS protection
- Regular security audits
This is not your average shared hosting. This is enterprise security.
How to Make WordPress Secure
WordPress security is not automatic. It requires proper setup. Here’s how the enterprise does it:
1. Use Quality Hosting
Cheap shared hosting = shared security problems. Enterprise sites use:
These hosts include firewalls, malware scanning, and automatic updates.
2. Minimize Plugins
Every plugin is a potential security risk. Enterprise sites:
- Use only necessary plugins
- Choose well-maintained plugins with good reviews
- Remove unused plugins completely
- Audit plugins regularly
3. Keep Everything Updated
Most hacks target old, unpatched vulnerabilities. Updates are critical:
- Enable automatic WordPress core updates
- Update plugins weekly
- Update themes
- Update PHP version
4. Use Strong Authentication
- Strong, unique passwords
- Two-factor authentication (2FA)
- Limit login attempts
- Change default admin username
5. Implement Web Application Firewall (WAF)
A WAF blocks attacks before they reach your site:
Custom Software Is Not More Secure
Here’s what people forget: Custom software has security issues too. The difference?
WordPress Vulnerabilities
- Publicly reported
- Quickly patched
- Security researchers help
- Community monitors
Custom Software Vulnerabilities
- Hidden until exploited
- Only your team can fix
- No external review
- You discover bugs the hard way
“Custom development often wins on TCO while providing better performance and security, though this can vary based on project complexity.”
— Synaptis Technologies
Notice the word “can” — custom software can be more secure. But only if you invest heavily in security testing, code reviews, and ongoing maintenance. Most companies don’t. In practice the “we’ll build it ourselves so it’s safer” line usually means “we’ll build it ourselves and never fund the audit,” which is the least secure outcome on this entire page.
Security Is a Process, Not a Product
The real truth about security:
No software is inherently secure or insecure. Security depends on:
- How it’s configured
- How it’s maintained
- How it’s hosted
- How users behave
A poorly maintained custom site is less secure than a well-maintained WordPress site. And vice versa.
The question is not “Is WordPress secure?” The question is “Are you doing security right?”
What I Actually Tell Clients Who Ask This
When a nervous stakeholder brings me the “is WordPress safe enough for us?” question, I do not answer with the platform. I answer with three questions of my own, because they predict a breach far better than the CMS name ever will.
Who owns updates, and is it in someone’s calendar? Almost every site I have seen compromised was running a plugin with a patch available for weeks that nobody applied. Security is not a decision you make once at launch; it is a chore someone has to own on a schedule. If the honest answer is “nobody,” that is the real vulnerability, and it would exist on any platform you named.
How many plugins are actually load-bearing? Given that ~90% of vulnerabilities come from plugins, the fastest security win most sites can make is deleting the six plugins they installed to try something in 2021 and never removed. Every one you remove is attack surface that no longer exists. I would rather cut a plugin than harden it.
What happens the day you are breached anyway? Mature security assumes eventual failure. Daily backups you have actually restored from, a WAF in front, monitoring that pages a human — these are what turn an incident into an inconvenience. The teams that plan only for prevention are the ones that lose a weekend when prevention inevitably slips.
Enterprise Security Checklist
If you want WordPress security at enterprise level, here’s your checklist:
- ☐ Use managed WordPress hosting (VIP, WP Engine, Kinsta)
- ☐ Enable automatic core updates
- ☐ Audit and minimize plugins
- ☐ Implement 2FA for all users
- ☐ Use a WAF (Cloudflare, Sucuri)
- ☐ Regular backups (daily minimum)
- ☐ Security monitoring and alerts
- ☐ Regular security audits
- ☐ SSL/HTTPS everywhere
- ☐ Principle of least privilege for users
Follow this checklist, and your WordPress site will be more secure than 99% of custom-built websites.
Key Takeaways
- 97% of WordPress vulnerabilities come from plugins, not WordPress core
- The White House and NASA use WordPress — they wouldn’t if it was insecure
- Open-source security is better than “security through obscurity”
- Custom software has vulnerabilities too — you just don’t know about them yet
- Security is about configuration and maintenance, not the platform
Next in this series: “50,000 Visitors Per Second: How WordPress Handles Massive Traffic” — Scaling WordPress for enterprise performance.
Sources
Last modified: August 2, 2026
United States / English
Slovensko / Slovenčina
Canada / Français
Türkiye / Türkçe