-
Notifications
You must be signed in to change notification settings - Fork 122
Best Practice
Below are some guidelines about things you can try to do to stay as compliant and as secure as possible when using node-fhir-server-core.
node-fhir-server-core has the ability to run in both http and https mode. In order to run in https mode, you must provide a valid certificate and key. In https mode, the server will also have HSTS enabled. There are other options for deploying with HTTPS. For example, you can deploy this in http mode and put an AWS Load Balancer in front of it and setup an HTTPS domain through Amazon.
While we are not preventing you from running this server in http mode, mainly because we want to provide flexibility with your deployment, we really encourage you to only expose the API over HTTPS.
However you decide to implement authentication, you need to manage tokens correctly and have strategies in place for validating tokens. A few simple things you can do are to invalidate old tokens when new tokens are issued, only issue short lived tokens, and have an invalidate endpoint that you can revoke someone's token if they are spamming the system or repeatedly trying to access things they should not have access to. You can even associate an ip address with a token. This way, if someone sniffs the token and tries to use it you will see that a different ip is using a token. The new ip address should be blocked and forced to login to prove they are legitimate. Lastly, we recommend you have some sort of introspection endpoint. If someone is granted a token and this token includes scopes, they could theoretically decrypt the token, update the scopes, and resign it (this does of course require the secret used to sign the token). However, a simple mitigation for these kinds of attacks is to take the given token and hit an introspection endpoint and compare the token signatures, if something changed, revoke it.
NOTE: We are currently working on some of these for you in the core repo so you will not need to worry about them.
We are currently not translating resources between versions. If a user makes a request to an stu3 endpoint and your data is in dstu2 format, we will not be attempting to translate that data for you or map any properties between versions. There are many cases where this conversion is simply not possible if you want to remain 100% compliant. However, if you want to map the data yourself outside of core, you can make a best effort to map them in your implementation. We will cast anything that comes back from your services to it's version specific resource. For example, if a GET request comes in for stu3/Patient/12, whatever JSON you return will be used to create a new patient resource based on the stu3 spec.