WordPress for Financial Organizations

WordPress is secure enough for banks, credit unions and other financial organizations when it is set up, deployed and maintained with the same discipline regulators expect from every other system those institutions run.

I’ve built and maintained WordPress websites for banks and credit unions for years, including Coastal1 Credit Union, and none of them has had a security incident. That record has nothing to do with luck or one magic security plugin. It comes from stacking a lot of small, boring controls on top of each other, so a failure in any one layer never becomes a breach. This is the playbook I use, section by section.

  • Edge protection: Cloudflare in front of everything.
  • Application hardening: a custom theme and plugin that strip out what an attacker can learn or abuse.
  • Hosting: managed WordPress hosting with real compliance reports.
  • Authentication: encrypted admin logins and mandatory MFA.
  • Process: git-only deploys, change logs, a backup static site, annual audits and automated scanning.
  • Compliance: accessibility, privacy and image rights handled before they turn into lawsuits or settlement letters.

1. Cloudflare

Every financial website I manage sits behind Cloudflare. Most attacks never reach WordPress because the edge stops them first. Here is what the Coastal1 configuration covers, described generally. I don’t publish the exact rules, thresholds or paths, and you shouldn’t either.

Transport and DNS

  • TLS everywhere: Full SSL to origin, TLS 1.2 as the minimum, TLS 1.3 enabled, Always Use HTTPS and automatic HTTPS rewrites.
  • HSTS: enabled with a long max-age and preload, so browsers refuse to downgrade to plain HTTP even on the first visit.
  • DNSSEC: turned on, so DNS answers for the domain can’t be spoofed.
  • CAA records: only named certificate authorities can issue certificates for the domain.
  • SPF and DMARC: set up so phishers can’t easily send email that appears to come from the credit union.

WAF and managed rules

  • Cloudflare Managed Ruleset: covers known CMS and plugin exploits, with signatures Cloudflare updates.
  • OWASP Core Ruleset: generic protection against SQL injection, XSS and similar attack classes.
  • Exposed Credentials Check: flags login attempts that use username and password pairs already leaked in public breaches.

Custom rules

  • Admin and login challenge: suspicious visitors get a managed challenge before they ever see the WordPress login screen.
  • Rate limiting: brute force attempts on the login get cut off fast, and a broader per-IP limit protects dynamic pages from floods.
  • Sensitive file blocking: requests for dotfiles, dependency manifests, readme files and similar items are blocked at the edge.
  • Exploit probe filtering: requests for file types a WordPress site never serves (other platforms’ scripts) get challenged. These are almost always vulnerability scanners.
  • Scanner floods: abusive scanner user agents, empty user agents and known bad networks are blocked outright.
  • Form protection: pages that spammers target get a challenge and a higher security level.
  • Allowlisted scanners: the security vendors the institution pays for can do their work without tripping the rate limits.

Headers, bots and the browser

  • Content Security Policy: added at the edge with a response header transform, and skipped for logged-in admins so the editor keeps working.
  • Cross-Origin-Opener-Policy: set to same-origin.
  • Server fingerprint removed: the X-Powered-By header is stripped at the edge.
  • Super Bot Fight Mode: challenges traffic that is definitely automated and lets verified bots like Googlebot through.
  • Page Shield: watches the third-party scripts loading on the site, which is the main concern on pages where members enter information.
  • Browser Integrity Check and email obfuscation: both turned on.

Typosquat domains

Coastal1 also registered lookalike domains defensively, covering swapped characters, a spelled-out “one” and hyphenated versions. Phishing campaigns against credit union members usually start on a domain one character away from the real one. Owning those domains costs less than a single fraud investigation.

More detail is in Cloudflare caching for WordPress and on my security and performance services page.

2. WordPress modifications

The edge stops most attacks, and the application has to hold up against whatever gets past it. On Coastal1, the custom theme and a small custom tools plugin take care of this hardening, so none of it relies on a security plugin that someone could deactivate.

  • No PHP execution in uploads: any request for a .php file inside the uploads directory gets a 403.
  • User enumeration blocked: ?author=N requests get stopped. The REST API users endpoints are removed for anyone who lacks permission to list users, which closes off the email confirmation trick described in CVE-2023-5561.
  • Version disclosure removed: the generator tag goes, in both the page head and the feeds, along with the X-Pingback and X-Powered-By headers.
  • Security headers from the application: HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict Referrer-Policy, a Permissions-Policy that denies the camera and microphone, and Cache-Control: no-store on responses that must stay out of shared caches.
  • Reduced attack surface: oEmbed, emoji scripts, feed links, comments and pingbacks are all off. XML-RPC pingback methods are removed.
  • Capabilities locked down: the Customizer and the importer are disabled for everyone, admins included.
  • Scan findings fixed in code: when a third-party penetration test flags something, such as a path manipulation finding from a Qualys scan or an input sanitization issue from a vendor audit, the fix lands in the theme with a comment that cites the finding.
  • Online banking kept off WordPress: the online banking login form posts directly to the core banking vendor’s secure domain. WordPress never touches member banking credentials, and that matters more than anything else on this list.
  • Secure cookies: the few cookies the site sets get Secure and SameSite flags and short lifetimes, and they hold nothing sensitive.
  • Junk files removed after deploys: a cleanup script deletes readme.html, license.txt, sample config files and dev files that would tell a scanner which version is running.

For the broader version of this checklist, see securing a WordPress website.

3. Hosting

For a financial institution, I recommend only two hosts: Kinsta and WP Engine. Both are managed WordPress platforms. Both can hand an examiner or a vendor management team the compliance paperwork they ask for. Both handle the server layer well enough that I don’t have to.

Requirement Why it matters for a bank Kinsta and WP Engine
SOC 2 Type II report Vendor due diligence and third-party risk management Both provide one
Isolated environments One compromised site can’t reach another Both
Staging environments Changes get tested before they reach members Both
Git or SSH deploys Production changes come only from version control Both
Daily backups with retention Recovery and continuity planning Both
Server-level caching and CDN Performance under traffic spikes and DDoS absorption Both
Platform-level firewall and malware scanning Defense in depth behind Cloudflare Both

Shared hosting, a self-managed VPS or a general cloud host can work in theory. In practice they hand the institution’s IT team a server to patch, monitor and document, which isn’t the business a credit union is in. I compare the two in more depth in Kinsta vs WP Engine.

4. Client-side encryption and MFA for admin logins

The WordPress login is the most valuable target on the site, so it gets two extra layers.

Client-side encryption of admin credentials

TLS already encrypts the login in transit. Encrypting credentials in the browser before submission adds another layer on top of that, so the plaintext password never appears in request bodies. That keeps it out of anything that can see decrypted traffic: proxies, TLS-inspecting firewalls on a corporate network, browser extensions, request logs. Credentials that leak into a log file somewhere are a very common real-world exposure, and this closes that hole.

MFA with Google Authenticator

Every admin account requires a time-based one-time code. I use the Google Authenticator plugin, specifically the actively maintained fork on GitHub by Ivan Kruchkoff, which builds on Henrik Schack’s original plugin. It’s small, dependency-light and does one job. It works with any TOTP app (Google Authenticator, 1Password, Authy, Microsoft Authenticator).

The FFIEC’s 2021 guidance on authentication and access directs institutions to use multi-factor authentication for high-risk users, and it specifically calls out administrators and other privileged accounts. A WordPress administrator account is privileged access to a public system that carries the institution’s brand.

I cover the options in more depth in WordPress two-factor and SSO authentication.

5. Minimal code

Every plugin is code you didn’t write, didn’t review and have to trust. Most WordPress vulnerabilities live in plugins, not in WordPress core. So the most effective security control I have is to install less.

  • Custom theme: built for the institution, with no page builder, no theme framework and no bundled plugins.
  • Few plugins, each with a clear job: forms, search, SEO, MFA, an activity log, SVG sanitization and redirect safety. Every plugin has to justify its place.
  • Custom functionality in a custom plugin: rate tables, calculators and integrations live in code I wrote and can audit, not in a marketplace plugin with 40 settings screens.
  • No abandoned plugins: any plugin that hasn’t been updated recently gets replaced or rewritten.

I wrote about why this works in the WordPress security fallacy. It also explains why a plugin changing ownership is a real risk, as the Advanced Custom Fields takeover showed.

6. DevOps

How code gets to production matters as much as what that code is.

  • Read-only file system: production code can’t be changed from inside WordPress. Nobody can install plugins, edit theme files or apply updates from the dashboard. If an attacker gets an admin login, they still can’t drop a backdoor into the codebase.
  • Git deploys only: the only way code reaches production is a git push to the host. Every change has an author, a timestamp, a message and a diff. A change that isn’t in git doesn’t exist, and anything on the server that doesn’t match git is a red flag.
  • Staging and test environments with database sync: updates and new features go to staging first, on a fresh copy of the production database, so the test is realistic. Database dumps never get committed to the repository.

Locking down the file system at the WordPress level looks like this in wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
define( 'FORCE_SSL_ADMIN', true );

The git workflow itself is covered in Kinsta git push deployment.

7. Change logs

When an examiner, an auditor or the marketing VP asks “who changed this and when?”, you need an answer that doesn’t rely on anyone’s memory. I install the Stream plugin (originally built by XWP) on every financial site. It records every meaningful action in the admin:

  • Logins, failed logins and logouts
  • Content created, edited, published and deleted
  • User accounts created, changed and removed, and role changes
  • Plugin and setting changes
  • Media uploads and deletions

Git logs the code. Stream logs everything people do in the dashboard. Between the two, any change to the website can be traced to a person.

8. A backup static site

Regular backups protect against data loss. They don’t solve the harder problem: what does the institution show the public when the WordPress site itself is compromised, defaced or offline?

My answer is a static HTML copy of the full website, kept current and hosted completely separately from WordPress. If the site is ever taken over, DNS gets repointed to the static copy in minutes. Members still see accurate rates, branch hours, phone numbers and the online banking login, while the real site gets cleaned up offline with no time pressure.

  • A static site has no database, no PHP and no login, so there’s essentially nothing to attack.
  • The DNS change is documented ahead of time, so anyone on the takeover plan can make it.
  • Keep the static copy current on a schedule. A stale backup site showing last year’s rates is its own problem.

See how to back up WordPress and a simple Node static server for the building blocks.

9. Annual audits

Security drifts. People leave, vendors change, passwords get shared in a pinch and never rotated. Once a year, I run an audit with the institution:

  1. Rotate every password: WordPress admins, hosting, Cloudflare, DNS registrar, SFTP and SSH, and any API keys the site uses.
  2. Review the takeover plan: confirm who does what if the site is compromised, check the static backup works, and make sure the DNS repoint steps are still accurate.
  3. Confirm the institution can regain access: the credit union, not the vendor, must own and be able to recover the hosting, Cloudflare, domain registrar and Google accounts. Test the recovery paths for real.
  4. Remove former staff and vendors: compare every WordPress user, hosting user and Cloudflare member against the current staff list and remove anyone who has left.
  5. Force password rotation: make every remaining user set a new password, and confirm MFA is still enrolled on every account.
System What to check
WordPress User list, roles, MFA enrollment, inactive accounts
Hosting (Kinsta or WP Engine) Account owner, users, SSH keys, git deploy keys
Cloudflare Account members, API tokens, WAF rules still match the site
Domain registrar Owner, registrar lock, renewal date, typosquat domains renewed
Google (Tag Manager, Analytics, Search Console) Users and owners, ownership held by the institution

10. Accessibility

Banks and credit unions are among the industries hit hardest by ADA website accessibility lawsuits and demand letters. Accessibility isn’t optional for a financial website. It’s a legal requirement and a customer service obligation.

  • Target WCAG 2.2 Level AA: it’s the current W3C recommendation and the standard demand letters and settlements point to.
  • Build it into the theme: semantic HTML, real heading structure, keyboard navigation, visible focus states and sufficient color contrast all belong in the code, not a bolt-on overlay widget.
  • Accessible forms and calculators: loan calculators, rate tables and application forms are where financial sites usually fail. Test them with a screen reader.
  • PDFs count too: disclosures and rate sheets need to be accessible or have accessible HTML versions.
  • Test on a schedule: automated scans catch maybe a third of issues. Manual keyboard and screen reader testing catches the rest.

My testing process is in how to test a website for ADA compliance, and the service is on my accessibility consultant page.

11. Cookies and privacy

Financial institutions run marketing tags like everyone else: Google Ads, Meta, LinkedIn, analytics, chat widgets. Every one of them is a privacy obligation under GDPR, CCPA and CPRA, and a growing list of state privacy laws.

  • Load tags through Google Tag Manager: one controlled container, owned by the institution, instead of scripts pasted into the theme. See my Google Tag Manager consultant page.
  • Use Google Consent Mode v2: tags respect the visitor’s choice, and Google can still model conversions for visitors who decline. See Consent Mode in Google Tag Manager.
  • Run a real consent banner: one that actually blocks tags before consent where the law requires it. Plenty of banners only display a message. I explain my approach in self-hosted cookie consent management and HubSpot Consent Mode attribution.
  • Audit what actually loads: Blacklight, a free tool from The Markup, scans any URL and reports the trackers, third-party cookies, session recorders and fingerprinting scripts it finds. Run it against your own site. You’ll probably be surprised.

For help with this, see my privacy and consent consultant page.

12. Image rights management

This one catches institutions off guard. Copyright enforcement firms crawl the web looking for licensed stock photos, then mail settlement demand letters, often for thousands of dollars per image. A banner photo a marketing coordinator uploaded six years ago can turn into a legal bill today.

  • Log every image’s source: for each image in the media library, record where it came from, the license, the purchase or download date and who added it.
  • Keep the license documentation: invoices, license certificates or download receipts, kept somewhere the institution can find them years later.
  • Audit the media library: on a schedule, find images with no documented source and either document them or remove them.
  • Respond with evidence: when a settlement letter arrives, a documented license usually ends the conversation.

13. WPScan

WPScan is the WordPress security scanner and vulnerability database that most of the WordPress security world relies on. Ryan Dewhurst started it as an open source scanner, and Automattic, the company behind WordPress.com, acquired it in 2021. Its team of WordPress security researchers maintains the largest database of known WordPress core, plugin and theme vulnerabilities.

I run WPScan checks daily against the plugins and themes installed on each financial site. When a vulnerability is disclosed in something we run, I find out the same day and can patch, mitigate at the Cloudflare edge or remove the plugin before an exploit spreads.

14. Claude and ChatGPT

AI models are now good enough to do a useful first pass security review of a WordPress codebase. I use the Claude and ChatGPT APIs to scan custom theme and plugin code for issues like missing escaping, missing capability checks, unsafe database queries, hardcoded secrets and trust in spoofable headers.

  • Automate it: the scan runs on a schedule and on code changes. It doesn’t wait for someone to remember to do it.
  • Use the APIs: API usage under commercial terms gives you clearer data handling commitments than pasting code into a consumer chat app.
  • MCP is possible, and it needs caution: connecting an AI agent directly to a production WordPress site or hosting account through MCP gives it live access to a financial institution’s systems. If you do it at all, start with read-only scopes on a staging copy, never production credentials.
  • A person reviews every finding: AI flags issues, and a developer confirms and fixes them.

More on how I use these tools in writing good website code with AI and Claude Code CLI.

Conclusion

WordPress is secure for enterprise organizations, banks and credit unions. The platform isn’t the risk. The risk is how it gets built, deployed and maintained: too many plugins, shared admin passwords, edits made directly on the live server, no MFA, no edge protection, no plan for a bad day. Fix those, and WordPress holds up as well as any other system the institution runs.

I’ve personally built and maintained WordPress websites for banks and credit unions using everything in this article, and none of them has had a security incident. If your institution wants that same setup, take a look at my website management for banks and credit unions service.

References