HIPAA on the web: the four patterns that fail every audit

PHI in URLs, missing HSTS on PHI pages, browser autofill on PHI forms, and third-party scripts on PHI pages. Each of these has been the root cause of seven-figure OCR fines. Here is what they look like and how to fix them.

If your website touches Protected Health Information — patient portals, appointment booking, insurance forms, telehealth, even a contact form on a clinical site — HIPAA's Security Rule applies to the web layer. Most violations we audit cluster around four patterns. None require custom infrastructure. All have been the root cause of seven-figure HHS Office for Civil Rights fines.

Pattern 1: PHI in URLs

The most common HIPAA-relevant web finding. URLs are written to server access logs, browser history, third-party referrer headers, CDN edge caches, and the URL bar of any device that displays the page — none of which sit under a Business Associate Agreement.

Telltale patterns: ?patientid=A4729183, /portal/dashboard/MRN-12345, ?diagnosis=type2-diabetes. Even an internal-only system ID counts if it can be correlated back to a patient.

Fix pattern: pass identifiers in the request body (POST), and resolve from the authenticated session server-side. URLs should be opaque — /portal/dashboard, no query string. If you must use a path identifier for caching, use a one-way HMAC token rotated per session.

Pattern 2: Missing or weak HSTS on PHI pages

A returning user typing your domain into the address bar without a protocol initiates an HTTP request. Without HSTS, that HTTP request is interceptable and can be steered to an attacker before the HTTPS redirect happens. On a HIPAA-covered patient portal this is exactly the threat HSTS exists to close.

Fix pattern: set Strict-Transport-Security: max-age=31536000; includeSubDomains; preload site-wide. Verify with the Plumb security module. Submit to the HSTS preload list once stable.

Pattern 3: Forms with PHI and browser autofill enabled

A patient enters their member ID, MRN, or date of birth into a form. The browser asks “save this for later?” — and the next user of the same device (a shared family iPad, a library computer, a clinic kiosk) sees an autofill suggestion for the previous patient's value. This is a documented Office for Civil Rights review gap and a source of complaint-driven investigations.

Fix pattern: set autocomplete="off" on every PHI-bearing input. The HTML5 autocomplete attribute also accepts more granular tokens — autocomplete="new-password" for credentials, but for genuine PHI the conservative answer is off.

Pattern 4: Third-party scripts on PHI pages

Meta Pixel on a patient appointment page. Google Analytics on the diagnosis search results. Hotjar session replay on the symptom-checker. Each of these can result in PHI being transmitted to a third party without a Business Associate Agreement — and 2022-2024 saw a wave of class-action lawsuits against hospital systems for exactly this pattern.

Fix pattern: maintain a separate list of pages that touch PHI. On those pages, no third-party scripts may load — period. If you need analytics, use a HIPAA-eligible vendor (Google Analytics 4 with a signed BAA only applies to specific configurations; most deployments don't qualify), self-host, or aggregate server-side.

What enforcement looks like

HHS Office for Civil Rights enforces HIPAA. Penalties are tiered by culpability:

• Tier 1 (unknown violation) — $137 to $68,928 per violation, annual cap of $2.07M (2024 indexed amounts).
• Tier 2 (reasonable cause) — $1,379 to $68,928 per violation, same annual cap.
• Tier 3 (willful neglect, corrected) — $13,785 to $68,928 per violation.
• Tier 4 (willful neglect, not corrected) — $68,928 per violation, annual cap of $2.07M.

Beyond fines, every HIPAA enforcement action involves a corrective action plan with multi-year monitoring. The cost of the CAP often exceeds the cost of the fine.

Parallel exposure: 38 states have their own breach-notification laws that fire on the same incident, and class-action plaintiffs' firms will follow any OCR resolution agreement with their own filings.

What HIPAA is not

A few common misconceptions worth correcting:

• HTTPS alone is not HIPAA compliance. Encryption in transit is one of about a dozen technical safeguards in § 164.312. Sites still fail audits with perfect HTTPS.
• A privacy policy is not HIPAA compliance. HIPAA requires a Notice of Privacy Practices — a specific document with required elements that differs from a generic web privacy policy.
• A BAA is not retroactive. If you sent data to a subprocessor before signing the BAA, the historical data is still unprotected. Audit what data flowed where before you signed.

What Plumb checks

Plumb's healthcare module checks the four patterns above plus a handful of adjacent ones: HTTPS enforcement on PHI pages, form method (POST vs GET) on PHI forms, form action HTTPS, and the presence of third-party scripts. The report lists each finding with the affected URL and exact remediation. Re-run after fixes and confirm the healthcare-module section reports all checks passed — that's evidence for your security and compliance team, not just engineering.

This article is not legal advice. HIPAA obligations depend on specific facts and data flows. Engage qualified counsel and a HIPAA-experienced security consultant for your specific situation.