Pass sensitive data from loader to client

[brendanfmartin]

Problem

Some data may be passed from the loader function to the client side. An example is data needed to make authenticated client side API calls. I would like to store this data in memory and remove the data from the DOM.

Example

https://github.com/brendanfmartin/test-react-router-secrets

Start the application. Open the Inspect Elements tab and search for the secret: ishouldbehidden

You will see the secret value on the window.__reactRouterContext.streamController.

How do I prevent this value from being shown on the DOM?

[sergiodxa]

There's no way yo send data from the server to the client without allowing clients to read it.

Even if you stopped using the route loader and fetched it, the data is available on the Network tab of the browser devtools.

The only safe thing to do is to fetch the API server-side using that sensitive data and return to the client the non-sensitive data needed to render the UI.

[brendanfmartin]

@gustavopch That's a great idea and is part of my test cases. For context we have web architecture with specialized edge routing that will load up our RR7 app as a host container for MFE. There is an orchestration in handing off data and I need to test all my cases for UX on loading as well as performance.

I'm going to test:

• Pull on clientLoader at root level
• Pull on clientLoader at each top level domain
• Encrypt on server and decrypt on UI

If there are any other mechanisms to test please let me know.

[gustavopch]

Not sure, but I suspect middleware may be useful here, like a server middleware that encrypts and a client middleware that decrypts, so this would happen automatically for all your routes, or maybe you could make it only encrypt/decrypt props that are prefixed with secret. Middleware support is already available in experimental releases, so you can play with it: #12941

[sergiodxa]

Removing ir from the dom after streaming won't help, http streaming works without JS so you could send a request, get the html with the sensitive data and ignore the JS

[sergiodxa]

To decrypt you will send to pass the decryption key to the browser, this makes it public showing anyone to decrypt it

[gustavopch]

Our concern is third party libraries having access to sensitive data.

@sergiodxa Would that be a problem even considering he's not worried about the user, but only about 3rd party libs?