Locking Down a Partner API and Patient Portal

Rank by exploitability and blast radius. First, the API identity gap: an API key that does not resolve a user means every partner call can inherit Anonymous and bypass role checks. Contain by disabling the public endpoint or forcing it through a gateway that rejects calls until custom authentication resolves a user and sets the request identity. Second, the PatientRecord screen: missing screen permission plus no CheckRole can expose patient data to any session that reaches the screen. Add the screen permission, add CheckRole and CheckPermission in preparation and in the data action, and verify with a test account for each role. Third, SQL injection: remove Expand Inline, use bound parameters, and validate input. Fourth, log exposure: mask patient IDs and query text at source, restrict log access. Fifth, rate: apply gateway throttling and alerting. Do not treat the API key as authentication; it is at most a client identifier. After containment, rotate keys and notify the privacy officer if access logs show exposure.

Separate authentication, role permission, and object-level access. For the API, authenticate the caller to a known application user or service account, then check a scope or permission for each operation, such as read:patient or write:note, at the server action boundary. Do not rely on the route or controller. For patient data, check that the requested patient is in the caller's tenant, clinic or care relationship; a Clinician role alone is not enough. For screens, set screen permissions, add CheckRole and CheckPermission in the screen preparation, and re-check in the data action or aggregate that returns records. Hide UI elements only as usability, never as security. Use least privilege: partner clinics get read-only access to their own patients; Admin does not automatically get clinical data unless a business rule allows it. Log authorization decisions with caller, patient, action and result, but not clinical payload. Add automated tests for Anonymous, Patient A versus Patient B, Clinician outside clinic, and Admin. Review all exposed REST methods for missing checks, not just the reported one.

Centralize security logs with tamper-evident retention. Alert on authentication failures, authorization denials, unusual patient-record volume per caller or IP, and rate-limit breaches. Remove sensitive payloads from error logs; log correlation IDs and masked identifiers. For incident response: preserve evidence, determine whether the API key or screen was actually exploited, rotate credentials, revoke sessions or tokens if needed, and follow the provider's breach notification policy with legal and privacy. Add a post-incident review with owners and dates. Prevent recurrence with a secure coding checklist for exposed REST and SQL widgets, a pre-production security test for every new API, and a review of all screens with no permission. Track mean time to detect and mean time to contain as metrics. If clinical access must stay up, use a gateway rule to block only the affected partner scope rather than taking down the portal.