Hi team, We are currently having a pentest, and had an issue which seems to be linked to the way medplum SDK handles the access token. The description of the vulnerability is the following : Description The application stores accessToken and refreshToken in localStorage, accessible via JavaScript. This allows an attacker able to execute code in the browser context (XSS or injection) to retrieve these tokens and take full control of the user’s account. Impact • Complete account takeover: immediate access to protected resources via the accessToken. • Persistent access: the refreshToken can generate new accessTokens even after expiration. • Exposure of PII: the token allows access to sensitive patient information. • Ease of exploitation: reachable via a simple JavaScript injection or XSS. In the medical context, patient data and internal references can be compromised, creating a GDPR/HIPAA risk. Recommendations • Never store tokens in localStorage. • Use HttpOnly, Secure cookies to store refreshTokens. • Immediately rotate exposed refreshTokens and invalidate active accessTokens. • Limit client-side exposure: never include tokens in JSON responses accessible to JS. • Strengthen XSS protection: strict Content Security Policy (CSP), server-side validation/sanitization, and secure front-end libraries. • Implement monitoring and alerts for token usage and suspicious attempts. • Token rotation and short lifetimes: limit accessToken lifetimes and make refreshTokens single-use or revocable. I've also found this article talking about this vulnerability : https://medium.com/@anoop-singh-dev/why-you-should-stop-storing-tokens-in-local-storage-and-use-http-only-cookies-instead-8ca79f10f979 Do you have any feedback on this ? Thank you !

Hi @thomabig - (Long post ahead, please feel free to message me directly if you'd like to discuss) Thank you for sharing the pentest findings. Medplum takes security very seriously. Token storage in SPAs is indeed a nuanced security topic with trade-offs rather than absolute right/wrong approaches. You're correct that

MedplumClient

stores tokens in

localStorage

by default. This is a deliberate design choice that balances security with implementation complexity, and aligns with practices used by many major platforms including Auth0, Okta, and AWS Amplify when configured for static SPAs. Regarding the GDPR/HIPAA concern: It's important to clarify that the risk to patient data comes from the XSS vulnerability itself, not the token storage location. If an attacker can execute JavaScript in your application: * They can make API calls as the user regardless of token storage location * They can capture any data the user enters or views * They can modify the application UI to phish credentials * Even with httpOnly cookies, they can still perform actions on behalf of the user while they're active HIPAA's Security Rule requires "reasonable and appropriate" technical safeguards but does not prescribe specific implementation details like token storage methods. The key requirements are around access controls, encryption in transit, and audit logging - all of which Medplum provides regardless of token storage location. The real HIPAA/GDPR risk here is XSS itself, not

localStorage

. An XSS vulnerability that allows access to patient data is the compliance issue, regardless of how authentication tokens are stored. Once an attacker has JavaScript execution in your application context, they have session-level access to PHI whether or not they can persist tokens. Medplum does support httpOnly cookie authentication for customers who require it. This involves: * Setting up a backend proxy service * Configuring CORS and CSRF protections * Managing secure cookie settings * Implementing proper session handling We typically help enterprise customers implement this more complex configuration. For your current setup, we recommend focusing on XSS prevention: * Implement strict Content Security Policy headers * Ensure all user input is properly sanitized * Keep dependencies updated * Use Medplum's built-in CORS configuration correctly If moving to cookie-based auth is a requirement from your pentest, we can discuss the implementation requirements and what tier of support would include assistance with that configuration. This is a complicated topic. Please let me know if you would like to discuss more offline.

Hi @cody Thank you for your answer ! I will take this as a first step to discuss it with the pentester !

I had the same vulnerability report show up yesterday. So I strengthened cors and csrf. That’s all the security I know

What do you mean you've strenghtened CORS and CSRF ?