Healthcare Website Security. Prevent PHI Leakage and Reduce Risk

Healthcare websites face a category of security threats that general business websites don’t. Patient data, credential access, and the trust that a medical practice carries make healthcare sites attractive targets. This guide covers the specific threats, the three layers of website security, and exactly how to protect your practice’s digital infrastructure.

Why Healthcare Websites Are Attractive Targets

Healthcare data is among the most valuable personally identifiable information on the dark web. A healthcare website sits at the front door of a practice’s digital ecosystem. Attackers target it for several specific reasons.

Patient Data in Inquiry Forms

Appointment request forms collect name, phone number, condition or reason for visit, and sometimes insurance information. That combination has genuine black market value. A breach that exposes form submission data isn’t just a reputation problem. It’s a data security event with regulatory consequences.

Credential Theft Through Patient Portals

Many practice websites link to or host patient portal login pages. Phishing pages that mimic your portal login can harvest patient credentials. Attackers also target admin login pages to gain access to the site itself and the data it contains.

Reputation Attacks

Defacing a healthcare website, replacing content with malicious or embarrassing material, causes immediate patient trust damage. For a medical practice, where reputation is built over years, a defacement incident can affect patient volume for months after remediation.

Network Pivot Points

Practices that run integrated EHR systems, practice management software, or connected medical devices on the same network as their website server face a higher-order risk. A compromised website server can be used as a foothold to probe deeper into the network. This is the ransomware entry scenario that has shut down healthcare organizations at significant scale.

The Three Layers of Healthcare Website Security

Security for a healthcare website operates at three layers: the server where the site lives, the application (WordPress), and the data the site collects. Each layer has its own attack surface and its own set of controls.

Layer 1. Server-Level Security

Choose Managed Hosting Over Shared Hosting

Managed WordPress hosting providers (WP Engine, Kinsta, Nexcess, and similar) include server-level firewalls, DDoS protection, automated malware scanning, and daily backups as baseline features. Shared hosting provides none of these adequately. For a healthcare practice, managed hosting is not a luxury. It’s the right baseline.

Use SFTP, Not FTP

FTP transmits credentials in plain text. Anyone monitoring the connection can capture your username and password. SFTP encrypts the connection. Your hosting provider supports SFTP. Use it exclusively for file transfers.

SSH Key Authentication

For server access via SSH, use key-based authentication instead of passwords. SSH keys are mathematically far more difficult to compromise than passwords and eliminate the brute force attack vector on SSH access entirely.

Layer 2. Application-Level Security (WordPress)

Keep Everything Updated

Outdated plugins account for 56% of WordPress hacks. WordPress core, plugins, and themes all receive security updates. Applying these updates promptly is the single highest-impact maintenance action you take. An update that patches a known vulnerability eliminates the entire attack surface for that vulnerability immediately.

Remove Unused Plugins

An inactive plugin is still installed on your server. If it contains a vulnerability, attackers can exploit it regardless of whether you’ve activated it in WordPress. Deactivate and delete plugins you don’t use. There’s no benefit to keeping them and a real security cost to doing so.

Web Application Firewall

A web application firewall (Wordfence or Sucuri WAF) sits in front of your site and blocks common attack patterns before they reach WordPress. SQL injection, cross-site scripting, and known exploit attempts are blocked at the firewall layer. For healthcare sites, a WAF is a required layer of defense, not optional.

Limit Login Attempts

Brute force attacks against WordPress admin login pages try thousands of username and password combinations. Limiting login attempts to 3 to 5 tries before a lockout prevents this attack vector entirely. Wordfence includes this feature. There are also dedicated plugins for login attempt limiting.

Two-Factor Authentication for All Admin Accounts

Every account with WordPress admin or editor access should require two-factor authentication. Even if a password is compromised, an attacker cannot access the account without the second factor. This is non-negotiable for healthcare sites where admin access means access to form submission data and site content.

Strong Passwords and No Default Admin Username

Attackers automatically try the username “admin” because it’s the WordPress default. Change it during initial setup or immediately after discovery. All passwords should be generated by a password manager (16+ random characters). No dictionary words, no predictable patterns.

Disable XML-RPC If Not Needed

XML-RPC is a WordPress feature that allows remote connections to the site. It’s a common attack vector for credential brute forcing because it doesn’t respect login attempt limits by default. If you don’t use XML-RPC (most practices don’t), disable it via a plugin or server configuration.

HTTPS on Everything

HTTPS must be enforced across every page of your site, including admin pages, contact forms, and any patient-facing content. HTTP connections transmit data in plain text. Every appointment form submission, login, and page visit on HTTP is readable by anyone monitoring the network connection. A valid SSL certificate and proper HTTPS redirect is baseline in 2025.

Layer 3. Data Security for Healthcare Websites

What Data Does Your Website Collect?

Start by auditing every form on your site. What information does each one collect? Name and email for a newsletter? That’s low risk. Name, phone, reason for visit, and insurance carrier for an appointment request? That combination may qualify as protected health information (PHI) depending on the context and your attorney’s assessment.

Three Options for Appointment Form Data

Once you know what your forms collect, you have three approaches to managing the data:

• Email-only delivery, no database storage. Configure Gravity Forms or Contact Form 7 to send form submissions directly to your email address without storing them in the WordPress database. This eliminates the database as a point of exposure. The tradeoff is no backup of form submissions if an email is lost.
• Database storage with encryption. If you need to store form submissions in WordPress for review later, use a plugin that encrypts form data in the database. Gravity Forms with the GravityEncrypt add-on provides this. Encrypted data in a compromised database is significantly less useful to an attacker.
• HIPAA-compliant form solution with BAA. Services like IntakeQ, Hushmail, or similar HIPAA-compliant form platforms handle PHI properly and will sign a Business Associate Agreement. If your forms collect significant health information, this is the appropriate tier.

HIPAA and Your Website. What Actually Applies

Most practice websites are not directly covered entities under HIPAA simply by virtue of existing. HIPAA applies when a website creates, receives, maintains, or transmits ePHI (electronic protected health information). A standard appointment request form that collects name, phone, and preferred appointment time likely does not constitute PHI. A form asking about symptoms, diagnoses, or treatment history likely does. The gray area is large, and the legal stakes of getting it wrong are significant. Consult a healthcare attorney with specifics about your forms and use case.

Incident Response. What to Do If Your Site Is Compromised

Having a clear plan before an incident is far better than figuring it out during one. Here’s the response sequence for a compromised healthcare website:

• Take the site offline or put it in maintenance mode to stop active damage and prevent further patient exposure to malicious content.
• Contact your hosting provider immediately. Managed hosts have security response teams. Shared hosting providers may not, but they can isolate the account.
• Restore from a clean, pre-infection backup. Identify the last clean backup date. Restore to that point on a staging environment first to verify it’s clean.
• Identify and remove malware. Use Sucuri SiteCheck or Wordfence scan to identify malicious files. Remove them or restore from clean backup.
• Update everything and change all credentials. WordPress core, all plugins, all themes. Change every admin password. Revoke and re-issue SSH keys. Change hosting account passwords.
• Assess what data was exposed. Was form submission data accessible? Were patient inquiry records in the database? Document the scope for your records and any notification obligations.

For ongoing maintenance that prevents these situations, read our healthcare website maintenance guide and our detailed healthcare website maintenance services overview.