Skip to content

Instantly share code, notes, and snippets.

@AustinWood
Created January 22, 2026 23:34
Show Gist options
  • Select an option

  • Save AustinWood/987847d043d2e7724ca0b3c8f6451ec2 to your computer and use it in GitHub Desktop.

Select an option

Save AustinWood/987847d043d2e7724ca0b3c8f6451ec2 to your computer and use it in GitHub Desktop.
Security Recommendations for FTP - Next Health

Security Recommendations for FTP

These are specific, actionable steps to address critical vulnerabilities in the FollowThatPatient system. Each recommendation includes precedent from actual HIPAA enforcement actions—organizations that faced multi-million dollar penalties for lacking these exact controls.


1. Block Bulk Patient Endpoint (CRITICAL — Do Immediately)

Action: Create mobile-specific access tokens that block access to GET /patients (the bulk endpoint). The mobile app only needs GET /patients/:id—there is no legitimate reason for a patient's phone to request the entire patient database.

Effort: Low (days, not weeks)

Why it matters: The current system allows any authenticated user—including someone who just downloaded the app from the App Store—to retrieve the entire patient database in seconds. This is the most urgent vulnerability. Blocking the bulk endpoint doesn't fix the underlying authorization problem (see Step 2), but it stops the easiest and most damaging attack vector immediately.

Precedent: In Anthem, Inc. (2018), OCR found that the company "failed to implement adequate minimum access controls to prevent cyber-attackers from accessing sensitive ePHI." Anthem paid $16 million to settle—the largest HIPAA penalty in history. The breach exposed 79 million patient records. (HHS.gov)


2. Implement User-Scoped Authentication (HIGH — Within 2 Weeks)

Action: Implement JWT-based (or equivalent) authentication where tokens are scoped to the specific user who logged in. If userId=2 logs in, they should only be able to access their own patient record—not change the ID to access any other patient's information.

Effort: Moderate (requires backend changes)

Why it matters: The current system has no authorization layer at the API level. Any valid token can access any patient record by simply changing the ID in the request. This is an "Insecure Direct Object Reference" (IDOR) vulnerability—ranked #1 on the OWASP API Security Top 10.

Precedent: In Premera Blue Cross (2020), OCR found failures to "implement sufficient procedures to prevent unauthorized access to ePHI." Premera paid $6.85 million—the second-largest HIPAA settlement ever. Additionally, a class action cost them $74 million. (HHS.gov)


3. Replace Sequential IDs with UUIDs (MEDIUM — Within 30-60 Days)

Action: Replace sequential integer IDs (/patients/1, /patients/2, etc.) with non-enumerable UUIDs or similar identifiers throughout the system.

Effort: High (requires refactoring across FTP)

Why it matters: Sequential integers allow trivial enumeration attacks. Even with proper authentication, if any part of the system is compromised, an attacker can iterate through every patient record. UUIDs make this practically impossible.

Precedent: In Children's Medical Center of Dallas (2017), OCR imposed a $3.2 million civil monetary penalty—notably because Children's had received external recommendations to fix security issues and failed to act on them. OCR stated: "Covered entities that fail to take action risk exposure to the consequences of a HIPAA breach." The failure to implement known security recommendations was explicitly cited as an aggravating factor. (HHS.gov)


4. Implement Access Logging and Monitoring (MEDIUM — Within 30 Days)

Action: Enable comprehensive audit logging for all API access to patient records. Implement automated alerting for anomalous access patterns (e.g., a single user accessing hundreds of patient records).

Effort: Moderate

Why it matters: Even after implementing access controls, you need visibility into who is accessing what. This serves both as a deterrent and as evidence of due diligence in the event of a breach investigation.

Precedent: In Gulf Coast Pain Consultants (2024), a former contractor accessed the system on three occasions to steal PHI for fraudulent Medicare claims. OCR found the organization failed to "implement procedures to regularly review records of activity in information systems." Penalty: $1.19 million. (HHS.gov) In Anthem, the attackers "roamed undetected" for months—OCR explicitly cited the "failure to regularly review information system activity" as a violation.


Summary

# Recommendation Priority Effort Timeline
1 Block bulk patient endpoint CRITICAL Low Immediately
2 User-scoped authentication HIGH Moderate 2 weeks
3 Replace IDs with UUIDs MEDIUM High 30-60 days
4 Access logging & monitoring MEDIUM Moderate 30 days

These are not optional enhancements—they are baseline security controls required by HIPAA. The precedents above demonstrate that OCR imposes the harshest penalties when organizations are aware of vulnerabilities and fail to act.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment