HIPAA Web Security Checklist for Healthcare Sites

You cannot protect what you cannot see. Before hardening anything, map every web-facing system that stores, processes, or transmits PHI. This scoping exercise is required by HIPAA's Risk Analysis standard (§164.308(a)(1)) and forms the foundation of every subsequent step.

• List every public domain, subdomain, and API endpoint associated with your healthcare application.
• Label which endpoints accept or return PHI (patient portals, appointment forms, lab result pages, billing pages).
• Document the technology stack: web server software and version, application framework, CDN, and third-party integrations.
• Identify all environments (production, staging, dev) and confirm that staging/dev environments never contain real PHI.
• Record where SSL/TLS termination occurs — load balancer, CDN edge, or origin server — to ensure encryption is enforced end-to-end.

A default web server installation is designed for compatibility, not security. Attackers fingerprint server software and exploit known default behaviours. Stripping the server to only what your application needs dramatically reduces the attack surface — a core requirement under HIPAA's Technical Safeguards for integrity and access control.

• Remove default content: Delete default index pages, documentation directories, and example scripts (e.g., /manual on Apache, default IIS welcome pages).
• Disable unused modules: On Apache, disable mod_status, mod_info, and mod_userdir unless explicitly needed. On Nginx, remove unused upstream modules at compile time.
• Restrict HTTP methods: Allow only GET, POST, and HEAD. Explicitly deny TRACE, OPTIONS, PUT, DELETE, and CONNECT unless your API requires them.
• Suppress the Server banner: Set ServerTokens Prod (Apache) or server_tokens off (Nginx) to prevent version disclosure.
• Suppress the X-Powered-By header: Remove or spoof this header to hide your backend technology (PHP, ASP.NET, etc.).
• Set directory listing to off: Ensure Options -Indexes (Apache) or autoindex off (Nginx) so directory contents are never exposed.
• Run the web server as a non-privileged user: The process should not run as root. Use a dedicated service account with minimal OS permissions.
• Limit request size: Set LimitRequestBody (Apache) or client_max_body_size (Nginx) to the minimum value your application requires to mitigate denial-of-service risks.
• Configure connection timeouts: Set KeepAliveTimeout and Timeout to sensible low values to resist slow-loris style attacks.
• Sensagraph continuously scans your exposed server headers and flags information-disclosure issues automatically.

HIPAA explicitly requires encryption of ePHI in transit (§164.312(e)(1)). TLS is the mechanism, but a misconfigured TLS setup — one that allows old protocol versions or weak ciphers — provides a false sense of security. Modern attackers exploit weak TLS to decrypt session traffic or perform downgrade attacks.

• Enforce TLS 1.2 as the minimum: Disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 at the server level. These are deprecated and vulnerable (POODLE, BEAST, DROWN).
• Prefer TLS 1.3: Enable TLS 1.3 support on your server and client-facing load balancer; it provides forward secrecy by default and eliminates several legacy handshake vulnerabilities.
• Use strong cipher suites: Allow only AEAD ciphers such as AES-128-GCM, AES-256-GCM, and CHACHA20-POLY1305. Disable RC4, 3DES, DES, and any NULL or EXPORT cipher suites.
• Enable and enforce Perfect Forward Secrecy (PFS): Prefer ECDHE and DHE key exchange algorithms so that compromise of the server's private key does not expose past sessions.
• Use a 2048-bit or larger RSA key (or EC P-256+): Keys shorter than 2048 bits are no longer considered secure.
• Disable TLS compression: TLS-level compression is vulnerable to the CRIME attack; ensure it is off.
• Configure OCSP Stapling: Enable OCSP stapling on your server so certificate revocation status is delivered efficiently without leaking client IP to certificate authorities.
• Redirect all HTTP to HTTPS: Issue a 301 permanent redirect from port 80 to port 443 for every domain and subdomain that handles PHI.
• Verify the full certificate chain: Ensure intermediate certificates are correctly included in the server's certificate bundle to prevent chain-of-trust errors on some clients.
• Sensagraph checks your TLS protocol versions, cipher suite strength, and certificate chain validity on every scan.

HTTP security headers are a lightweight but high-impact layer of defence. They instruct browsers how to behave when rendering your pages, mitigating entire classes of attacks — cross-site scripting, clickjacking, MIME sniffing, and protocol downgrade — that could expose PHI. Many HIPAA auditors now review header configuration as part of technical safeguard assessments.

• Strict-Transport-Security (HSTS): Set Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. This forces browsers to use HTTPS exclusively and prevents SSL-stripping attacks. Submit to the HSTS preload list at hstspreload.org once confirmed stable.
• Content-Security-Policy (CSP): Define a strict policy that whitelists only your own origins for scripts, styles, images, and frames. Start with Content-Security-Policy: default-src 'self' and expand only as needed. Use a reporting endpoint (report-uri or report-to) to catch violations.
• X-Frame-Options: Set to DENY or SAMEORIGIN to prevent clickjacking attacks that could trick users into submitting PHI to a malicious frame.
• X-Content-Type-Options: Set X-Content-Type-Options: nosniff to stop browsers from MIME-sniffing responses, which can lead to script injection.
• Referrer-Policy: Set to no-referrer or strict-origin-when-cross-origin to prevent patient URLs (which may contain PHI in query strings) from leaking in the Referer header to third-party sites.
• Permissions-Policy (formerly Feature-Policy): Disable browser features your application does not use: Permissions-Policy: geolocation=(), microphone=(), camera=().
• Cross-Origin-Opener-Policy (COOP): Set Cross-Origin-Opener-Policy: same-origin to isolate your browsing context and mitigate Spectre-style side-channel attacks.
• Cross-Origin-Resource-Policy (CORP): Set Cross-Origin-Resource-Policy: same-origin on API responses containing PHI to prevent cross-origin reads.
• Remove unnecessary headers: Ensure X-Powered-By, X-AspNet-Version, and X-AspNetMvc-Version headers are absent from all responses.
• Sensagraph audits all HTTP response headers on every scan and flags missing or misconfigured security headers against best-practice baselines.

An expired or revoked certificate breaks encrypted transport and triggers browser warnings that patients interpret as a sign of an untrustworthy site. Worse, it may force users to click through warnings and transmit PHI over an untrusted connection. Certificate management is an operational control HIPAA auditors consider part of the ongoing risk management programme.

• Track all certificate expiry dates: Maintain a central inventory of every certificate in use, including those on subdomains, internal services, and load balancers.
• Automate renewal: Use ACME-based automation (e.g., Certbot with Let's Encrypt, or your CA's API) to renew certificates at least 30 days before expiry. Avoid manual renewal as the sole process.
• Alert on expiry: Set up monitoring alerts at 60, 30, and 7 days before expiry. Treat a certificate expiring within 7 days as an incident.
• Use certificates from trusted CAs only: Ensure certificates are issued by a publicly trusted Certificate Authority. Self-signed certificates are not acceptable for patient-facing systems.
• Revoke and replace compromised certificates immediately: If a private key is ever exposed (server breach, accidental commit to a repository), revoke the certificate within hours and rotate the key.
• Check SANs match all served domains: Confirm that Subject Alternative Names cover every hostname your application responds to, including www and non-www variants.
• Sensagraph monitors certificate validity and expiry on every scan and alerts when certificates are approaching expiry or present chain errors.

Information disclosure — leaking software versions, internal paths, stack traces, or patient identifiers in URLs — gives attackers a map of your environment and may constitute a HIPAA breach if PHI is exposed. This step focuses on minimising what your application reveals about itself under normal and error conditions.

• Configure custom error pages: Replace default 400, 403, 404, 500 error pages with custom pages that show no server, framework, or file path information.
• Disable stack traces in production: Ensure display_errors = Off (PHP), debug mode is disabled (Django, Rails, Node), and exceptions are logged server-side only — never rendered to the browser.
• Audit query strings for PHI: Ensure patient identifiers, record numbers, and appointment IDs are never passed as plain-text URL parameters, as these appear in server logs, browser history, and the Referer header.
• Secure robots.txt: Do not list sensitive paths (admin panels, API endpoints, patient data directories) in robots.txt — it is publicly readable and acts as a roadmap for attackers.
• Review third-party scripts and analytics: Every external JavaScript tag on your site is a potential data leak. Audit all third-party tags; ensure analytics tools are configured to anonymise or exclude PHI.
• Disable or restrict CORS: If your API uses CORS, whitelist only specific trusted origins. Never use Access-Control-Allow-Origin: * on endpoints that return PHI.
• Remove backup and temporary files from the web root: Files like .bak, ~, .swp, and .old left in a public directory can expose source code or configuration data.

HIPAA's Access Control standard (§164.312(a)(1)) requires that only authorised users access ePHI. Weak authentication is consistently the top vector in healthcare data breaches. This step focuses on controls specific to the web application and server access layer.

• Require Multi-Factor Authentication (MFA): Enforce MFA for all accounts that can access PHI — clinical staff, admin users, and developers with production access.
• Enforce HTTPS-only cookies: Set the Secure flag on all session cookies so they are never transmitted over plain HTTP.
• Set HttpOnly on session cookies: Prevent JavaScript from reading session cookies by setting the HttpOnly flag, mitigating XSS-based session hijacking.
• Use SameSite cookie attribute: Set SameSite=Strict or SameSite=Lax on session cookies to reduce CSRF risk.
• Implement account lockout and rate limiting: Lock accounts after a defined number of failed login attempts and rate-limit authentication endpoints to resist brute-force attacks.
• Restrict access to admin and management interfaces by IP: Firewall or network-layer restrict admin panels (/admin, /wp-admin, server management ports) to known office or VPN IP ranges.
• Disable password-based SSH; use key-based authentication: For server access, disable PasswordAuthentication yes in sshd_config and require SSH key pairs.
• Apply principle of least privilege to database accounts: The web application's database user should have only SELECT/INSERT/UPDATE on required tables — never full DBA privileges.
• Implement session timeout: Automatically expire authenticated sessions after a period of inactivity consistent with HIPAA's automatic logoff standard (§164.312(a)(2)(iii)). 15–30 minutes is a common healthcare benchmark.

HIPAA's Security Rule is not a one-time checkbox — it requires ongoing risk management (§164.308(a)(1)(ii)(A)). Configuration drift, dependency updates, and new attack techniques mean that a server hardened today can be vulnerable next month. Continuous monitoring and rigorous documentation are what turn a security checklist into an auditable compliance programme.

• Run automated security scans regularly: Schedule scans against all production domains at least weekly, and trigger scans automatically after every deployment. Sensagraph provides continuous automated scanning that checks TLS configuration, HTTP headers, certificate status, and information-disclosure issues on every run.
• Maintain an audit log of all configuration changes: Every change to server config, TLS settings, firewall rules, and security headers must be logged with a timestamp, the person who made the change, and the reason. Use version-controlled infrastructure-as-code (Terraform, Ansible) where possible.
• Conduct a formal risk analysis at least annually: Document identified risks, their likelihood and impact, and the controls implemented to mitigate them. Update this document whenever you add new systems or services that touch PHI.
• Test your incident response plan: Simulate a TLS certificate expiry, a data exposure via a misconfigured header, or a server information-disclosure finding. Confirm your team can detect, respond, and document the incident within defined SLAs.
• Perform penetration tests periodically: Commission third-party penetration tests (at least annually or after significant changes) that specifically target the web application and server layers handling PHI.
• Review and update security policies: Ensure your Acceptable Use Policy, Password Policy, and Incident Response Plan are reviewed at least annually and reflect current technical controls.
• Track remediation of all findings: Every vulnerability found by a scan or pen test must be assigned an owner, a severity rating, and a remediation deadline. Document when it was fixed and re-verify closure.
• Keep a Business Associate Agreement (BAA) on file: For every third-party vendor whose service touches PHI (hosting, CDN, analytics), ensure a signed BAA is in place and reviewed annually.