Skip to content
HealthTAG Hospital Module

Security hardening

Deployment controls

Section titled “Deployment controls”
  • Expose only Kong HTTPS 443; restrict or remove host mappings for API 9000, HAPI 8080, and Kong Admin 8444.
  • Use a trusted TLS certificate, protect private keys, and rotate certificates before expiry.
  • Generate unique database passwords and API credentials; never reuse repository examples.
  • Restrict environment-file permissions and inject production secrets through an approved secret manager where possible.
  • Replace wildcard CORS with approved origins and headers.
  • The hospital must create, store, and rotate FHIR_API_KEY. Give it only the access required for Hospital API queries through the key-auth FHIR route.
  • Restrict Hospital API port 9000 to approved HealthTAG Lambda traffic, rate-limit sensitive routes, and retain access/audit logs under hospital policy.
  • Pin and scan images, patch the host, restrict outbound access, encrypt backups, and test recovery.

Known implementation risks

Section titled “Known implementation risks”

[!DANGER] Do not rely on the current Hospital API as a verified consent-enforcement boundary until these defects are remediated and tested.

  • api/src/routes/patients/index.ts contains a hard-coded blockchain private key.
  • The authorization function returns a Promise but the route does not await it; a Promise is truthy, so the intended denial branch is not reliably enforced.
  • The credential failure test compares an object by identity (patientCredential === {}), which never detects a newly returned empty object.
  • Several failures collapse to HTTP 400, reducing auditability and making authentication/authorization errors indistinguishable.
  • CORS is unrestricted in both the Express API and Kong setup.
  • The Compose file publishes internal API and HAPI ports and contains unpinned application images.

Track these as source-code security work in the data-source-node repository. After remediation, add automated allow/deny tests and obtain an independent security review. This documentation deliberately makes no guarantee that blockchain authorization currently protects every response.